E-Rechnung validieren: Wie EN 16931, XRechnung, ZUGFeRD, Peppol und UStG zusammenspielen

Das Schichtenmodell auf einen Blick

Vorab: Was heißt eigentlich „Schema-Prüfung“ und „Schematron“?

In jedem Prüfbericht tauchen zwei Begriffe auf: Schema (XSD) und Schematron. Beides sind Prüftechniken für XML – aber sie beantworten völlig unterschiedliche Fragen.

Schema-Prüfung (XSD): Ist das Formular richtig aufgebaut?

Ein XML-Schema (XSD, XML Schema Definition) beschreibt den Bauplan eines XML-Dokuments. Es legt fest, welche Elemente es gibt und wie sie heißen, in welcher Reihenfolge und Verschachtelung sie stehen, wie oft sie vorkommen dürfen und welchen Datentyp ein Wert hat (Datum, Dezimalzahl, Text).

Die Analogie: Das Schema prüft, ob ein Formular die richtigen Kästchen an der richtigen Stelle hat und ob im Datumsfeld ein Datum steht. Es prüft nicht, ob die Angaben zusammenpassen.

Ein Beispiel, das die Schema-Prüfung ablehnt:

<cbc:IssueDate>13.10.2026</cbc:IssueDate>   <!-- falsch: XSD erwartet 2026-10-13 -->

Ein Beispiel, das die Schema-Prüfung durchwinkt, obwohl es falsch ist:

<cbc:LineExtensionAmount currencyID="EUR">100.00</cbc:LineExtensionAmount>
<cbc:TaxExclusiveAmount currencyID="EUR">250.00</cbc:TaxExclusiveAmount>
<!-- Summen passen nicht zusammen – dem Schema ist das egal -->

Die XSD-Dateien kommen von den Herausgebern der Syntax: OASIS für UBL, UN/CEFACT für CII. Sie sind für die ganze Welt gleich – egal ob die Rechnung in Deutschland, Frankreich oder Norwegen verwendet wird.

Schematron: Ergeben die Inhalte fachlich Sinn?

Schematron ist eine ISO-standardisierte Regelsprache (ISO/IEC 19757-3), mit der man inhaltliche Bedingungen über ein XML-Dokument formuliert. Jede Regel besteht aus einem Kontext (wo im Dokument geprüft wird, per XPath), einer Bedingung, einer Meldung mit Regel-ID und einem Schweregrad (fatal/Error oder Warning).

So sieht eine vereinfachte Schematron-Regel aus, hier BR-CO-10 aus der EN 16931:

<rule context="/ubl:Invoice/cac:LegalMonetaryTotal">
  <assert id="BR-CO-10" flag="fatal"
    test="cbc:LineExtensionAmount =
          sum(/ubl:Invoice/cac:InvoiceLine/cbc:LineExtensionAmount)">
    [BR-CO-10] Sum of Invoice line net amount (BT-106) =
    Σ Invoice line net amount (BT-131).
  </assert>
</rule>

Übersetzt: „Die Gesamtsumme der Positionen muss gleich der Summe aller einzelnen Positionsbeträge sein.“ Genau das kann ein XSD nicht ausdrücken. Schematron kann also:

• Werte miteinander vergleichen (Summen, Steuerbeträge, Rundung)
• bedingte Pflichtfelder prüfen („wenn USt-Kategorie Reverse Charge, dann muss die Käufer-USt-IdNr. vorhanden sein“)
• Codelisten abgleichen (ist EUR ein gültiger ISO-4217-Code?)
• Kardinalitäten verschärfen, die das XSD offen lässt – im CII-Schema ist fast alles optional, erst Schematron macht z. B. die Rechnungsnummer zur Pflicht

Warum es beides braucht

Der entscheidende Punkt: Das XSD ist für alle gleich – die Unterschiede zwischen EN 16931, XRechnung, Peppol und den ZUGFeRD-Profilen stecken fast vollständig im Schematron. Eine XRechnung und eine Peppol-Rechnung in UBL bestehen dasselbe Schema. Was sie unterscheidet, sind die zusätzlichen Schematron-Regeln (BR-DE-… bzw. PEPPOL-…), die auf die EN-16931-Regeln draufgelegt werden.

