XRechnung validieren: KoSIT-Validator, Schematron-Fehler und was sie bedeuten

Der KoSIT-Validator ist die Referenzsoftware, mit der Sie prüfen, ob eine XRechnung tatsächlich normkonform ist, bevor sie beim Empfänger landet oder von einer öffentlichen Vergabestelle zurückgewiesen wird. Er kombiniert eine Prüfung gegen das XML-Schema mit Schematron-Regeln aus der XRechnung-Spezifikation und meldet strukturelle Fehler ebenso wie inhaltliche Verstöße gegen die Rechnungslogik. Wer XRechnungen aus einer eigenen Fakturierung oder aus einem Automatisierungs-Workflow erzeugt, sollte diese Prüfung fest vor dem Versand einplanen, nicht erst dann, wenn eine Rechnung zurückkommt. Stand: August 2026.

Was prüft der KoSIT-Validator eigentlich?

Der KoSIT-Validator durchläuft laut eigener Dokumentation mehrere Schritte: Er erkennt das vorliegende XML-Format, validiert die Datei gegen XML-Schema und Schematron-Regeln, erzeugt daraus einen individuellen Bericht und berechnet einen Annahmestatus. Die eigentlichen Prüfregeln liefert der Validator dabei nicht selbst mit, sondern eine separate Konfiguration, die sogenannte Szenario-Datei. Für XRechnung übernimmt das die XRechnung-Validator-Konfiguration, die Schematron-Regeln aus EN16931 und der deutschen CIUS-Erweiterung XRechnung sowie die passenden XML-Schemas für UBL- und UN/CEFACT-Rechnungen bündelt. Ohne diese Konfiguration prüft der Validator gar nichts, er ist bewusst als generisches Werkzeug gebaut.

Wie starten Sie eine Prüfung über die Kommandozeile?

Sie rufen den Validator als Java-Programm auf und übergeben ihm die Szenario-Konfiguration sowie die zu prüfende Datei. Praktisch heißt das:

• Aufruf: java -jar validator-Version-standalone.jar -s Szenario-Konfigurationsdatei -r Repository-Pfad Dateiname, optional mit weiteren Parametern.
• Hilfe: Der Parameter --help zeigt alle verfügbaren Optionen direkt im Terminal.
• Alternativen: Der Validator lässt sich auch als Java-Bibliothek in eigene Software einbetten oder im Daemon-Modus mit HTTP-Schnittstelle betreiben, über den Parameter -D.

Für einen Automatisierungs-Workflow ist vor allem der Daemon-Modus interessant, weil sich die Prüfung dann per HTTP-Aufruf in eine Pipeline einhängen lässt, statt jedes Mal einen neuen Prozess zu starten.

Was unterscheidet Schema-Fehler von Schematron-Fehlern?

Ein Schema-Fehler bedeutet, dass die XML-Datei nicht dem vorgeschriebenen Aufbau entspricht, etwa ein Pflichtfeld fehlt komplett oder ein Element steht an der falschen Stelle. Das sind meist harte technische Fehler, die vor jeder inhaltlichen Prüfung behoben werden müssen. Ein Schematron-Fehler dagegen bedeutet, dass die Datei zwar strukturell gültig ist, aber eine fachliche Regel der XRechnung-Spezifikation verletzt, etwa eine Summenbildung, die nicht aufgeht, oder ein Steuersatz, der zur gewählten Kategorie nicht passt. Beide Fehlertypen landen im selben XML-Bericht und fließen gemeinsam in den finalen Annahmestatus ein, den der Validator am Ende ausgibt.

Wie lässt sich die Prüfung vor dem Versand automatisieren?

Am zuverlässigsten ist eine Prüfung, die automatisch läuft, bevor eine Rechnung überhaupt das Haus verlässt. In einem n8n-Workflow lässt sich das so umsetzen, dass die generierte XRechnung-XML per HTTP-Request an eine laufende Validator-Instanz im Daemon-Modus geschickt wird und der zurückgelieferte Bericht ausgewertet wird, bevor der Versand-Schritt überhaupt startet. Schlägt die Prüfung fehl, bricht der Workflow ab und meldet den Fehler an die Buchhaltung, statt eine ungültige Rechnung zu verschicken. Genau solche vorgeschalteten Prüf- und Freigabeschritte gehören zu den Automatisierungen, die wir bei NordFlux für Mandanten mit eigener Rechnungsstellung einrichten.

Häufige Fragen zu XRechnung validieren

Reicht die Prüfung mit dem KoSIT-Validator als alleinige Kontrolle vor dem Versand?

Für die technische und fachliche Konformität nach EN16931 und XRechnung-CIUS ja, denn genau dafür ist der Validator gebaut. Er prüft aber nicht, ob die enthaltenen Geschäftsdaten wie Bankverbindung oder Leistungsbeschreibung inhaltlich korrekt sind, das bleibt weiterhin Ihre Verantwortung.

Brauche ich für jede Rechnungsart eine eigene Konfiguration?

Ja, die Szenario-Konfiguration ist an das jeweilige Format gebunden. Für XRechnung nutzen Sie die XRechnung-Validator-Konfiguration, für andere EN16931-Ausprägungen wie ZUGFeRD gibt es entsprechend andere Konfigurationsdateien mit eigenen Schematron-Regeln.

Kann ich den Validator ohne Java-Kenntnisse einsetzen?

Grundkenntnisse der Kommandozeile reichen für den einfachen Aufruf gegen einzelne Dateien aus, eine Java-Entwicklungsumgebung brauchen Sie dafür nicht. Für die Einbindung in einen automatisierten Workflow, etwa über den Daemon-Modus, ist technisches Verständnis für HTTP-Aufrufe hilfreich.

Was passiert, wenn sich die Schematron-Regeln ändern?

Die XRechnung-Schematron-Regeln folgen einer semantischen Versionierung: Hauptversionen bringen inkompatible Regeländerungen, Nebenversionen erweitern gültige Inhalte wie neue Codelisten, und Patch-Versionen beheben rückwärtskompatible Fehler. Es lohnt sich, die verwendete Konfigurationsversion im Blick zu behalten und bei Hauptversionswechseln bestehende Validierungs-Workflows erneut zu testen.