XRechnung prüfen: Ablauf, Werkzeuge und typische Fehler

ARLing s. r. o. · 25. September 2026

Die drei Stufen einer XRechnung-Prüfung

Welche Regeln gelten, steht in der Datei selbst: Das Feld CustomizationID (BT-24) nennt den Standard, bei XRechnung 3.0 endet der Wert auf xrechnung_3.0. Der KoSIT-Validator ordnet eine solche UBL-Rechnung dem Szenario „EN16931 XRechnung (UBL Invoice)“ zu und prüft sie in dieser Reihenfolge:

1. XML-Schema (XSD) von UBL 2.1: Hier geht es um die Syntax: welche Elemente in welcher Reihenfolge stehen und welche Datentypen sie haben.
2. Schematron der EN 16931: unter anderem die Kernregeln BR-01 bis BR-65, die Summenregeln BR-CO, die Codelisten BR-CL und die Regeln je Steuerkategorie wie BR-S.
3. Schematron der XRechnung: die deutschen Regeln BR-DE, zum Beispiel BR-DE-15 für die Käuferreferenz, und die aus Peppol BIS Billing 3.0 übernommenen Regeln wie PEPPOL-EN16931-R120.

Die Reihenfolge hat eine praktische Folge: In unserem Test liefen nach einem Schemafehler die beiden Schematron-Stufen nicht mehr. Als wir die Rechnungsnummer (cbc:ID) entfernt haben, meldete der KoSIT-Validator deshalb nicht die Regel BR-02, sondern einen Schemafehler vom Typ cvc-complex-type mit dem Satz „Invalid content was found starting with element“: ungültiger Inhalt ab dem Element IssueDate, erwartet wurde ProfileExecutionID oder ID, in Zeile 5, Spalte 18.

Unsere Prüfung hat keine Schemastufe und meldet denselben Fall als BR-02: „Die Rechnungsnummer (BT-1, Element cbc:ID) fehlt. Ergänzen Sie die Belegnummer.“ Steht im KoSIT-Bericht dieser Satz, hat das Schema an der Stelle des genannten Elements ein anderes erwartet, und die Meldung zählt die erwarteten Elemente auf; in unserem Fall fehlte davor das Pflichtelement cbc:ID.

So prüfen Sie eine XRechnung in fünf Schritten

1. Die XML-Datei nehmen. Geprüft wird das strukturierte XML. Bei ZUGFeRD steckt es in einem PDF/A-3 und nutzt seit Version 2.0 die Cross Industry Invoice (CII) von UN/CEFACT.
2. Das Profil ansehen. Endet CustomizationID auf xrechnung_3.0, gelten die Regeln der XRechnung; steht dort ein anderer Wert, wählt der Validator einen anderen Regelsatz oder erstellt, wenn keiner passt, nur einen Standardbericht.
3. Prüfen. Lokal mit dem KoSIT-Validator (Java 11 oder neuer) oder im Browser mit unserem XRechnung-Validator, bei dem die Datei den Rechner nicht verlässt. Unsere Prüfung wendet ihre Regeln nur auf UBL an; für CII, also auch für das XML aus einer ZUGFeRD-Datei, hat die KoSIT-Konfiguration eigene Szenarien, die greifen, wenn die Kennung im XML genau auf die EN 16931 oder auf XRechnung 3.0 lautet.
4. Erst die Fehler, dann die Warnungen. In unserem Test führte schon ein einziger Fehler zur Empfehlung, die Datei zurückzuweisen, Warnungen allein nicht.
5. An der Quelle korrigieren und neu prüfen. Eine einzige falsche Angabe kann mehrere Meldungen auslösen; prüfen Sie deshalb nach jeder Korrektur die neue Datei.

Den KoSIT-Validator laden Sie als Datei validator-1.6.3-standalone.jar von der Release-Seite des Validators, die Regeln als ZIP-Datei von der Release-Seite der XRechnung-Konfiguration. Das Release für XRechnung 3.0.2, mit dem wir getestet haben, nennt in seinen Hinweisen den Validator 1.6.3. Wir haben die ZIP-Datei in den Ordner conf entpackt; der Aufruf sah dann so aus: java -jar validator-1.6.3-standalone.jar -s conf/scenarios.xml -r conf -o out -h rechnung.xml.

