ZUGFeRD oder XRechnung: welches Format Sie wirklich brauchen

1. Warum „ZUGFeRD oder XRechnung“ nicht aufgeht

Unten steht die Norm: EN 16931, 2017 veröffentlicht. Sie legt fest, welche Angaben eine elektronische Rechnung enthalten muss und wie sie zueinander passen müssen — Rechnungsnummer, Datum, Parteien, Positionen, Steueraufschlüsselung, Summenproben. Jedes Pflichtfeld hat eine Nummer, von BT-1 aufwärts. Alles, was danach kommt, ist eine Variation dieser Norm.

Die XRechnung ist eine solche Variation, genauer: eine CIUS, eine „Core Invoice Usage Specification“. Sie macht die Norm für deutsche öffentliche Auftraggeber enger, nie anders. Was in der EN 16931 optional ist, kann in der XRechnung Pflicht werden; erfinden darf sie nichts dazu. Deshalb ist jede XRechnung automatisch auch eine gültige EN-16931-Rechnung, umgekehrt gilt das nicht.

ZUGFeRD beantwortet eine ganz andere Frage, nämlich: in welcher Datei reist das Ganze? Eine ZUGFeRD-Rechnung ist eine PDF/A-3-Datei nach ISO 19005-3, in die dieselben strukturierten Daten als XML eingebettet sind. Das FeRD nennt das ein „inhaltlich identisches Mehrstück derselben Rechnung“: Der Mensch sieht die PDF, die Software liest die XML, und beide müssen dasselbe sagen.

Daraus folgt der Satz, an dem die meisten Vergleichstabellen scheitern: eine ZUGFeRD-Datei kann eine XRechnung enthalten. Kein Sonderfall, sondern ein eigenes ZUGFeRD-Profil mit dem Namen XRECHNUNG.

Regelwerk und Hülle sind eben zwei Achsen, und jede Rechnung hat auf beiden einen Wert.

2. Die Entscheidung, kurz

Meine Meinung dazu, deutlicher als die Tabelle: Wenn Sie keine Behördenkunden haben, brauchen Sie die XRechnung nie. Dann ist ZUGFeRD im Profil EN 16931 die richtige und einzige Antwort, und jeder Aufwand, den Sie in die Formatfrage stecken, ist verschwendet. Das kippt in dem Moment, in dem ein einziger Kunde eine Leitweg-ID oder ein Peppol-Postfach nennt — dann brauchen Sie beide Wege, und zwar dauerhaft.

Eine Vorgabe schlägt all das: Steht im Vertrag oder im Lieferantenportal ein Format, gilt dieses. Darüber diskutiert niemand erfolgreich mit einer Einkaufsabteilung.

3. Die acht Regeln, die nur die XRechnung kennt

Hier wird der Unterschied konkret. Eine Rechnung, die als EN 16931 durchgeht, fällt als XRechnung durch, wenn eine dieser Angaben fehlt. Die Regelcodes sind die des KoSIT-Validators; wir haben jede Regel am 7. September 2026 einzeln gegen ihn laufen lassen, bevor sie in unsere Vorab-Prüfung kam.

Vier der acht Regeln drehen sich um dieselbe Sache: einen erreichbaren Menschen beim Rechnungssteller, mit Name, Telefon und E-Mail. Das wirkt kleinlich, ist aber der Punkt, an dem in der Praxis die meisten XRechnungen durchfallen — weil in der EN 16931 niemand diese Gruppe füllen muss und viele Systeme sie deshalb gar nicht anbieten.

Zur Leitweg-ID in BT-10 gibt es einen eigenen Beitrag: Leitweg-ID in der E-Rechnung erklärt, woher Sie sie bekommen und wie sie aufgebaut ist.

4. Woran man im XML sieht, was man vor sich hat

Dieselbe Rechnung, zweimal aus unserem Generator — einmal als EN 16931, einmal als XRechnung. Unterschieden wird sie ganz am Anfang des Dokuments, im Kontextblock. Zuerst die EN-16931-Fassung:

<rsm:ExchangedDocumentContext>
  <ram:GuidelineSpecifiedDocumentContextParameter>
    <ram:ID>urn:cen.eu:en16931:2017</ram:ID>
  </ram:GuidelineSpecifiedDocumentContextParameter>
</rsm:ExchangedDocumentContext>

Und dieselbe Stelle als XRechnung:

<rsm:ExchangedDocumentContext>
  <!-- BT-23 steht VOR der Guideline: so schreibt es die XSD-Sequenz vor -->
  <ram:BusinessProcessSpecifiedDocumentContextParameter>
    <ram:ID>urn:fdc:peppol.eu:2017:poacc:billing:01:1.0</ram:ID>
  </ram:BusinessProcessSpecifiedDocumentContextParameter>
  <ram:GuidelineSpecifiedDocumentContextParameter>
    <ram:ID>urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0</ram:ID>
  </ram:GuidelineSpecifiedDocumentContextParameter>
</rsm:ExchangedDocumentContext>

Zwei Dinge kommen dazu. Die Guideline-Kennung (BT-24) trägt jetzt die KoSIT-Fassung als Anhängsel — das ist die Zeile, an der jeder Validator erkennt, nach welchem Regelsatz er prüfen soll. Und darüber steht der Geschäftsprozess (BT-23) mit der Peppol-Kennung.

