KoSIT-Validator und Browser-Prüfung im Vergleich
Direkte Antwort: Der KoSIT-Validator ist die vom IT-Planungsrat beauftragte Referenzimplementierung: ein Java-Programm, das XML-Schema und Schematron-Regeln nach einer Konfigurationsdatei (scenarios.xml) anwendet und einen Bericht mit Annahme/Ablehnung erzeugt. Belegivo verwendet dieselben Regelwerke in derselben Version (Konfiguration 2026-08-31: CEN 1.3.16, XRechnung 2.6.0) und übernimmt die dort festgelegten Schweregrade – führt sie aber im Browser aus (libxml2 für XSD, Saxon-JS für Schematron). Bei gleicher Eingabe sind die Befunde deshalb gleich; Unterschiede können sich aus Parsern, Zeitpunkten der Regelaktualisierung und dem Berichtsformat ergeben. Im Zweifel gilt der KoSIT-Validator.
Was identisch ist
| Element | KoSIT-Validator | Belegivo |
|---|---|---|
| XML-Schemata | UBL 2.1, CII D16B aus der Konfiguration | dieselben Dateien |
| Schematron | EN16931-UBL/CII-validation.xsl, XRechnung-UBL/CII-validation.xsl | dieselben XSL, zu SEF kompiliert |
| Schweregrade | customLevel in scenarios.xml |
nachgebildet (BR-CL-21/23 Warnung, UBL-CR-646 Fehler, CII-SR-465/466 Fehler, 475/476 Information; Extension-Szenario eigene Stufen) |
| Szenariowahl | nach CustomizationID/Guideline-ID | nach derselben Kennung |
| Reihenfolge | Schema zuerst; bei Schemafehler keine Schematron-Prüfung | gleich |
Die Übereinstimmung wird im Projekt durch Tests belegt: Generierte Rechnungen werden sowohl im Browser als auch mit dem Java-Validator geprüft (Dokumentation unter „Über uns“).
Wo Unterschiede entstehen können
- Berichtsform: KoSIT erzeugt einen XML/HTML-Report mit „Annahme/Ablehnung“; Belegivo einen eigenen Bericht mit deutschen Erklärungen.
- Parser: Unterschiedliche XML-Parser können Grenzfälle (Whitespace, Encodings) anders behandeln.
- Zeitpunkt: Wenn KoSIT eine neue Konfiguration veröffentlicht, muss Belegivo nachziehen; die verwendete Version steht auf jeder Prüfseite.
- Nicht enthalten: KoSIT prüft Factur-X-Profile und PDF nicht; Belegivo ergänzt die Factur-X-Schematrons und PDF-Metadaten-Checks.
Wann der Java-Validator selbst sinnvoll ist
- Automatisierte Massenprüfung (Kommandozeile, Daemon-Modus).
- Nachweis gegenüber Dritten mit dem offiziellen Bericht.
- Prüfung mit eigenen Szenarien oder Konfigurationen.
Installation: Java 11+, validator-1.6.3-standalone.jar und die Konfiguration herunterladen, dann java -jar validator.jar -s scenarios.xml -r <Konfigurationsordner> rechnung.xml.
Beispiel
Ein Rechnungseingangssystem lehnt eine Datei mit „BR-CL-23“ ab. Belegivo meldet dieselbe Regel als Warnung – wie der KoSIT-Validator im Standardprofil. Das Eingangssystem ist strenger konfiguriert. Der Befund ist in allen drei Werkzeugen derselbe; nur die Konsequenz unterscheidet sich.
Häufige Fehler
- Unterschiedliche Regelversionen vergleichen.
- „Vom KoSIT-Validator akzeptiert“ mit „vom Empfänger akzeptiert“ gleichsetzen.
- Annehmen, Browser-Prüfung sei eine Vereinfachung – es sind dieselben Regelwerke.
Grenzen
Aussagen zur Übereinstimmung gelten für die dokumentierte Version; prüfen Sie bei Zweifeln mit dem Java-Validator nach.
Passendes Werkzeug: E-Rechnung prüfen – lokal im Browser, ohne Datei-Upload.
Quellen
- KoSIT Validator 1.6.3 (Open Source, Apache-2.0) (abgerufen 22.10.2026)
- KoSIT Validator-Konfiguration XRechnung 2026-08-31 (scenarios.xml, Schweregrade) (abgerufen 22.10.2026)
- Belegivo: Testdokumentation (Abgleich mit KoSIT-Validator und Mustang) (abgerufen 22.10.2026)