Und noch eine Grenze gilt für beide: Weder XSD noch Schematron schauen außerhalb des Dokuments nach. Ob eine USt-IdNr. existiert oder eine IBAN zum Lieferanten gehört, kann keine der beiden Techniken wissen – dafür braucht es die Stammdaten-Prüfungen in Schicht ⑥.

① Die rechtliche Basis: UStG §14

Ganz oben steht nicht ein technischer Standard, sondern das Umsatzsteuergesetz. Seit dem Wachstumschancengesetz definiert §14 Abs. 1 UStG die E-Rechnung als Rechnung in einem strukturierten elektronischen Format, das der EN 16931 entspricht – oder in einem anderen Format, sofern es die korrekte und vollständige Extraktion der Angaben in ein EN-16931-konformes Format ermöglicht.

Damit verweist das Gesetz auf die Norm – die Norm selbst kennt aber die deutschen Pflichtangaben nach §14 Abs. 4 UStG nicht im Detail. Genau hier entsteht die erste Lücke:

Konsequenz: Eine Rechnung kann technisch einwandfrei EN-16931-valide sein und trotzdem den Vorsteuerabzug des Empfängers gefährden – etwa wenn das Leistungsdatum fehlt. Kein Schematron der Welt prüft, ob eine Rechnungsnummer fortlaufend ist oder ob die Leistungsbeschreibung „handelsüblich“ genug ist. Die vollständige Liste finden Sie in unserer Checkliste der Pflichtangaben.

② Die Semantik: EN 16931 – das Herzstück

Die EN 16931-1 ist ein semantisches Datenmodell. Sie sagt nicht, wie das XML aussieht, sondern welche Informationen eine Rechnung enthält und wie sie zusammenhängen:

• Business Terms (BT): rund 160 einzelne Informationselemente, z. B. BT-1 Rechnungsnummer, BT-31 USt-IdNr. des Verkäufers, BT-84 IBAN
• Business Groups (BG): logische Gruppen, z. B. BG-4 Verkäufer, BG-23 Umsatzsteueraufschlüsselung, BG-25 Rechnungsposition
• Business Rules (BR): Regeln, die gegen diese Elemente prüfen

Die Business Rules teilen sich in Familien:

Wogegen wird geprüft? Gegen die Werte im Dokument selbst – also interne Konsistenz. Die EN 16931 prüft, ob die Summen aufgehen, ob zu jeder USt-Kategorie eine Aufschlüsselung existiert und ob Pflichtfelder gefüllt sind. Sie prüft nicht, ob die Werte in der realen Welt stimmen.

Technisch werden die Regeln als Schematron ausgeliefert (CEN/TC 434, Validation Artefacts), jeweils in einer Variante für UBL und für CII. Welche BT-Felder wofür stehen, zeigt unser Leitfaden zu den BT-Feldern; was sich mit der EN 16931 in 2026 ändert, steht im Beitrag zu EN 16931:2026, XRechnung 4.0 und ViDA.

③ Die Syntax: UBL oder CII

Die EN 16931 kennt zwei gleichwertige Syntaxen (EN 16931-3):

• UBL 2.1 (OASIS) – international verbreitet, Standard im Peppol-Netz
• UN/CEFACT CII D16B – Basis von ZUGFeRD/Factur-X

Geprüft wird hier per XSD-Schema: Ist das XML wohlgeformt, stehen die Elemente an der richtigen Stelle, haben Datum und Betrag den richtigen Datentyp? Das Syntax-Binding übersetzt die semantischen BTs in konkrete XPaths. Beispiel BT-1 Rechnungsnummer:

Merke: XSD-valide heißt nur „strukturell korrektes XML“. Ein CII-Dokument ohne Rechnungsnummer, ohne Käufer und mit falschen Summen kann das Schema problemlos bestehen.

④ Die Spezialisierungen: XRechnung, Peppol, ZUGFeRD

