KoSIT-Validator: Versionen, Download und Prüfung im Browser

Was ist der KoSIT-Validator?

Der KoSIT-Validator ist ein Prüfprogramm für XML-Dokumente. Herausgeber ist die Koordinierungsstelle für IT-Standards (KoSIT), die auch den Standard XRechnung betreut. Das Programm ist in Java geschrieben und steht unter der Apache License 2.0 auf GitHub (itplr-kosit/validator). Laut README arbeitet es in vier Schritten: XML-Format erkennen, mit XML-Schema und Schematron prüfen, einen Bericht erzeugen und eine Empfehlung zur Annahme oder Ablehnung berechnen.

Validator und Prüfkonfiguration sind zwei Downloads

Der Validator selbst enthält keine Prüfregeln. Die README nennt ihn ausdrücklich „just an engine“. Was geprüft wird, legt eine Prüfkonfiguration fest: die Datei scenarios.xml mit den Prüfszenarien, dazu XML-Schemas und Schematron-Regeln. Für E-Rechnungen ist das die Prüfkonfiguration XRechnung. Sie enthält die Schemas für UBL 2.1 und UN/CEFACT CII D16B, die Schematron-Regeln der EN 16931 und die Regeln der XRechnung.

Drei Betriebsarten

• Kommandozeile: Sie prüfen eine oder mehrere Dateien und erhalten je Datei einen Bericht.
• Bibliothek: Entwickler binden den Validator in eigene Java-Anwendungen ein (Maven: org.kosit:validator).
• Daemon: Mit der Option -D läuft der Validator als HTTP-Server, standardmäßig auf localhost, Port 8080. Adresse und Port ändern Sie mit -H und -P.

Aktuelle Version: Validator 1.6.3 und XRechnung-Konfiguration v2026-08-31

Die neueste Version des Validators ist 1.6.3 vom 20.08.2026; auf GitHub ist sie als „Latest“ markiert. Laut Changelog schließt sie eine Sicherheitslücke: Im Modus STRICT_LOCAL konnten Stylesheets von entfernten Adressen eingebunden werden. Die neueste Prüfkonfiguration ist das Release v2026-08-31, auf GitHub veröffentlicht am 02.09.2026. Sie nutzt den Validator 1.6.3 und die CEN-Schematron-Regeln 1.3.16. Unser Validator im Browser nutzt dieselbe Prüfkonfiguration; als Vergleich dient der Java-Validator 1.6.3.

Die Versionsbezeichnungen sind unterschiedlich aufgebaut: Der Validator hat Versionsnummern (1.6.3), die Konfiguration trägt das Datum ihres Release (v2026-08-31) und im Dateinamen die XRechnung-Version (3.0.2). Weil es im Sommer 2026 kein normatives Release gab, gilt die XRechnung-Version 3.0 laut KoSIT bis mindestens 31.07.2027. Eine Vorversion der Spezifikation XRechnung 4.0 ist seit dem 15.09.2026 veröffentlicht; die endgültige Fassung soll laut KoSIT voraussichtlich im Frühjahr 2027 erscheinen.

Und „KoSIT-Validator 1.5.0“?

Version 1.5.0 ist ein älteres Release vom 02.12.2022. Viele Anleitungen nennen noch diese Version. Seitdem sind 1.5.1 und 1.5.2 (beide 01.09.2025) sowie 1.6.0 bis 1.6.3 erschienen. Die README nennt den Zweig 1.5.x „frozen“, also ohne Wartung und ohne Support; 1.6.x bekommt Fehlerbehebungen, aber keine neuen Funktionen. Seit 1.5.1 heißt die Datei validator-…-standalone.jar statt validationtool-…. Seit 1.6.0 ist mindestens Java 11 nötig, Java 8 wird nicht mehr unterstützt.

An einer Version 2.0 mit neuem Berichtsformat arbeitet die KoSIT laut README. Im Repository gibt es dazu Vorab-Tags wie v2.0.0-alpha1; ein Release 2.0 ist auf der Release-Seite bislang nicht veröffentlicht (Stand: 30.10.2026).

KoSIT-Validator herunterladen und mit Java ausführen

Sie brauchen Java ab Version 11 und zwei Dateien: den Validator als Standalone-JAR von der Release-Seite des Validators und die Prüfkonfiguration als ZIP von der Release-Seite der Konfiguration. Das Beispiel für Linux und macOS orientiert sich an der Anleitung docs/usage.md der Konfiguration; wir haben es am 30.10.2026 mit OpenJDK 21 ausgeführt.

# Beispiel: Validator und Prüfkonfiguration herunterladen
curl -LO https://github.com/itplr-kosit/validator/releases/download/v1.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

# rechnung.xml prüfen; -s Szenarien, -r Verzeichnis der Konfiguration, -h Bericht auch als HTML
java -jar validator-1.6.3-standalone.jar -s scenarios.xml -r "$PWD" -h rechnung.xml

