KoSIT-Validator: Was er prüft und wie Sie ihn nutzen

Der KoSIT-Validator ist das quelloffene Prüfwerkzeug der Koordinierungsstelle für IT-Standards (KoSIT). Mit der Prüfkonfiguration für XRechnung prüft er eine XML-Rechnung gegen XSD-Schema, die Regeln der EN 16931 und die XRechnung-Regeln und empfiehlt Annahme oder Zurückweisung. Er läuft als Java-Programm auf der Kommandozeile oder als HTTP-Dienst.

Der Beitrag richtet sich an Entwickler, Integratoren und Rechnungseingangsteams, die Prüfergebnisse nachvollziehen oder den Validator selbst betreiben wollen. Stand der Angaben ist der 29. September 2026: Validator 1.6.3 und Prüfkonfiguration 2026-08-31.

Was ist der KoSIT-Validator?

Der KoSIT-Validator ist ein konfigurierbares Java-Programm, das XML-Dokumente gegen XSD-Schemata und Schematron-Regeln prüft und daraus einen Prüfbericht mit Annahmeempfehlung erzeugt. Die KoSIT beschreibt ihn auf xeinkauf.de (öffnet in neuem Tab) als „konfigurierbares XML-Prüftool“, das mit einer XRechnung-spezifischen Konfiguration zur Validierung nach dem Standard XRechnung genutzt wird.

Zwei Teile gehören zusammen:

Ohne Konfiguration prüft der Validator nichts. Welche Regeln gelten, steht allein in der Konfiguration. Deshalb ist die Frage „Welche Version des KoSIT-Validators nutzen Sie?“ nur halb gestellt: Entscheidend ist das Datum der Konfiguration.

Wie läuft eine Prüfung ab?

1. Szenario wählen: Der Validator vergleicht Wurzelelement und Spezifikationskennung (BT-24) mit den match-Ausdrücken der scenarios.xml.
2. XSD-Prüfung: Die Datei muss dem Schema von UBL 2.1 oder CII entsprechen.
3. Schematron EN 16931: Pflichtfelder (BR-…), Rechenregeln (BR-CO-…), Codelisten (BR-CL-…).
4. Schematron XRechnung: nationale Regeln (BR-DE-…), nur in den XRechnung-Szenarien.
5. Bericht: Die Berichtsvorlage fasst die Ergebnisse zusammen. Dabei kann die Konfiguration Schweregrade ändern, in der Version 2026-08-31 zum Beispiel BR-CL-23 von „fatal“ auf „warning“.
6. Bewertung: Enthält der Bericht das Element rep:accept, gilt die Datei als annehmbar.

So sieht der Anfang des ersten Szenarios in der aktuellen Konfiguration aus:

<match>exists(/invoice:Invoice/cbc:CustomizationID[ . = 'urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0']) </match>
<validateWithXmlSchema>
  <resource>
    <name>XML Schema for UBL 2.1 Invoice</name>
    <location>resources/ubl/2.1/xsd/maindoc/UBL-Invoice-2.1.xsd</location>
  </resource>
</validateWithXmlSchema>

Die Konfiguration 2026-08-31 enthält elf Szenarien:

Die letzte Zeile erklärt eine häufige Überraschung: Eine Rechnung mit einer veralteten Kennung wie xrechnung_2.3 wird abgelehnt, ohne dass eine einzige Geschäftsregel läuft. Mehr zu BT-24 und den Namensräumen steht im Beitrag XRechnung XML-Struktur.

Welche Rolle spielt der Validator rechtlich?

Das BMF-Schreiben vom 15.10.2025 nennt kein bestimmtes Werkzeug. Es spricht von einer „geeigneten Validierungsanwendung“, mit der sich Formatfehler feststellen lassen (Rn. 6a). Nach Rn. 35a darf sich ein Unternehmer mit der Sorgfalt eines ordentlichen Kaufmanns auf das technische Ergebnis einer solchen Validierung verlassen, soweit es um Format und Geschäftsregeln geht. Den Validierungsbericht aufzubewahren, bietet sich als Nachweis an.