Mit -h legt der Validator neben dem XML-Bericht einen lesbaren HTML-Prüfbericht ab; der Rückgabewert 0 bedeutet, dass alle geprüften Dateien als annehmbar gelten, eine positive Zahl nennt die Zahl der zurückgewiesenen.

Wer lieber im Browser arbeitet: Mit der Option -D, also java -jar validator-1.6.3-standalone.jar -s conf/scenarios.xml -r conf -D, läuft der KoSIT-Validator als kleiner Dienst auf dem eigenen Rechner, standardmäßig auf localhost mit Port 8080, und zeigt dort ein einfaches Formular für eine XML-Datei. KoSIT schreibt dazu, diese Oberfläche sei nur zum Vorführen gedacht und nicht für den produktiven Einsatz. In unserem Test antwortete der Dienst auf eine annehmbare Datei mit dem HTTP-Status 200 und auf eine zurückzuweisende mit 406.

Den Prüfbericht lesen: Fehler, Warnung, Bewertung

Der HTML-Bericht des KoSIT-Validators heißt Prüfbericht. Oben steht die Konformitätsprüfung mit der Zahl der Fehler und Warnungen, darunter eine Übersicht je Prüfstufe (val-xsd für das Schema, val-sch.1 für die EN 16931, val-sch.2 für die XRechnung) und dann jede Meldung mit Code, Grad, Text und Pfad. Am Ende steht die Bewertung, und die kannte in unserem Test nur zwei Sätze:

• „Es wird empfohlen das Dokument anzunehmen und weiter zu verarbeiten.“
• „Es wird empfohlen das Dokument zurückzuweisen.“

Entschieden hat allein der Grad der Meldungen: Jede Datei mit mindestens einem Fehler (error) bekam die Empfehlung zurückzuweisen, jede Datei nur mit Warnungen (warning) die Empfehlung anzunehmen. Ein Detail verwirrt beim ersten Lesen: Bei einer Datei mit einer einzigen Warnung stand oben „Es ist nicht konform zu den formalen Vorgaben“, unten aber die Empfehlung zur Annahme. Für Dateien, die sich gar nicht verarbeiten lassen, sieht die getestete Konfiguration laut ihren Hinweisen einen dritten Satz vor: „Das Dokument sollte nicht automatisiert angenommen werden“.

Die Texte der Regelmeldungen sind der Wortlaut aus dem Schematron: die Regeln BR-DE auf Deutsch, etwa „[BR-DE-27] In BT-42 sollen mindestens drei Ziffern enthalten sein.“, die übrigen auf Englisch, auch die aus Peppol übernommene Regel PEPPOL-EN16931-R120. Unsere Prüfung ergänzt jeden Fund um eine eigene Erklärung und den Pfad zum Element; im Test war diese Erklärung bei 13 von 14 Funden ganz deutsch, bei BR-CL-04 enthielt sie noch slowakische Wörter.

Typische Fehler im Test: was beide Prüfungen melden

Bei diesen fünf Varianten waren sich beide Werkzeuge einig: Der KoSIT-Validator empfahl jedes Mal, die Datei zurückzuweisen, und unsere Prüfung meldete jedes Mal einen Fehler. Die Sätze in Anführungszeichen sind die Meldungen unserer Prüfung, wörtlich.

