← E-Rechnung mit Inkvoice

XRechnung oder ZUGFeRD? Der Unterschied an echten Dateien und Prüfberichten

· Barış Çelik · Read this post in English

  • erechnung
  • xrechnung
  • zugferd
  • validator
  • opensource

XRechnung und ZUGFeRD sind die beiden Formate, mit denen die meisten Unternehmen in Deutschland E-Rechnungen schreiben werden. Beide folgen der europäischen Norm EN 16931 und gelten damit als E-Rechnung. Trotzdem unterscheiden sie sich darin, was Ihr Kunde bekommt und welche Angaben Pflicht sind. Dieser Beitrag zeigt den Unterschied an derselben Rechnung in beiden Formaten, erstellt mit Inkvoice und mit dem offiziellen Validator geprüft. Alle Dateien finden Sie im Beispielpaket.

Die kurze Antwort

ZUGFeRD XRechnung
Was Sie senden Ein PDF mit der XML darin (PDF/A-3) Nur XML
Wer es lesen kann Menschen (PDF) und Software (XML) Software oder ein Anzeigeprogramm
XML-Syntax UN/CEFACT CII UBL oder CII (Inkvoice nutzt UBL)
Typischer Empfänger Unternehmen Behörden mit Leitweg-ID
Gilt als E-Rechnung Ab Version 2.0.1, nicht in den Profilen MINIMUM und BASIC-WL Ja

Ist Ihr Kunde ein Unternehmen, ist ZUGFeRD meist die sichere Wahl: Die Buchhaltung kann das PDF öffnen, die Software liest die XML. Ist Ihr Kunde eine Behörde, verlangt sie in der Regel eine XRechnung und nennt Ihnen eine Leitweg-ID.

Dieselbe Rechnung, zwei Dateien

Unsere Beispielrechnung geht über 1.960 Euro netto mit 19 % Umsatzsteuer an ein deutsches Unternehmen. In der XRechnung sagen die ersten Zeilen, welchem Standard die Datei folgt. Danach wählt der Validator seine Regeln:

<cbc:CustomizationID>urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0</cbc:CustomizationID>
<cbc:ID>INV-2026-0002</cbc:ID>
<cbc:IssueDate>2026-11-02</cbc:IssueDate>
<cbc:DueDate>2026-11-16</cbc:DueDate>
<cbc:BuyerReference>INV-2026-0002</cbc:BuyerReference>

Die XML im ZUGFeRD-PDF sagt dasselbe in einer anderen Syntax. Ihre Kennung ist die der reinen EN 16931, das ZUGFeRD-Profil heißt ebenfalls EN 16931 (früher COMFORT):

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

Ein falsches Zeichen in dieser ersten Zeile, und der Validator erkennt die Datei gar nicht. Das ist uns passiert: Unsere XRechnungen vor Inkvoice 0.3.4 nutzten eine veraltete Form der Kennung, und der Validator meldete bei jeder Datei „kein passendes Szenario“.

Was ein echtes ZUGFeRD-PDF ausmacht

Ein PDF mit angehängter XML ist nicht automatisch ZUGFeRD. Das Format verlangt:

  • eine PDF/A-3-Datei, die Archivvariante von PDF, die Anhänge erlaubt. Alle Schriften müssen eingebettet sein, und die Farben brauchen ein festgelegtes Profil;
  • die XML als factur-x.xml angehängt und als alternative Form des Dokuments gekennzeichnet;
  • XMP-Metadaten, die Lesern sagen, dass das PDF eine Factur-X/ZUGFeRD-Rechnung enthält, in welchem Profil und unter welchem Dateinamen.

Leseprogramme suchen genau diese Metadaten. Fehlen sie, meldet ein Validator wie Mustang „keine ZUGFeRD-XML gefunden“, obwohl der Anhang da ist. Auch das haben wir auf die harte Tour gelernt; Inkvoice 0.3.4 schreibt alle drei Teile.

Was XRechnung zusätzlich zur EN 16931 verlangt

XRechnung ist die deutsche Spezifikation („CIUS“) zur EN 16931. Sie macht einige Angaben zur Pflicht, die die Norm offenlässt. Das sind die Regeln, an denen unsere eigenen ersten Dateien gescheitert sind, mit den Regelnummern, die der Validator ausgibt:

Regel Was sie verlangt
BR-DE-1 Zahlungsanweisungen, etwa eine SEPA-Überweisung mit Ihrer IBAN
BR-DE-15 Eine Käuferreferenz (BT-10). Behörden nennen Ihnen ihre Leitweg-ID; bei Unternehmen genügt eine beliebige Referenz
BR-DE-5, 6, 7 Einen Ansprechpartner beim Verkäufer: Name, Telefonnummer, E-Mail-Adresse
BR-DE-3, 4 Ihre Postleitzahl und Ihren Ort
BR-DE-8, 9 Postleitzahl und Ort des Kunden
PEPPOL-EN16931-R010, R020 Eine elektronische Adresse für Sie und für den Kunden. Eine E-Mail-Adresse genügt

Keine dieser Angaben ist schwer zu liefern, aber jede einzelne lässt die ganze Datei durchfallen. Inkvoice füllt sie jetzt aus Ihren Einstellungen und zeigt beim Erstellen der E-Rechnung, was fehlt, zum Beispiel eine Telefonnummer.

Zahlungsanweisungen sehen in der XRechnung so aus:

<cac:PaymentMeans>
  <cbc:PaymentMeansCode>58</cbc:PaymentMeansCode>
  <cbc:PaymentID>INV-2026-0002</cbc:PaymentID>
  <cac:PayeeFinancialAccount>
    <cbc:ID>DE02120300000000202051</cbc:ID>
    <cbc:Name>Anna Beispiel</cbc:Name>
  </cac:PayeeFinancialAccount>
</cac:PaymentMeans>

Code 58 steht für SEPA-Überweisung. Alle Daten in den Beispielen sind Testdaten.

Sonderfälle, auf die die Norm achtet

Einige alltägliche Rechnungen brauchen in beiden Formaten besondere Sorgfalt:

  • 7 % Umsatzsteuer ist keine eigene Kategorie: Sie steht in der Kategorie S („standard rated“) mit 7 %. Die Kategorie AA scheitert an der Codeliste.
  • Rabatte auf die ganze Rechnung müssen je Steuersatz aufgeteilt werden; die Bemessungsgrundlage ist Positionen minus Rabatt. Die Umsatzsteuer wird dann auf den rabattierten Betrag berechnet.
  • Gutschriften haben den Typ 381 und positive Beträge; der Typ sagt, dass es eine Gutschrift ist.
  • Reverse Charge (§ 13b UStG) braucht die Kategorie AE und einen Befreiungsgrund, etwa VATEX-EU-AE.
  • Kleinunternehmer nutzen die Kategorie E mit einem Grund wie „Kleinunternehmer gemäß § 19 UStG“.

Zu jedem dieser Fälle gibt es eine Beispieldatei im Paket.

So funktioniert die Prüfung

Der KoSIT-Validator ist das Referenzwerkzeug der Koordinierungsstelle für IT-Standards. Mit der XRechnung-Konfiguration (wir nutzen 3.0.2 vom 31. August 2026) macht er drei Dinge:

  1. Er liest die CustomizationID beziehungsweise die Kennung und wählt ein Szenario: XRechnung UBL, XRechnung CII oder reine EN 16931.
  2. Er prüft das XML-Schema: Elementnamen und ihre Reihenfolge.
  3. Er prüft die Geschäftsregeln (Schematron): die Regeln der EN 16931 und bei der XRechnung zusätzlich die deutschen von oben.

Das Ergebnis ist ein Prüfbericht, der empfiehlt, die Datei anzunehmen oder abzulehnen. Für die PDF-Seite prüft Mustang das PDF/A (mit veraPDF) und die eingebettete XML.

Inkvoice führt beides bei jeder Änderung am E-Rechnungs-Code für 27 Beispielrechnungen aus. Stand heute: 27 von 27 vom KoSIT-Validator akzeptiert, 13 von 13 ZUGFeRD-PDFs in Mustang gültig. Sie können den Prüfbericht XRechnung und den Prüfbericht ZUGFeRD öffnen oder alle Dateien mit Berichten herunterladen und selbst prüfen.

Was sollten Sie nehmen?

  • Geschäftskunden: ZUGFeRD, sofern der Kunde nichts anderes verlangt.
  • Behörden: XRechnung mit deren Leitweg-ID.
  • Im Zweifel: Fragen Sie Ihren Kunden. Seine Buchhaltungssoftware entscheidet, was sie einlesen kann.

Wie Sie beides in Inkvoice einrichten, steht in E-Rechnung mit Inkvoice erstellen und senden. Die Fristen finden Sie in E-Rechnungspflicht: Fristen und Ausnahmen.

Quellen