XRechnung oder ZUGFeRD: Das richtige Format wählen (und die Profile, die scheitern)
Die Pflicht akzeptiert XRechnung und ZUGFeRD, aber nicht jedes ZUGFeRD. Die Profile Minimum und Basic-WL erfüllen EN 16931 nicht. So wählen Sie richtig und validieren vor dem Versand.
XRechnung oder ZUGFeRD: Das richtige Format wählen (und die Profile, die scheitern)
Die deutsche E-Rechnungspflicht schreibt kein einzelnes Format vor. Sie schreibt einen Standard vor: EN 16931. Zwei Formate dominieren den konformen Raum. Die Wahl zwischen ihnen ist eine Workflow-Entscheidung, keine Compliance-Entscheidung. Die Wahl des falschen ZUGFeRD-Profils ist ein Compliance-Fehler.
Die zwei Formate
XRechnung
Der deutsche Standard: eine rein strukturierte XML-Datei, definiert als deutsche Core Invoice Usage Specification (CIUS) von EN 16931. Verfügbar in zwei Syntaxen, beide gleichwertig:
- UBL (Universal Business Language)
- UN/CEFACT CII (Cross Industry Invoice)
XRechnung ist maschinenzentriert. Es gibt keine lesbare Ebene; die Visualisierung erzeugt die Empfängersoftware. Für B2G-Rechnungen an die Bundesverwaltung ist XRechnung seit 2020 Pflicht, was es zum Standard in Branchen mit öffentlichen Auftraggebern macht.
ZUGFeRD
Ein Hybridformat: ein lesbares PDF/A-3 mit eingebetteter XML-Datei. Der Empfänger sieht eine normale Rechnung; seine Software extrahiert das XML.
Für die Pflicht muss ZUGFeRD in Version 2.0.1 oder höher mit einem EN-16931-konformen Profil vorliegen:
- Profil EN 16931 (Comfort): voll konform
- Profil Extended: konform, enthält zusätzliche Daten über den Standard hinaus
- Profil XRechnung: das XRechnung-Datenmodell im Hybrid-Container
Die Profil-Falle
ZUGFeRD wird in Profilen mit unterschiedlichem Dateninhalt ausgeliefert. Zwei davon scheitern an der Pflicht:
| Profil | Konform? | Grund |
|---|---|---|
| Minimum | Nein | Unzureichender Dateninhalt für EN 16931 |
| Basic-WL | Nein | Unzureichender Dateninhalt für EN 16931 |
| Basic | Nein | Unterhalb der EN-16931-Anforderungen |
| EN 16931 (Comfort) | Ja | Volle Standardkonformität |
| Extended | Ja | EN 16931 plus Erweiterungen |
Eine Rechnung im Profil Minimum oder Basic-WL ist eine "sonstige Rechnung": Rechtlich ist sie keine E-Rechnung. Nach den Übergangsfristen bringt sie dem Empfänger keinen Vorsteuerabzug. Die Falle: Die Datei sieht trotzdem aus wie eine normale Rechnungs-PDF. Niemand bemerkt es, bis eine Validierung oder eine Prüfung kommt.
Der Entscheidungsrahmen
| Ihre Situation | Passendes Format |
|---|---|
| Maximale Automatisierung; Kunden sind Konzerne oder öffentliche Hand | XRechnung |
| Empfänger sind auch kleine Betriebe, die Rechnungen manuell lesen | ZUGFeRD (Profil EN 16931) |
| Sie beliefern öffentliche Auftraggeber | XRechnung (für B2G bereits Pflicht) |
| Interoperabilität über viele Partner und Länder | XRechnung UBL oder Peppol BIS 3.0 |
| Bestehende EDI-Verbindungen mit Volumen | EN-16931-kompatibles EDI-Mapping (Übergang) |
Der hybride Charakter von ZUGFeRD ist sein echter Vorteil: Eine Datei dient dem Auge und der Software des Buchhalters. Das reine XML von XRechnung ist sein Vorteil: Keine Mehrdeutigkeit, welche Ebene maßgeblich ist. Beachten Sie: Nach GoBD ist in beiden Fällen der strukturierte Teil der maßgebliche Datensatz.
Vor dem Versand validieren
Das Mandat unterscheidet zwei Fehlerarten:
- Formatfehler: Die Datei verletzt die Syntax oder technische Vorgaben. Eine formal fehlerhafte E-Rechnung ist keine E-Rechnung im Sinne des § 14 Abs. 1 Satz 6 UStG; der Vorsteuerabzug besteht nur während der Übergangsfristen.
- Geschäftsregelfehler: Das XML ist wohlgeformt, verletzt aber logische Regeln. Der Klassiker: Das Pflichtfeld BT-10 (Buyer Reference) ist in einer XRechnung leer. Oder: Der ausgewiesene Steuerbetrag stimmt rechnerisch nicht. Validatoren melden diese als kritische Fehler.
Der KoSIT-Validator ist das Referenzwerkzeug. Der Workflow:
- Erzeugen Sie eine Testrechnung aus Ihrem Produktivsystem, nicht aus einer Testvorlage.
- Prüfen Sie sie mit dem KoSIT-Validator.
- Beheben Sie Fehler an der Datenquelle (Stammdaten, Rechnungslogik), nicht per Hand im XML.
- Erneut validieren, dann versenden.
Die BStBK empfiehlt Empfängern, jede eingehende E-Rechnung ebenso zu prüfen: Syntax, Semantik und Konformität mit nationalen Erweiterungen. Eine ungültige erhaltene Rechnung ist ein Thema für den sofortigen Kontakt mit dem Aussteller, nicht für die stille Buchung.
Häufige Fehler
"ZUGFeRD" mit konform gleichsetzen. Das Profil entscheidet. Prüfen Sie, welches Profil Ihre Software tatsächlich erzeugt.
Die PDF-Ebene eines ZUGFeRD von Hand bearbeiten. Sichtebene und XML müssen übereinstimmen. Wer eine Ebene ändert, desynchronisiert die Datei; der strukturierte Teil ist der rechtlich relevante.
Validierung als Problem des Empfängers behandeln. Ein Formatfehler auf einer Rechnung, die Sie nach Ihrem Pflichtdatum ausstellen, ist Ihr Compliance-Fehler und das Vorsteuerproblem Ihres Kunden.
BT-10 vergessen. Unternehmen und öffentliche Auftraggeber steuern Rechnungen über die Buyer Reference. Fehlt sie, gibt es Ablehnungen, selbst wenn das XML technisch valide ist.
Dieses Material dient der allgemeinen Information und stellt keine Rechts- oder Steuerberatung dar. Prüfen Sie im Einzelfall die aktuellen Regelungen oder konsultieren Sie einen qualifizierten Berater.