XRechnung validieren: der KoSIT-Validator erklärt

Von evoicely · Zuletzt geprüft am 20. Oktober 2026

Um eine XRechnung zu validieren, prüfen Sie das XML gegen drei Regelwerke: das XML-Schema von UBL oder CII, die Geschäftsregeln der EN 16931 und die deutschen XRechnung-Regeln (BR-DE-*). Das offizielle Werkzeug dafür ist der KoSIT-Validator, ein Java-Programm, zusammen mit der XRechnung-Konfiguration der KoSIT. Eine Datei ohne Fehler ist „acceptable“; Warnungen ändern daran nichts. Für eine schnelle Prüfung ohne Installation laden Sie die Datei in unseren kostenlosen E-Rechnungs-Validator hoch. Er verwendet dieselben offiziellen Regeldateien, zeigt jeden Fehler mit seiner Regel-ID an und speichert Ihre Datei nicht.

Was „gültig“ bedeutet

Eine XRechnung wird in Ebenen geprüft. Jede Ebene hat eigene Regel-IDs, an der ID in einer Fehlermeldung erkennen Sie also, woher sie stammt:

Ebene	Was sie prüft	Regel-IDs
XML-Schema	Struktur: Elementnamen, Reihenfolge, Verschachtelung und Datentypen (UBL 2.1 oder UN/CEFACT CII D16B).	Schemafehler mit Zeilennummer
EN 16931	Die Geschäftsregeln der europäischen Norm: Pflichtfelder, Summen, die aufgehen, Umsatzsteuerkategorien, Codelisten. Von CEN als Schematron veröffentlicht.	`BR-`, `BR-CO-`, `BR-S-`, `BR-AE-`, `BR-CL-`, `UBL-`
XRechnung (CIUS)	Die zusätzlichen deutschen Regeln: Käuferreferenz, Kontaktdaten des Verkäufers, Zahlungsangaben, Anschriften, elektronische Adressen.	`BR-DE-*` und einige von Peppol übernommene wie `PEPPOL-EN16931-R020`

Die aktuelle Konfiguration enthält die EN-16931-Regeln in Version 1.3.16 und das XRechnung-Schematron 2.6.0 für XRechnung 3.0.2 (Release der Validator-Konfiguration vom 31. August 2026; Quellen: Validierungsartefakte zur EN 16931, XRechnung-Schematron).

Jede Regel hat einen Schweregrad. In der Konfiguration der KoSIT führt ein Befund der Stufe fatal oder error zu „REJECT“. Eine warning, etwa BR-DE-19 bei einer IBAN mit falscher Prüfziffer, lässt die Datei „ACCEPTABLE“, ebenso ein Hinweis der Stufe information.

Wie der Validator das Regelwerk wählt

Der KoSIT-Validator ist nur eine Prüf-Engine. Er weiß, wie es in seiner Dokumentation heißt, nichts über XML-Dokumente und hat keine eigenen Prüfregeln (KoSIT-Validator auf GitHub). Die Regeln kommen aus einer Konfiguration, deren scenarios.xml Szenarien auflistet. Jedes Szenario greift anhand der Spezifikationskennung des Dokuments (BT-24): cbc:CustomizationID in UBL, die Guideline-ID in rsm:ExchangedDocumentContext in CII.

Für eine normale XRechnung 3.0 muss diese Kennung genau so lauten:

urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0

Die XRechnung-Konfiguration enthält außerdem Szenarien für die XRechnung-Extension, für XRechnung CVD und für reine EN-16931-Dateien (Kennung urn:cen.eu:en16931:2017), auf die nur die Regeln der EN 16931 angewendet werden. Eine Datei, deren Kennung zu keinem Szenario passt, etwa eine alte xrechnung_2.3-Datei, wird ohne jede Regelmeldung abgelehnt: Im Bericht steht nur, dass kein Szenario gegriffen hat. Lehnt der KoSIT-Validator eine Datei ab, ohne Fehler aufzulisten, prüfen Sie zuerst BT-24.