Die Validierung ersetzt aber nicht die inhaltliche Prüfung. Ein falscher Steuersatz fällt keiner Regel auf, ist aber ein Inhaltsfehler. Wie die drei Fehlerklassen zusammenhängen, erklärt unser Beitrag XRechnung-Fehler beheben.

Beispiel: den Validator lokal ausführen

Sie brauchen Java 11 oder neuer. Die folgenden Befehle stammen sinngemäß aus der Anleitung der Prüfkonfiguration; nur Ordnernamen sind angepasst.

# Validator und Prüfkonfiguration laden
curl -L -o validator-1.6.3-standalone.jar \
  https://repo1.maven.org/maven2/org/kosit/validator/1.6.3/validator-1.6.3-standalone.jar
curl -L -o konfiguration.zip \
  https://github.com/itplr-kosit/validator-configuration-xrechnung/releases/download/v2026-08-31/xrechnung-3.0.2-validator-configuration-2026-08-31.zip
unzip konfiguration.zip -d konfiguration

# Rechnung prüfen, XML- und HTML-Bericht in den Ordner "berichte" schreiben
mkdir -p berichte
java -jar validator-1.6.3-standalone.jar \
  -s konfiguration/scenarios.xml -r konfiguration \
  -o berichte -h rechnung.xml
echo $?

Die Optionen im Einzelnen: -s nennt die scenarios.xml, -r den Ordner mit den Regeldateien, -o den Ausgabeordner, -h legt zusätzlich eine HTML-Fassung des Berichts ab, und -p würde das Ergebnis direkt im Terminal ausgeben. Danach liegen rechnung-report.xml und rechnung-report.html im Ordner berichte.

echo $? zeigt den Rückgabecode:

Typische Stolpersteine beim Aufruf

• Seit Version 1.5.1 heißt die Datei validator-…-standalone.jar. Ältere Skripte und Anleitungen rufen noch validationtool-… auf.
• Seit Version 1.6.1 liegt die Standalone-JAR getrennt vom ZIP-Paket; das Release 1.6.0 enthielt nur das ZIP.
• -r muss auf den Ordner zeigen, in dem der Unterordner resources der Konfiguration liegt. Sonst findet der Validator die Regeldateien nicht und endet mit Code -2.
• Sie können -s und -r mehrfach angeben, etwa um die XRechnung-Konfiguration und die öffentliche Konfiguration für Peppol BIS Billing in einem Lauf zu nutzen.
• Statt eines Dateinamens nimmt der Validator die Rechnung auch über die Standardeingabe entgegen, zum Beispiel < rechnung.xml.

Was steht in der Bewertung?

Die Berichtsvorlage der Konfiguration 2026-08-31 kennt fünf Formulierungen:

Warnungen ändern die Empfehlung nicht. Wie Sie die einzelnen Meldungen eines Berichts lesen, zeigt die Liste der XRechnung Fehlercodes mit Erklärungen. Maßgeblich ist dabei immer der Regeltext im Bericht selbst.

Der Validator als HTTP-Dienst

Mit -D startet der Validator einen Server, standardmäßig auf localhost, Port 8080. Andere Adressen setzen Sie mit -H und -P.

java -jar validator-1.6.3-standalone.jar -s konfiguration/scenarios.xml -r konfiguration -D

# in einem zweiten Terminal: Rechnung per POST senden, Bericht speichern
curl -s -o bericht.xml -w "%{http_code}\n" \
  -H "Content-Type: application/xml" \
  --data-binary @rechnung.xml http://localhost:8080/rechnung.xml

Der Dienst antwortet mit 200, wenn die Datei annehmbar ist, mit 406, wenn nicht, und mit 422 bei einem Verarbeitungsfehler, der meist auf die Konfiguration hindeutet. Pro Anfrage nimmt er genau ein XML-Dokument an, kein Multipart. Eine Anmeldung prüft er nicht; den Zugriff müssen Sie selbst absichern, etwa über einen vorgeschalteten Proxy. Unter /server/health meldet er seinen Status.

Welche Konfiguration gehört zu welcher XRechnung-Version?