Die EN 16931 ist bewusst offen gehalten. Länder und Netzwerke dürfen sie per CIUS (Core Invoice Usage Specification) einschränken – also Felder zur Pflicht machen, Codelisten verengen, Wertebereiche begrenzen. Erweitern dürfen sie nur über offizielle Extensions.

XRechnung (KoSIT)

Die XRechnung ist der deutsche CIUS, herausgegeben von der KoSIT in Bremen. Sie ergänzt die EN-Regeln um die BR-DE-xx-Regeln, z. B.:

Geprüft wird mit dem KoSIT-Validator und der jeweiligen Validator-Konfiguration für die gültige XRechnung-Version. Der Prüfbericht unterscheidet zwischen Error (Ablehnung) und Warning (Hinweis). Die XRechnung gibt es in beiden Syntaxen – UBL und CII. Sie ist im öffentlichen Auftragswesen (B2G) Pflichtformat und im B2B-Bereich als „reine“ XML-Rechnung verbreitet. Die typischen Meldungen und ihre Lösung zeigt unsere Übersicht der häufigsten Validierungsfehler.

ZUGFeRD / Factur-X (FeRD, FNFE)

ZUGFeRD ist ein hybrides Format: ein PDF/A-3 für das menschliche Auge, darin eingebettet eine CII-XML-Datei (factur-x.xml). Inhaltlich ist ZUGFeRD identisch mit dem französischen Factur-X. Entscheidend sind die Profile – sie bestimmen, wie viel strukturierte Information im XML steckt:

Jedes Profil hat eigene Schematron-Regeln, die zusätzlich zu den EN-Regeln greifen. Und es kommt eine eigene Prüfebene hinzu: das PDF selbst (siehe Schicht ⑤). Mehr zu den Grenzen von BASIC WL steht in unserem Beitrag ZUGFeRD BASIC WL, die Formatwahl erklärt XRechnung vs. ZUGFeRD.

Peppol BIS Billing 3.0 (OpenPeppol)

Peppol ist zweierlei: ein Dokumentstandard und ein Transportnetz. Als Dokumentstandard ist Peppol BIS Billing 3.0 ebenfalls ein CIUS der EN 16931 (in der Regel UBL) mit eigenen Regeln:

• PEPPOL-EN16931-Rxxx: netzweite Regeln, z. B. R001 (Business Process muss angegeben sein), R008 (keine leeren Elemente)
• Länderspezifische Regeln (z. B. NO-R-, DK-R-, SE-R-), die nur greifen, wenn der Verkäufer aus dem jeweiligen Land kommt

Eine XRechnung kann über Peppol transportiert werden – sie wird dann gegen die XRechnung-Regeln geprüft, nicht gegen Peppol BIS. Welche Regeln greifen, steuert die CustomizationID im Dokument.

⑤ Container und Transport

Diese Schicht prüft nicht den Rechnungsinhalt, sondern das „Drumherum“.

Ein klassischer Fehler bei ZUGFeRD: Das XML ist perfekt, aber die XMP-Metadaten deklarieren ein anderes Profil – der Validator des Empfängers lehnt ab. Bei Peppol validiert der sendende Access Point das Dokument vor dem Versand; ein ungültiges Dokument kommt gar nicht erst im Netz an.

⑥ Stammdaten und Plausibilität: VIES, IBAN & Co.

Hier liegt die Ebene, die die meisten Validatoren nicht abdecken – und die in der Praxis die teuersten Fehler verursacht. Schematron prüft Struktur und interne Konsistenz. Ob ein Wert in der echten Welt existiert, kann es nicht wissen.

USt-IdNr.: Format vs. Existenz

Besonders kritisch bei innergemeinschaftlichen Lieferungen (USt-Kategorie K, BR-IC-Regeln) und Reverse Charge (AE): Die EN 16931 verlangt nur, dass die USt-IdNr. des Käufers vorhanden ist. Ob sie gültig ist, entscheidet aber über die Steuerfreiheit nach §6a UStG – die gültige USt-IdNr. des Erwerbers ist seit 2020 materielle Voraussetzung.

IBAN: Prüfsumme statt Präsenz