Möglichkeit 1: online prüfen

Unser kostenloser Validator liest die Spezifikationskennung und wählt das Regelwerk auf dieselbe Weise, aus derselben KoSIT-Konfiguration (XRechnung 3.0.2, Konfiguration vom 31. August 2026). So gehen Sie vor:

Öffnen Sie den Validator und wählen Sie die XML-Datei (bis 10 MB) aus oder fügen Sie das XML ein.
Starten Sie die Prüfung. Sie erhalten ein Ergebnis (gültig oder nicht gültig), die angewendeten Regelwerke und jeden Fehler und jede Warnung mit Regel-ID, Regeltext und der Stelle im Dokument, auf die sie sich beziehen.
Unter dem Ergebnis wird die Rechnung wie eine Papierrechnung dargestellt, sodass Sie sehen, was tatsächlich im XML steht.

Er verarbeitet XRechnung in UBL und CII, ZUGFeRD / Factur-X (als XML oder als PDF mit eingebettetem XML) und Peppol BIS Billing 3.0. Die Datei wird im Arbeitsspeicher geprüft und nie gespeichert. Anders als der KoSIT-Validator wendet er bei einer unbekannten Spezifikationskennung trotzdem die Kernregeln der EN 16931 an und weist Sie darauf hin, statt die Datei nur abzulehnen.

Besteht eine Datei die Prüfung, erfüllt sie die veröffentlichten Regeln. Das garantiert nicht, dass ein bestimmter Rechnungsempfänger oder ein bestimmtes Portal sie annimmt; manche führen eigene Prüfungen durch.

Möglichkeit 2: den KoSIT-Validator selbst ausführen

Das lohnt sich, wenn Sie Rechnungen in großer Zahl erzeugen oder die Prüfung in Ihren Build einbauen wollen. Sie brauchen Java 11 oder neuer (Anleitung im Repository der Konfiguration).

# die Validator-Engine (Standalone-JAR)
curl -LO https://repo1.maven.org/maven2/org/kosit/validator/1.6.3/validator-1.6.3-standalone.jar

# die XRechnung-Konfiguration (Regeln, Schemas, scenarios.xml)
curl -LO https://github.com/itplr-kosit/validator-configuration-xrechnung/releases/download/v2026-08-31/xrechnung-3.0.2-validator-configuration-2026-08-31.zip
unzip xrechnung-3.0.2-validator-configuration-2026-08-31.zip -d xrechnung-config

# eine oder mehrere Dateien prüfen
java -jar validator-1.6.3-standalone.jar \
  -s xrechnung-config/scenarios.xml \
  -r xrechnung-config \
  -o reports -h invoice.xml

-s ist die Szenario-Datei, -r das Verzeichnis, auf das sich die Pfade der Konfiguration beziehen, -o das Ausgabeverzeichnis, und -h schreibt den Bericht zusätzlich als HTML. Sehen Sie in den Releases der Konfiguration nach neueren Versionen, bevor Sie sich auf eine festlegen.

Auf der Konsole erscheint eine Übersichtstabelle. So sieht die Ausgabe für eine Rechnung ohne Käuferreferenz aus (gekürzt):

|File          |Schema |Schematron|Acceptance|Error/Description            |
|invoice.xml   |   Y   |    N     |  REJECT  |[BR-DE-15] Das Element "Buyer|
|              |       |          |          | reference" (BT-10) muss übe…|
Acceptable:  0  Rejected:  1

Der Validator endet mit Exit-Code 1, wenn eine Datei abgelehnt wird, und mit 0, wenn alle Dateien akzeptabel sind. Ein CI-Job schlägt also bei Fehlern fehl und läuft bei Warnungen durch. Übergeben Sie viele Dateien in einem einzigen Aufruf: Der Start der JVM dauert länger als die Prüfungen selbst. Für Dienste, die laufend prüfen, gibt es außerdem einen Daemon-Modus (-D), der einen HTTP-Server startet, standardmäßig auf localhost Port 8080 (README des KoSIT-Validators).

