KoSIT Validator

Die Koordinierungsstelle für IT-Standards (KoSIT) in Bremen betreut den Standard XRechnung im Auftrag von Bund und Ländern. Für die Prüfung von E-Rechnungen stellt sie ein eigenes Werkzeug bereit: den KoSIT Validator, oft auch „KoSIT-Prüftool“ oder „XRechnung-Prüftool“ genannt. Der Quellcode liegt öffentlich auf GitHub unter itplr-kosit/validator.

Technisch ist der Validator eine allgemeine XML-Prüfmaschine. Er erkennt das Format eines Dokuments, prüft es gegen XML Schema und Schematron, erzeugt einen Bericht und berechnet daraus eine Annahmeempfehlung. Was genau geprüft wird, steht nicht im Programm selbst, sondern in einer Szenario-Konfiguration (scenarios.xml). Ein Szenario sagt: Für dieses Dokumentformat gelten diese Schemata, diese Schematron-Dateien und diese Regeln für den Bericht.

Für XRechnung veröffentlicht die KoSIT diese Konfiguration separat als validator-configuration-xrechnung. Sie enthält die UBL-2.1- und CII-Schemata, die EN16931-Schematron des CEN und die Schematron der CIUS XRechnung und der Extension XRechnung. Die Releases sind nach Datum benannt und nennen die passende XRechnung-Version, zuletzt die 3.0-Linie.

1. Java installieren. Die Standalone-JAR läuft mit Java 11 oder neuer.
2. Validator laden. Auf der Release-Seite von itplr-kosit/validator liegt ein ZIP mit den JAR-Varianten. Sie brauchen validator-<version>-standalone.jar. Bis Version 1.5.0 hieß die Datei validationtool-<version>-standalone.jar; ältere Anleitungen nutzen noch diesen Namen.
3. XRechnung-Konfiguration laden und in einen Ordner entpacken. Darin liegt die scenarios.xml.
4. Rechnung prüfen:

java -jar validator-<version>-standalone.jar \
  -s <konfig>/scenarios.xml \
  -r <konfig> \
  -h rechnung.xml

-s nennt die Szenario-Datei, -r den Ordner mit Schemata und Schematron (das „Repository“). -h schreibt den HTML-Teil des Berichts als Datei, -p gibt den Bericht auf der Konsole aus. Sie können mehrere Dateien auf einmal übergeben. --help zeigt alle Optionen.

Daemon-Modus: Mit -D startet der Validator als HTTP-Dienst. Ihre Anwendung schickt die XML dann per POST und erhält den Bericht zurück. So binden viele ERP- und Rechnungseingangssysteme die Prüfung ein, ohne für jede Rechnung eine neue Java-Instanz zu starten.

java -jar validator-<version>-standalone.jar \
  -s <konfig>/scenarios.xml -r <konfig> -D

In Java-Anwendungen können Sie den Validator auch als Bibliothek einbinden (Maven-Koordinaten org.kosit:validator).

Der Validator schreibt immer einen XML-Bericht. Die XRechnung-Konfiguration bettet darin eine HTML-Ansicht ein: oben die Empfehlung, darunter alle Meldungen mit Regel-ID, Schweregrad, Text und XPath zur betroffenen Stelle. Darunter folgt eine lesbare Darstellung der Rechnung.

• acceptable: keine Fehler, die laut Szenario zur Ablehnung führen. Warnungen sind möglich.
• reject: mindestens ein Fehler (Schema oder Schematron-Regel mit Level „error“). Der Empfänger kann die Rechnung zurückweisen.

Häufige Gründe für „reject“ bei XRechnung sind eine fehlende oder falsche Leitweg-ID als Käuferreferenz (BR-DE-15, siehe Leitweg-ID), fehlende Kontaktdaten des Verkäufers (BR-DE-2, BR-DE-5 bis BR-DE-7), eine falsche Spezifikationskennung in BT-24 oder Summenfehler aus der EN16931 wie BR-CO-15. Die EN16931-Fehler und die BR-DE-Fehler finden Sie auch mit unserem Online-Validator; Schemafehler zeigt nur der KoSIT Validator.

Online-Vorprüfung mit unserem Validator, wenn Sie schnell wissen wollen, ob eine Rechnung die europäische Norm und die XRechnung-Regeln erfüllt: beim Testen einer neuen Rechnungssoftware, bei einer Rückfrage eines Kunden, bei Rechnungen über Peppol an Empfänger in anderen Ländern oder wenn Sie kein Java installieren dürfen. Sie sehen jeden Fehler mit Regel-ID und Hinweis zur Behebung.

KoSIT Validator, wenn die Rechnung als XRechnung an eine öffentliche Stelle geht (ZRE, OZG-RE oder ein Landesportal), wenn ein Empfänger ausdrücklich XRechnung-Konformität verlangt oder wenn Sie die Prüfung automatisiert im eigenen System brauchen. Nur der KoSIT Validator mit der aktuellen Konfiguration prüft zusätzlich das XML Schema und gibt die offizielle Annahmeempfehlung.

In der Praxis ergänzen sich beide: Erst die EN16931- und BR-DE-Fehler online finden und beheben, dann die XRechnung im KoSIT Validator abschließend prüfen. Mehr zu den Formaten auf XRechnung Validator, E-Rechnung Validator und im Vergleich ZUGFeRD, Factur-X und XRechnung.