• Muster mit zwei Fehlern, Bruttobetrag einen Cent zu hoch (535.51 statt 535.50) und Tippfehler in der IBAN: zum Betrag BR-CO-15 bei beiden, unsere Meldung „Der Gesamtbetrag mit Umsatzsteuer (BT-112) soll 450.00 plus 85.50 sein, also 535.50. In der Datei steht 535.51.“; zur IBAN beim KoSIT-Validator die Warnung BR-DE-19, bei uns dieselbe Warnung und dazu der Fehler ARL-IBAN
• Käuferreferenz fehlt: BR-DE-15 bei beiden, unsere Meldung „XRechnung verlangt die Leitweg-ID beziehungsweise Käuferreferenz (BT-10, cbc:BuyerReference), zum Beispiel 04011000-12345-03.“
• Währung als Wort „Euro“ statt Code EUR: zwei Fehler aus einer Änderung, BR-CL-04 und BR-CO-15, weil die Beträge weiter in EUR stehen und es in der Rechnungswährung keinen Steuerbetrag mehr gibt; bei uns zu BR-CO-15 „In der Rechnungswährung (Euro) muss es genau einen Gesamtsteuerbetrag (BT-110) geben. Gefunden: 0. Prüfen Sie cac:TaxTotal/cbc:TaxAmount und das Attribut currencyID.“
• Eine Position mit 269.00 statt 270.00: Der KoSIT-Validator meldet BR-CO-10 und BR-S-08 als Fehler und PEPPOL-EN16931-R120 als Warnung, wir die beiden Fehler, etwa „Die Positionssumme stimmt nicht: cbc:LineExtensionAmount (BT-106) ist 450.00, die Summe der Positionen beträgt 449.00.“
• Telefon des Verkäufers fehlt: BR-DE-6 bei beiden, beim KoSIT-Validator zusätzlich die Warnung BR-DE-27, unsere Meldung „In den Verkäufer-Kontaktangaben fehlt die Telefonnummer (BT-42, cbc:Telephone).“

Die Varianten mit der Währung und mit der einen Position zeigen ein Muster: Eine einzige falsche Angabe erzeugt zwei oder drei Meldungen. Beheben Sie deshalb die eine Ursache und prüfen Sie neu, bevor Sie jede Meldung einzeln abarbeiten.

Was der KoSIT-Validator annimmt, obwohl es einen zweiten Blick wert ist

Drei Varianten bekamen vom KoSIT-Validator die Empfehlung zur Annahme:

• Tippfehler in der IBAN (letzte Ziffer geändert): die Warnung BR-DE-19, Bewertung annehmen; unsere Prüfung meldet einen Fehler, weil die IBAN die Modulo-97-Prüfung nach ISO 13616 nicht besteht
• Leitweg-ID ohne Prüfziffer (991-33333TEST statt 991-33333TEST-33): keine Meldung, Bewertung annehmen; unsere Prüfung warnt, weil am Ende der Bindestrich mit zweistelliger Prüfziffer fehlt
• Telefonnummer nur „+49“: Warnung BR-DE-27, Bewertung annehmen; unsere Prüfung meldet dieselbe Warnung

Den IBAN-Fehler übersieht der KoSIT-Validator nicht, er stuft ihn nur als Warnung ein, und Warnungen verhindern die Empfehlung zur Annahme nicht. Bei der Leitweg-ID ist die fehlende Meldung folgerichtig: Die Käuferreferenz (BT-10) ist nach der Beschreibung in Peppol BIS Billing 3.0 ein Kennzeichen, das der Käufer für die interne Weiterleitung vergibt, als Datentyp einfacher Text, sie muss also keine Leitweg-ID sein. Geht die Rechnung an eine Behörde, gehört die Leitweg-ID hinein, und die endet laut Formatspezifikation immer mit einem Bindestrich und einer zweistelligen Prüfziffer.

Die IBAN-Prüfung und die Prüfung der Leitweg-ID auf ihre Form sind bei uns eigene Kontrollen, keine Regeln aus dem Schematron. Umgekehrt meldet der KoSIT-Validator Dinge, die wir nicht melden: Schemafehler, die Warnung PEPPOL-EN16931-R120 im Profil XRechnung und BR-DE-27, wenn die Telefonnummer ganz fehlt. Eine XRechnung in der CII-Syntax prüft von beiden Werkzeugen nur der KoSIT-Validator. Das Werkzeug der KoSIT, die XRechnung selbst entwickelt, bleibt deshalb die Referenz; unsere Prüfung ist eine schnelle erste Prüfung davor, die zusätzlich auf die Zahlungsdaten schaut.

Häufig gestellte Fragen

Fazit: vor dem Versand prüfen, Warnungen ernst nehmen

Prüfen Sie jede XRechnung vor dem Versand, beheben Sie zuerst die Fehler und lesen Sie danach die Warnungen, vor allem zu IBAN und Leitweg-ID. Für eine schnelle erste Prüfung einer UBL-Datei ohne Installation und ohne Upload öffnen Sie die Datei in unserem Validator für E-Rechnung und XRechnung; er nennt zu jedem Fund den Regelcode, den Pfad zum Element und eine kurze Erklärung. Für CII und als Referenz nehmen Sie den KoSIT-Validator.