XRechnung 3.0 bleibt laut KoSIT mindestens bis zum 31.07.2027 in Kraft. Die Vorversion von XRechnung 4.0 erschien im September 2026; die finale Fassung soll im Frühjahr 2027 zusammen mit den technischen Komponenten erscheinen. Bis dahin prüfen Sie mit der Konfiguration 2026-08-31. Wer noch den Validator 1.5.x einsetzt, sollte auf 1.6.3 wechseln: Diese Version schließt eine Sicherheitslücke, durch die im Modus STRICT_LOCAL entfernte Stylesheets eingebunden werden konnten.

KoSIT-Validator, Online-Prüfung und XML Viewer im Vergleich

Der Online-Check bildet die Prüfschritte des Referenzwerkzeugs nach. Er wählt das Szenario nach der Kennung in BT-24, prüft das XSD-Schema und dann nur die Schematron-Regeln dieses Szenarios. Er übernimmt auch die Schweregrade aus der scenarios.xml, etwa BR-CL-23 als Warnung, und urteilt nach derselben Regel: Annahme nur, wenn keine Meldung der Stufe „error“ übrig bleibt. ZUGFeRD-XML im Profil EN 16931 läuft deshalb nur gegen die Regeln der Norm, und eine unbekannte Kennung führt wie beim KoSIT-Validator zur Ablehnung ohne Regelprüfung.

Wir haben den Online-Check mit dem KoSIT-Validator 1.6.3 und der Konfiguration 2026-08-31 abgeglichen. Getestet haben wir 33 eigene Testdateien und die 86 Dateien der offiziellen XRechnung-Testsuite. Die Empfehlungen, Regelcodes und Stufen waren bei allen Dateien gleich. Ein Unterschied bleibt: Schemafehler formuliert der Online-Check mit einer anderen XML-Bibliothek, deshalb lautet der Text anders und es fehlen die cvc-…-Codes. Das Ergebnis der Schemaprüfung ist dasselbe. Einen Prüfbericht zum Aufbewahren erzeugt nur der KoSIT-Validator. Wie Sie ZUGFeRD-Dateien vollständig prüfen, steht im Beitrag ZUGFeRD validieren.

So prüfen Sie eine XRechnung mit docutools.pro

1. Öffnen Sie den XRechnung Validator und klicken Sie auf „Datei auswählen“, oder testen Sie den Ablauf mit „Beispielrechnung laden“. Er nimmt UBL-Invoice- und CII-Dateien an, keine PDFs.
2. Die Datei wird an unseren Server übertragen und dort geprüft wie mit dem KoSIT-Validator: Szenario, XSD-Schema und Schematron-Regeln der Konfiguration 2026-08-31. Kostenlos sind zwei Uploads pro Tag bis 500 KB.
3. Sie sehen das Urteil „KoSIT-konform / Gültige XRechnung“ oder „Nicht KoSIT-konform“, den „Compliance-Score“ und die Liste der Fehler und Warnungen mit Regelcode.
4. Schlagen Sie einzelne Codes in der Übersicht der KoSIT-Fehler nach, zum Beispiel BR-DE-15 für die fehlende Käuferreferenz BT-10.
5. Um die Struktur der Datei zu untersuchen, öffnen Sie sie im XML Viewer. Er zeigt den Baum im Browser an, kostenlos bis 500 KB, validiert aber nicht.
6. Brauchen Sie einen Prüfbericht zum Aufbewahren, etwa als Nachweis im Sinne des BMF-Schreibens oder für ein Kunden-Onboarding, führen Sie zusätzlich den KoSIT-Validator wie oben beschrieben aus und bewahren Sie dessen Bericht auf.

Weitere Beiträge zu Prüfregeln und Fehlermeldungen finden Sie auf der Themenseite Validierung und Fehler.

Quellen

• KoSIT-Validator auf GitHub, mit Dokumentation zu CLI und Daemon (öffnet in neuem Tab)
• Prüfkonfiguration XRechnung auf GitHub, Releases und Anleitung (öffnet in neuem Tab)
• XRechnung-Versionen und Bundles auf xeinkauf.de (öffnet in neuem Tab)
• BMF-Schreiben vom 15.10.2025 zur E-Rechnung (öffnet in neuem Tab)

Stand: September 2026

Dieser Beitrag dient der allgemeinen Information und ersetzt keine Steuer- oder Rechtsberatung.