Grundlagen der E-Rechnung

Zuletzt geprüft am 26. September 2026.

Eine strukturierte E-Rechnung enthält Daten, die Software direkt lesen kann. Das kann eine XML-Datei sein oder, bei Formaten wie ZUGFeRD / Factur-X, XML, das in ein lesbares PDF eingebettet ist. Dieser Leitfaden erklärt die beteiligten Bausteine, wie sie zusammenhängen und was ein Validator aussagen kann und was nicht. Er richtet sich an Entwicklungs- und Finanzteams, die zum ersten Mal mit der E-Rechnung zu tun haben.

Im Kern geht es um drei Gedanken:

• Ein Format legt fest, wie die Daten geschrieben werden, etwa UBL oder CII.
• Ein Standard legt fest, was sie bedeuten: EN 16931 bestimmt, was eine europäische Rechnung aussagen muss.
• Zusätzliche Regeln gelten in bestimmten Zusammenhängen: im Peppol-Netzwerk, bei Rechnungen an deutsche öffentliche Auftraggeber oder in einem Profil von ZUGFeRD / Factur-X.

Die drei Formate im Überblick

Der Rest dieses Leitfadens erklärt, was hinter jeder Spalte steht, und danach die genauen Kennungen und Versionen.

Was eine Rechnung strukturiert macht

Ein PDF oder ein gescanntes Bild sieht für einen Menschen wie eine Rechnung aus, doch ein Programm muss raten, wo die Rechnungsnummer, die Summen und die Umsatzsteuer stehen. Eine strukturierte Rechnung gibt jeden Wert in einem benannten Element an: die Rechnungsnummer in einem Element, jede Position mit Menge, Preis und Nettobetrag, die Umsatzsteueraufschlüsselung, die Summen sowie Verkäufer und Käufer mit Kennungen wie der Umsatzsteuer-Identifikationsnummer.

Weil Struktur und Bedeutung vorab vereinbart sind, kann der Empfänger die Rechnung direkt einlesen, prüfen und einer Bestellung zuordnen.

<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"
    xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
    xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2">
    <cbc:CustomizationID>urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0</cbc:CustomizationID>
    <cbc:ProfileID>urn:fdc:peppol.eu:2017:poacc:billing:01:1.0</cbc:ProfileID>
    <cbc:ID>EX-2026-0001</cbc:ID>
    <cbc:IssueDate>2026-06-15</cbc:IssueDate>
    <cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>
    <cbc:DocumentCurrencyCode>GBP</cbc:DocumentCurrencyCode>
    <!-- the supplier, the customer, the invoice lines and the VAT breakdown -->
    <cac:LegalMonetaryTotal>
        <cbc:LineExtensionAmount currencyID="GBP">740.00</cbc:LineExtensionAmount>
        <cbc:TaxExclusiveAmount currencyID="GBP">740.00</cbc:TaxExclusiveAmount>
        <cbc:TaxInclusiveAmount currencyID="GBP">888.00</cbc:TaxInclusiveAmount>
        <cbc:PayableAmount currencyID="GBP">888.00</cbc:PayableAmount>
    </cac:LegalMonetaryTotal>

Syntax, Semantik und Anwendungsregeln

Drei Ebenen beantworten drei verschiedene Fragen zu einer E-Rechnung.

Syntax: Wie ist sie geschrieben?

Die Syntax ist das XML-Vokabular: die Namen der Elemente, ihre Reihenfolge und ihre Datentypen. In Europa sind zwei Syntaxen maßgeblich: UBL 2.1 (Universal Business Language) und die UN/CEFACT Cross Industry Invoice (CII). Eine Schemaprüfung (XSD) sagt Ihnen, ob ein Dokument in seiner Syntax wohlgeformt ist, nicht aber, ob es eine vollständige Rechnung ist.

Semantisches Modell: Was muss sie aussagen?

EN 16931, die europäische Norm für die elektronische Rechnungsstellung, definiert das Kernmodell der Rechnung: die Informationen, die eine Rechnung enthält, und die Regeln zwischen ihnen. Jede Information ist ein Informationselement (Business Term) mit einer Kennung, etwa BT-1 für die Rechnungsnummer und BT-106 für die Summe der Nettobeträge der Positionen; zusammengehörige Elemente bilden Gruppen (BG-). Geschäftsregeln (BR-) müssen über sie hinweg gelten: BR-CO-10 verlangt zum Beispiel, dass BT-106 der Summe der Nettobeträge der Rechnungspositionen entspricht. EN 16931 definiert keine eigene Syntax; ihre technischen Spezifikationen binden das Modell an UBL 2.1 und an CII D16B.

Anwendungsregeln: Wie nutzt diese Gemeinschaft sie?