5. Zwei Dinge, die wir dabei falsch hatten

Der Abschnitt steht hier, weil beide Fehler in jeder Spezifikation nachlesbar sind und wir sie trotzdem gemacht haben. Wer gerade selbst einen Generator baut, spart sich damit zwei Tage.

BT-23 steht vor BT-24, nicht danach

Wir hatten den Geschäftsprozess hinter die Guideline geschrieben. Inhaltlich war alles da, und trotzdem fiel das Dokument durch — nicht an einer Geschäftsregel, sondern schon am Schema, weil die XSD die Reihenfolge der Kinder im Kontextblock festlegt. Aufgefallen ist es erst beim Gegenlauf am 7. September 2026, weil die Regel PEPPOL-EN16931-R001 den Wert verlangt und wir sehen wollten, ob wir ihn richtig setzen. Eine Reihenfolge-Verletzung meldet der Validator nicht als „Ihr BT-23 ist an der falschen Stelle“, sondern als Schemafehler weit oben in der Datei. Danach sucht man an der falschen Stelle.

383 und 386 sind eine Warnung, kein Fehler

Die Regel BR-DE-17 zählt auf, welche Dokumentarten die XRechnung vorsieht: 326, 380, 381, 384, 389 und 875 bis 877. Wir hatten daraus geschlossen, dass alles andere ein Fehler ist, und 383 (Belastungsanzeige) sowie 386 (Vorausrechnung) abgelehnt. Im Gegenlauf blieben beide auf valid_with_warnings. Seitdem melden wir sie als Warnung und lassen den Anwender entscheiden. Lehre daraus: Eine Positivliste in der Spezifikation sagt nichts darüber, wie hart der Validator urteilt. Das muss man ausprobieren.

6. Die Profilfalle: MINIMUM und BASIC WL

ZUGFeRD kennt mehrere Profile, und zwei davon sind eine Falle. MINIMUM und BASIC WL tragen nur einen Auszug der Rechnungsdaten, ohne Positionen. Damit stehen die umsatzsteuerlichen Pflichtangaben nicht vollständig im strukturierten Teil — und genau das verlangt das BMF-Schreiben vom 15.10.2025. Eine solche Datei ist keine E-Rechnung im Sinne des § 14 UStG, so hübsch die PDF auch aussieht.

7. Welche Version gerade gilt

Stand 29. Oktober 2026, beide direkt bei der herausgebenden Stelle nachgesehen:

Für Sie als Rechnungssteller ändert sich dadurch fast nie etwas, und das ist der eigentliche Punkt dieses Abschnitts. Die Bugfix-Bundles betreffen die technischen Komponenten, vor allem den Validator; der Standard selbst bleibt unverändert. Im Dokument steht ohnehin die Guideline, nicht die Bundle-Nummer. Wichtig wird die Versionsfrage erst mit der XRechnung 4.0, weil dahinter eine überarbeitete EN 16931 steht — und die liegt noch ein gutes Stück vor uns.

8. Beide Wege in finisma

In finisma ist das Format ein Feld beim Erzeugen, kein zweites Produkt. Lassen Sie es, wie es ist, entsteht eine ZUGFeRD-PDF im Profil EN 16931. Stellen Sie es auf XRechnung um, kommt das reine XML mit den beiden Kennungen aus Abschnitt 4 — und die acht Pflichtangaben werden vorher geprüft, mit deutschen Meldungen statt Regelcodes, bevor überhaupt eine Datei entsteht. Eine fehlende Telefonnummer sehen Sie also im Formular und nicht erst im Rechnungsportal.

Den umgekehrten Weg gibt es auch: Wenn Sie eine XRechnung erhalten haben und ein Sichtdokument brauchen, etwa für DATEV Unternehmen Online, macht XRechnung in ZUGFeRD umwandeln daraus eine lesbare PDF, ohne die Original-XML anzutasten.

Wann die Pflicht für wen greift, steht in E-Rechnung 2027 für KMU. Wie gültige und ungültige Dateien konkret aussehen, zeigt E-Rechnung Beispiele mit Dateien zum Herunterladen.

9. Häufige Fragen

Quellen und Einordnung

Versionsstände der XRechnung: KoSIT/XStandards Einkauf, „Versionen und Bundles der XRechnung“, abgerufen am 29.10.2026. ZUGFeRD 2.5.2 und die Beschreibung des hybriden Formats: FeRD, „Was ist ZUGFeRD?“ und das Infopaket vom 04.08.2026. Profile MINIMUM und BASIC WL: BMF-Schreiben vom 15.10.2025 zur obligatorischen E-Rechnung. Norm: EN 16931 von 2017, PDF/A-3 nach ISO 19005-3:2012, Aufbewahrungsfrist acht Jahre nach § 14b Abs. 1 S. 1 UStG. Die Regelcodes in Abschnitt 3 und die beiden Fehler in Abschnitt 5 stammen aus unserem eigenen Gegenlauf gegen den KoSIT-Validator am 07.09.2026; die XML-Ausschnitte sind die Ausgabe unseres Generators. Der Beitrag ersetzt keine steuerliche Beratung und nicht die Vorgaben Ihres Rechnungsempfängers.