Den Prüfbericht lesen

Für jede Datei erhalten Sie invoice-report.xml und mit -h zusätzlich invoice-report.html. Der HTML-Prüfbericht ist auf Deutsch und zeigt:

das Szenario, das gegriffen hat, und damit, welche Regeln angewendet wurden;
den Namen des Verkäufers, die Rechnungsnummer und das Rechnungsdatum, die er gefunden hat, zur Kontrolle, dass er das richtige Dokument gelesen hat;
jeden Befund mit Regel-ID, Schweregrad, Text und einem XPath zum betroffenen Element;
das Ergebnis: annehmen oder ablehnen.

Die Texte der BR-DE-Regeln sind auf Deutsch, die der EN 16931 und von Peppol auf Englisch. Suchen Sie am besten nach der Regel-ID. Unser Leitfaden zu häufigen XRechnung-Fehlern erklärt die Fehler, auf die Stripe-Nutzer am häufigsten stoßen, und wie Sie sie beheben.

Was die Validierung nicht aussagt

Ob der Inhalt stimmt. Die Regeln prüfen, dass eine USt-IdNr. vorhanden ist und mit einem Ländercode beginnt, nicht, ob es Ihre ist oder ob die umsatzsteuerliche Behandlung richtig ist.
Ob die Käuferreferenz richtig zugestellt wird. Jede nicht leere BT-10 besteht BR-DE-15. Eine Behörde braucht aber genau ihre Leitweg-ID.
Ob ein ZUGFeRD-PDF ein gültiges PDF/A-3 ist. Die XRechnung-Konfiguration prüft nur XML. Bei ZUGFeRD lässt sich das eingebettete XML gegen die EN 16931 prüfen, für das PDF brauchen Sie eine separate PDF/A-Prüfung.
Peppol. Für Peppol BIS Billing 3.0 gelten eigene Regeln von OpenPEPPOL (Peppol BIS Billing 3.0), die in der XRechnung-Konfiguration nicht enthalten sind.

Gegen welche Version Sie prüfen

XRechnung 3.0 gilt seit dem 1. Februar 2024 und laut KoSIT mindestens bis zum 31. Juli 2027. Das aktuelle Bundle ist 3.0.2 mit dem Bugfix-Release vom 31. August 2026. Eine vorläufige XRechnung 4.0 wurde im September 2026 veröffentlicht, die endgültige Fassung wird für Frühjahr 2027 erwartet (XRechnung: Versionen und Bundles, xeinkauf.de). Prüfen Sie gegen die Konfiguration für die Version, die Ihre Rechnungsempfänger erwarten. Solange 4.0 nicht endgültig ist und gilt, ist das 3.0.

Weitere Leitfäden

Häufige XRechnung-Fehler (BR-DE-*): was jede Regel bedeutet und wie Sie den Fehler beheben.
XRechnung öffnen und lesen: wenn Sie sehen wollen, was darin steht.
XRechnung oder ZUGFeRD?: welches Format Ihre Kunden brauchen.
E-Rechnungspflicht in Deutschland für Stripe-Nutzer: wer ab wann E-Rechnungen ausstellen muss.

Was evoicely dabei übernimmt

Prüfen Sie jetzt eine XRechnung, kostenlos und ohne Anmeldung. Wenn Ihre Rechnungen aus Stripe kommen, macht evoicely daraus XRechnung und ZUGFeRD und prüft jede Datei mit diesen Regeln, bevor sie verschickt wird. Jetzt starten, kostenlos für 10 E-Rechnungen im Monat.

Dies sind allgemeine Informationen, keine Rechts- oder Steuerberatung. Eine Datei, die die Validierung besteht, ist technisch gültig nach den veröffentlichten Regeln; klären Sie mit Ihrer Steuerberatung, was für Ihr Unternehmen gilt.