Eine Core Invoice Usage Specification (CIUS) passt das Kernmodell an einen bestimmten Zusammenhang an. Sie kann optionale Informationen verpflichtend machen, Codelisten einschränken und Regeln ergänzen, muss aber eine Teilmenge des Kerns bleiben und darf keine seiner Regeln verletzen. Eine Extension geht den umgekehrten Weg und ergänzt Informationen, die der Kern nicht definiert.

• Peppol BIS Billing 3 ist eine CIUS der EN 16931, definiert von OpenPeppol und in UBL geschrieben.
• XRechnung, der deutsche Standard für Rechnungen an öffentliche Auftraggeber, besteht aus der CIUS XRechnung und der Extension XRechnung.
• ZUGFeRD / Factur-X definiert Profile: Das Profil EN 16931 folgt dem Kernmodell, MINIMUM und BASIC WL enthalten weniger als eine vollständige Rechnung nach EN 16931, und EXTENDED enthält mehr.

Ein Validator arbeitet diese Ebenen der Reihe nach ab: Ist die Datei wohlgeformtes XML, entspricht sie dem Schema ihrer Syntax, gelten die Regeln der EN 16931, und gelten die Anwendungsregeln? Ironfang meldet jeden Prüfschritt einzeln, sodass sich ein ungültiges Dokument von einer Dienststörung unterscheiden lässt und Sie sehen, wo ein Problem beginnt.

Syntaxen, Kennungen und Versionen

UBL und CII können dieselben Informationen der EN 16931 mit unterschiedlichen Elementnamen transportieren. Die Rechnungsnummer ist zum Beispiel cbc:ID am Anfang einer UBL-Rechnung und ram:ID innerhalb von rsm:ExchangedDocument in CII. Jedes Dokument gibt außerdem in seiner Spezifikationskennung an, welchen Regeln es folgt: cbc:CustomizationID in UBL oder die ram:ID von ram:GuidelineSpecifiedDocumentContextParameter in CII. Validatoren wählen anhand dieser Angabe die anzuwendenden Regeln.

ZUGFeRD und Factur-X sind derselbe Standard unter zwei Namen: ZUGFeRD 2.5.2 entspricht Factur-X 1.09.2. Eine hybride Rechnung ist eine PDF/A-Datei, eine lesbare Seite mit eingebettetem Rechnungs-XML, sodass eine Datei Mensch und Programm gleichermaßen dient.

Ironfang Finance validiert diese Versionen, und jedes Ergebnis nennt die genaue Version, gegen die geprüft wurde:

• Peppol BIS Billing 3.0, das Release vom Mai 2026, für UBL-Rechnungen und -Gutschriften.
• XRechnung 3.0.2, im technischen Bundle der KoSIT vom 31. August 2026, in UBL und CII.
• ZUGFeRD 2.5.2 / Factur-X 1.09.2 in den Profilen MINIMUM, BASIC WL, BASIC, EN 16931 und EXTENDED, als PDF oder als XML. Das Profil XRECHNUNG innerhalb eines ZUGFeRD-PDF wird erkannt und als noch nicht unterstützt gemeldet, nie als etwas anderes geprüft.

Die Leitfäden zu den Formaten gehen tiefer: XRechnung und ZUGFeRD / Factur-X.

Was eine Validierung feststellt

Ein bestandenes Ergebnis bedeutet, dass das Dokument, genau so wie gesendet, zum Zeitpunkt der Prüfung jede Regel erfüllt hat, die der Validator für eine benannte Version seiner Spezifikation geprüft hat. Fehler lassen ein Dokument durchfallen; Warnungen sind lesenswert, tun das aber nicht.

Es stellt nicht fest, dass

• die Rechnung versendet, zugestellt, empfangen oder vom Käufer angenommen wurde;
• der Inhalt kaufmännisch richtig ist: Ein Validator kann prüfen, ob die Summen aufgehen, nicht aber, ob Sie den richtigen Preis berechnet haben;
• die eigenen Anforderungen des Käufers über die veröffentlichten Regeln hinaus erfüllt sind;
• die Rechnung jede rechtliche oder steuerliche Pflicht erfüllt, die für Sie gilt.

Manches liegt außerhalb dessen, was eine XML-Prüfung sehen kann. Bei einem PDF nach ZUGFeRD / Factur-X meldet Ironfang zum Beispiel, dass die sichtbare PDF-Seite nicht mit dem eingebetteten XML verglichen wurde: Nur das XML sind die Rechnungsdaten, die geprüft wurden.

Peppol als Netzwerk ist etwas anderes

"Peppol" bezeichnet zwei Dinge. Peppol BIS Billing 3 ist die oben beschriebene Dokumentspezifikation. Das Peppol-Netzwerk ist der Weg, auf dem Dokumente übermittelt werden: Organisationen senden und empfangen darüber Geschäftsdokumente über einen akkreditierten Peppol-Dienstleister ihrer Wahl, und beide Seiten brauchen nur einen Dienstleister, um alle anderen im Netzwerk zu erreichen.