Die EN 16931 prüft bei SEPA-Überweisung (Zahlungsart 58) im Wesentlichen, dass eine Kontokennung angegeben ist. Ob die IBAN stimmt, ist eine eigene Prüfung:

• Struktur je Land (DE: 22 Zeichen)
• Prüfziffer nach ISO 13616 / Modulo 97 – fängt Zahlendreher zuverlässig ab
• optional: BIC-Plausibilität und Abgleich mit dem Lieferantenstamm (Schutz vor Rechnungsbetrug durch geänderte Bankverbindungen)

Weitere Stammdaten-Checks

• Leitweg-ID: Aufbau und Prüfziffer (ebenfalls Modulo 97-10) – entscheidend für die Zustellung im B2G
• Codelisten: Rechnungstyp (UNTDID 1001: 380 Rechnung, 381 Gutschrift/Korrektur, 384 korrigierte Rechnung, 389 Gutschriftsverfahren), Zahlungsart (UNTDID 4461), USt-Kategorie (UNTDID 5305), Einheiten (UN/ECE Rec. 20), elektronische Adressen (EAS)
• Bestellnummer, Lieferantennummer, Kostenstelle: Abgleich gegen das ERP des Empfängers – keine Norm-, aber eine Prozessanforderung

Was wird gegen was geprüft? Die Matrix

Die richtige Prüfreihenfolge

Ein sauberer Validierungsprozess arbeitet die Schichten von außen nach innen ab und bricht früh ab, wenn eine Basis-Schicht scheitert:

1. 1

   Container: Ist es ein PDF/A-3 mit eingebettetem XML – oder reines XML?

2. 2

   Syntax erkennen: UBL oder CII? Welche CustomizationID, welches Profil?

3. 3

   XSD: Strukturell gültig? Wenn nein: Abbruch, weitere Regeln sind sinnlos.

4. 4

   EN 16931 Schematron: Pflichtfelder, Rechenregeln, USt-Logik.

5. 5

   CIUS-Schematron: XRechnung (BR-DE), Peppol BIS oder ZUGFeRD-Profilregeln – passend zur deklarierten Kennung.

6. 6

   Stammdaten: USt-IdNr. per VIES, IBAN-Prüfziffer, Leitweg-ID, Abgleich mit Lieferanten- und Bestellstamm.

7. 7

   Steuerliche Plausibilität: Leistungsdatum, Steuerbefreiungshinweis, Dubletten, Gutschriftskennzeichnung.

Die Schritte 1–5 sind standardisiert und deterministisch. Die Schritte 6–7 entscheiden in der Praxis darüber, ob die Rechnung durch die Buchhaltung läuft – oder als Rückfrage zurückkommt.

Fazit: „Valide“ ist immer eine Aussage über eine Schicht

Wer eine E-Rechnung prüft, sollte immer sagen, wogegen: XSD-valide, EN-16931-konform, XRechnung-konform, Peppol-konform – oder steuerlich vollständig. Die Schichten bauen aufeinander auf, aber keine ersetzt die andere. Die größten Risiken liegen dort, wo die standardisierten Validatoren aufhören: bei Stammdaten wie USt-IdNr. und IBAN und bei den Pflichtangaben des UStG, die die Norm nicht erzwingt.

So prüft rechnungsapi.de

rechnungsapi.de validiert XRechnung (UBL und CII) und ZUGFeRD/Factur-X über die technischen Schichten in einem API-Aufruf:

Wie Sie die Prüfung per KI-Assistent aufrufen, beschreibt unser Beitrag zum MCP-Server und SDK.

Häufige Fragen

Quellen

§14 UStG in der Fassung des Wachstumschancengesetzes; BMF-Schreiben zur E-Rechnung vom 15.10.2024; EN 16931-1 und EN 16931-3 (CEN/TC 434) mit Validation Artefacts; XRechnung-Spezifikation und KoSIT-Validator (xeinkauf.de); ZUGFeRD 2.x / Factur-X (FeRD, FNFE-MPE); Peppol BIS Billing 3.0 (OpenPeppol); ISO/IEC 19757-3 (Schematron); ISO 13616 (IBAN); VIES (EU-Kommission).