Für rechnung.xml haben wir unsere fehlerhafte Beispielrechnung verwendet. Der Validator gibt am Ende diese Tabelle aus (Dateipfad gekürzt):

|File          |Schema |Schematron|Acceptance|Error/Description                                           |
|rechnung.xml  |   Y   |    N     |  REJECT  |[BR-CO-15]-Invoice total amount with VAT (BT-112) = Invoice |
|              |       |          |          |total amount without VAT (BT-109) + Invoice total VAT amount|
|              |       |          |          | (BT-110).;[BR-DE-15] Das Element "Buyer reference" (BT-1...|
Acceptable:  0  Rejected:  1

Den Bericht schreibt der Validator neben die Rechnung: rechnung-report.xml und mit -h zusätzlich rechnung-report.html. Der Exit-Code des Programms ist die Zahl der abgelehnten Dateien, hier 1; 0 bedeutet, dass alle Dateien angenommen wurden. Mit der gültigen Beispielrechnung meldet derselbe Aufruf ACCEPTABLE.

Geben Sie bei -r den vollständigen Pfad an. Mit -r . brach der Validator in unserem Test ab: Can not resolve resources/ubl/2.1/xsd/maindoc/UBL-Invoice-2.1.xsd in repository …. Alle Optionen zeigt java -jar validator-1.6.3-standalone.jar --help.

KoSIT-Validator online: dieselbe Konfiguration im Browser

Ein Online-Angebot der KoSIT selbst ist uns nicht bekannt; die KoSIT veröffentlicht den Validator zum Herunterladen. Unser XRechnung Validator führt die Regeln der Prüfkonfiguration v2026-08-31 inhaltlich unverändert in Ihrem Browser aus; für SaxonJS sind sie in das SEF-Format übersetzt. Die Schematron-Regeln führt dort SaxonJS aus, die Schemaprüfung libxml2 (als WebAssembly); Java ist nicht nötig. Die Rechnung wird dabei nicht hochgeladen.

Was gleich ist

Wir vergleichen unsere Ergebnisse mit dem Java-Validator 1.6.3 und derselben Konfiguration: Bewertung, Prüfszenario und jede Meldung mit Regel, Stufe und Fundstelle. Grundlage sind 269 Dateien: die 86 Dateien der offiziellen XRechnung-Testsuite und 183 eigens erzeugte Prüffälle, darunter 115 absichtlich fehlerhafte Rechnungen. Stand 26.10.2026 stimmen Bewertung, Prüfszenario und alle Schematron-Meldungen in allen 269 Dateien überein; der Vergleich läuft bei jeder Änderung als automatischer Test.

Was sich unterscheidet

• Die Texte der Schemafehler: Java nutzt Xerces, wir libxml2. Ob das Schema verletzt ist, stimmt überein; Wortlaut und Anzahl der Meldungen können abweichen.
• Bei drei Regeln (BR-S-08, BR-AF-08, BR-AG-08 in UBL) rechnet SaxonJS an der Toleranzgrenze anders. Diese Fälle rechnen wir mit exakten Dezimalwerten nach und kommen so zum selben Ergebnis wie der Java-Validator.
• Passt eine Rechnung zu keinem Prüfszenario, empfiehlt der Java-Validator die Ablehnung. Wir zeigen stattdessen „Kein passendes Prüfszenario“, weil dann kein Regelwerk angewendet wurde.
• Einen XML-Bericht im Format des KoSIT-Validators erzeugt unsere Seite nicht. Sie zeigt das Ergebnis auf der Seite und als druckbaren Prüfbericht; zusätzlich gibt es eine Schnellprüfung der Kernregeln und Hinweise ohne offiziellen Regelcode.

Die Einzelheiten stehen in unserer Methodik. Eine Zertifizierung durch die KoSIT gibt es für unsere Seite nicht.

ZUGFeRD und der KoSIT-Validator

Der KoSIT-Validator prüft XML-Dateien, keine PDF-Dateien. Bei einer ZUGFeRD- oder Factur-X-Rechnung müssen Sie die eingebettete XML-Datei (CII) also erst aus der PDF-Datei holen. Welches Prüfszenario dann greift, entscheidet die Spezifikationskennung (BT-24) im Element ram:GuidelineSpecifiedDocumentContextParameter/ram:ID:

• Profil EN 16931 (urn:cen.eu:en16931:2017): Szenario „EN16931 (CII)“
• Profil XRECHNUNG: Szenario „EN16931 XRechnung (CII)“
• Profile MINIMUM, BASIC WL, BASIC und EXTENDED: kein Szenario; der Validator kann diese Dateien nicht nach ihren Regeln prüfen

Das zeigt die scenarios.xml der Konfiguration v2026-08-31: Die Szenarien vergleichen die Kennung exakt, und BASIC (urn:cen.eu:en16931:2017#compliant#urn:factur-x.eu:1p0:basic) oder EXTENDED passen zu keinem davon. Die Tabelle aller Profile mit Kennungen finden Sie beim ZUGFeRD Validator; er liest die XML-Datei aus der PDF-Datei aus und prüft sie im Browser.

Den Prüfbericht des KoSIT-Validators lesen

Im Bericht steht eine Bewertung. Sie ist eine Empfehlung, keine Rechtsfolge: Ob eine Rechnung angenommen wird, entscheidet der Rechnungsempfänger. Die Konfiguration v2026-08-31 kennt diese Texte:

• „Es wird empfohlen das Dokument anzunehmen und weiter zu verarbeiten.“ (bei uns: „Annahme empfohlen“)
• „Es wird empfohlen das Dokument anzunehmen und zu verarbeiten, da die vorhandenen Fehler derzeit toleriert werden.“
• „Es wird empfohlen das Dokument zurückzuweisen.“ (bei uns: „Ablehnung empfohlen“)
• „Es wird empfohlen das Dokument zurückzuweisen. Da kein Pruefszenario gegriffen hat.“
• „Die Validierung konnte nicht vollständig durchgeführt werden. Das Dokument sollte nicht automatisiert angenommen werden.“

Stufen der Meldungen

Die Schematron-Regeln liefern ihre Ergebnisse im Format SVRL. Jede verletzte Regel ist ein svrl:failed-assert mit einem flag. Der Bericht der Prüfkonfiguration (default-report.xsl) ordnet fatal der Stufe error zu, warning der Stufe warning und information der Stufe information. Schon ein error führt zur Empfehlung, das Dokument zurückzuweisen, ebenso ein Schemafehler. Warnungen und Informationen ändern die Bewertung nicht.

Das Prüfszenario kann die Stufe einzelner Regeln ändern (customLevel). Beispiel aus der scenarios.xml: Die Regel UBL-CR-646 meldet sich mit flag="warning". Im Szenario „EN16931 XRechnung (UBL Invoice)“ ist sie auf error hochgestuft, in „EN16931 XRechnung Extension (UBL Invoice)“ auf information herabgestuft.

Beispiel: fehlende Käuferreferenz

Diese Meldung stammt aus unseren Testfällen: eine Rechnung der offiziellen Testsuite (01.01_comprehensive_test_ubl.xml), aus der wir die Käuferreferenz (BT-10) entfernt haben. So steht die Meldung in der SVRL-Ausgabe der XRechnung-Regeln:

<svrl:failed-assert location="/Q{urn:oasis:names:specification:ubl:schema:xsd:Invoice-2}Invoice[1]"
    flag="fatal" id="BR-DE-15" test="cbc:BuyerReference[boolean(normalize-space(.))]">
  <svrl:text>[BR-DE-15] Das Element "Buyer reference" (BT-10) muss übermittelt werden.</svrl:text>
</svrl:failed-assert>

Auch unserer fehlerhaften Beispielrechnung fehlt die Käuferreferenz. Im XML-Bericht rechnung-report.xml aus dem Aufruf oben wird daraus eine Meldung der Stufe error:

<rep:message id="val-sch.2.1" level="error"
    xpathLocation="/Q{urn:oasis:names:specification:ubl:schema:xsd:Invoice-2}Invoice[1]" code="BR-DE-15">
  [BR-DE-15] Das Element "Buyer reference" (BT-10) muss übermittelt werden.
</rep:message>

location und xpathLocation zeigen auf das Element, an dem die Regel geprüft wurde, hier das Wurzelelement Invoice, weil das Feld fehlt. Die Bewertung lautet „Es wird empfohlen das Dokument zurückzuweisen.“ Was die Meldung bedeutet und wie Sie den Fehler beheben, erklärt der Abschnitt zu BR-DE-15; bei öffentlichen Auftraggebern gehört in die Käuferreferenz meist die Leitweg-ID.

Häufige Fragen zum KoSIT-Validator

Quellen

• KoSIT: itplr-kosit/validator (README, CHANGELOG, docs/cli.md, docs/daemon.md) und Releases, Stand Commit 6ac5167 vom 20.08.2026; abgerufen am 30.10.2026.
• KoSIT: itplr-kosit/validator-configuration-xrechnung (README, CHANGELOG, docs/usage.md, scenarios.xml, src/default-report.xsl) und Release v2026-08-31; abgerufen am 30.10.2026.
• KoSIT: xeinkauf.de/xrechnung und „Versionen und Bundles“ (Gültigkeit von XRechnung 3.0, Vorversion 4.0); abgerufen am 30.10.2026.
• Eigener Test am 30.10.2026: Validator 1.6.3 mit der Konfiguration v2026-08-31 unter OpenJDK 21, geprüft mit unseren Beispielrechnungen; SVRL-Auszug aus unseren Testfällen (Methodik).

Zuletzt aktualisiert: 30.10.2026 · E-Rechnung OK ist ein unabhängiges Angebot und nicht mit der KoSIT verbunden. Diese Seite ist keine Rechtsberatung.