Die Validierung einer Peppol-BIS-Rechnung prüft das Dokument; sie versendet es nicht. Ironfang validiert Dokumente. Ironfang versendet keine Rechnungen, betreibt keinen Peppol Access Point und registriert keine Teilnehmer im Netzwerk.

Ausprobieren: ein Beispiel prüfen und einen Fehler beheben

In wenigen Minuten kommen Sie von einer fehlerhaften zu einer korrigierten Rechnung, ohne Konto:

1. Öffnen Sie den Peppol-Validator und wählen Sie das Beispiel mit Fehlern. Das Ergebnis meldet zwei Fehler nach EN 16931 in den Rechnungssummen, BR-CO-10 und BR-CO-13.
2. Lesen Sie die Erklärung zu BR-CO-10: Die angegebene Summe der Positionsbeträge muss der Summe der Positionen entsprechen. In diesem Beispiel ergeben die Positionen 740.00, die Summe gibt aber 750.00 an.
3. Vergleichen Sie es mit dem kommentierten gültigen Beispiel, in dem cbc:LineExtensionAmount in den Summen 740.00 beträgt. Korrigieren Sie den angegebenen Betrag und validieren Sie die Datei erneut.
4. Öffnen Sie dieselbe Datei im Rechnungs-Viewer, um die UBL-Rechnung als Dokument zu lesen.

Dasselbe Vorgehen funktioniert für die anderen Familien. Der XRechnung-Validator hat ein CII-Beispiel ohne Käuferreferenz (die Leitweg-ID), die XRechnung verlangt, deshalb meldet er BR-DE-15. Der ZUGFeRD- und Factur-X-Validator hat ein Beispiel-PDF mit zwei Fehlern, einem in den PDF-Metadaten und einem im XML. Wenn ein Befund eine Regel nennt, erklärt die Regelreferenz, was sie prüft und wie Sie den Fehler beheben.

In Software einbauen

• Aus dem Code validieren: ein lauffähiger Schnellstart, der eine Beispielrechnung an die Finance API sendet und das Ergebnis liest.
• Finance API V1 und V2: welche API-Version welches Format abdeckt und wie sich die Ergebnisse unterscheiden.
• Rechnungserzeugung: eine Peppol-BIS-Rechnung in UBL aus JSON erzeugen.
• Wie die Validierung von Peppol-Rechnungen tatsächlich funktioniert (auf Englisch) und Validierungsfehler nach EN 16931 verstehen (auf Englisch): die Prüfschritte und Regelfamilien im Detail.

Den Wissensbereich zur E-Rechnung erkunden, mit weiteren Leitfäden, Tools und Beispielen, nach Aufgaben geordnet.

Quellen

Die Aussagen zu Standards auf dieser Seite wurden am 26. September 2026 anhand dieser Primärquellen geprüft:

• Europäische Kommission: "Required syntaxes": EN 16931 definiert den Inhalt, nicht die Syntax; UBL 2.1 und UN/CEFACT CII D16B sind die beiden daran gebundenen Syntaxen.
• Europäische Kommission: "EN 16931 compliance": Was eine konforme Rechnung enthalten muss, und dass eine CIUS eine Teilmenge des Kerns ist, die seine Regeln nicht verletzt.
• OpenPeppol: Peppol BIS Billing 3.0: Peppol BIS Billing 3.0 ist eine CIUS der EN 16931 in UBL; dazu ihre Spezifikations- und Geschäftsprozesskennungen.
• OpenPeppol: "For end users": Organisationen senden und empfangen über das Peppol-Netzwerk mithilfe eines akkreditierten Peppol-Dienstleisters ihrer Wahl.
• KoSIT (xeinkauf.de): XRechnung: XRechnung besteht aus der CIUS XRechnung und der Extension XRechnung, betrieben von der KoSIT für den IT-Planungsrat, in UBL 2.1 und UN/CEFACT CII.
• FeRD: ZUGFeRD / Factur-X: ZUGFeRD bettet strukturierte XML-Rechnungsdaten in ein PDF/A-3-Dokument ein und ist, gemeinsam mit der FNFE-MPE, in Frankreich Factur-X.
• FeRD: ZUGFeRD 2.5.2: ZUGFeRD 2.5.2 entspricht Factur-X 1.09.2 und basiert auf UN/CEFACT CII D22B.
• FNFE-MPE: Factur-X: Factur-X ist derselbe Standard wie ZUGFeRD, eine hybride Rechnung aus PDF und XML, mit den Profilen MINIMUM, BASIC WL, BASIC, EN16931 und EXTENDED.

Die Versionen, die Ironfang validiert, stammen aus seinem eigenen Register der Regelwerke, das jedes Ergebnis nennt. Dieser Leitfaden erklärt die Standards; er ist keine Rechts- oder Steuerberatung.