XRechnung-Validator: XRechnung prüfen mit dem KoSIT-Validator

Eine formal fehlerhafte XRechnung kommt nicht mit einer Rückfrage zurück – sie kommt gar nicht an. Die Rechnungseingangsplattformen von Bund und Ländern prüfen jede Datei maschinell und lehnen ab, was die Prüfung nicht besteht. Validierung ist deshalb keine Kür für Techniker, sondern der Schritt zwischen „eingereicht" und „abgelehnt". Dieser Artikel zeigt, was der offizielle KoSIT-Validator prüft, wie Sie ihn kostenlos einsetzen, wie Sie den Prüfbericht lesen und welche zehn Fehler am häufigsten auftauchen.

Warum Validierung bei der XRechnung Pflicht in der Praxis ist

Die XRechnung ist eine reine XML-Datei nach EN 16931. Kein Sachbearbeiter ruft bei einer fehlenden Angabe an – die Datei geht in ein System, und das System entscheidet. ZRE, OZG-RE und die Landesportale prüfen jede Datei gegen dieselben Regeln wie der KoSIT-Validator. Fällt die Prüfung durch, kommt eine Ablehnung mit Prüfbericht; die Rechnung gilt als nicht zugestellt, das Zahlungsziel läuft nicht.

Im B2B ist es weicher, aber nicht besser: Eine XRechnung, die die Software des Kunden nicht einlesen kann, bleibt liegen, bis jemand nachfragt – und anders als bei einer PDF sieht der Kunde nur eine Fehlermeldung.

Deshalb wird jede XRechnung vor dem Versand validiert. Idealerweise tut das Ihr Rechnungsprogramm automatisch. Wenn nicht – oder wenn Sie prüfen wollen, ob es das wirklich tut – kommt der KoSIT-Validator ins Spiel.

Was der KoSIT-Validator prüft

Der Validator ist ein Java-Programm der KoSIT, die auch die XRechnung-Spezifikation herausgibt. Er selbst ist formatneutral; was er prüft, steckt in der Prüfkonfiguration, die die KoSIT je XRechnung-Version veröffentlicht. Die Prüfung läuft in drei Stufen:

1. Schema. Ist die Datei syntaktisch gültiges UBL oder UN/CEFACT CII – Elementnamen, Reihenfolge, Datentypen? Ein Datum 11.09.2026 statt 2026-09-11 scheitert schon hier, ebenso ein Betrag mit Komma. Schemafehler sind immer Ablehnungsgründe.

2. EN-16931-Schematron. Die europäischen Geschäftsregeln: Pflichtfelder (BR-…), Rechenregeln (BR-CO-…), Steuerkategorien (BR-S-…, BR-E-…, BR-AE-…), Codelisten (BR-CL-…). Hier fällt auf, wenn Summen nicht aufgehen.

3. XRechnung-Schematron. Die deutschen Zusatzregeln der CIUS, erkennbar am Präfix BR-DE-…. Sie machen Felder zur Pflicht, die in der Norm optional sind: Zahlungsangaben, Verkäuferkontakt, Leitweg-ID, Steuernummer oder USt-IdNr.

Die Konfiguration muss zur XRechnung-Version der Datei passen: Die CustomizationID sagt, welche Version die Datei beansprucht, die Konfiguration bringt je Version ein Prüfszenario mit. Aktuell gilt XRechnung 3.0 – laut KoSIT bis mindestens 31. Juli 2027, weil es im Sommer 2026 kein normatives Release gab. Eine Datei, die sich als 2.3 ausgibt, findet kein Szenario mehr und wird abgelehnt, bevor die Prüfung beginnt.

Schritt für Schritt: XRechnung mit dem KoSIT-Validator prüfen

Der Validator ist kostenlos und quelloffen; mit etwas Kommandozeilen-Erfahrung ist er auch für Anwender machbar.

1. Java installieren

Sie brauchen eine Java-Laufzeit, Java 17 oder neuer ist die sichere Wahl. Prüfen Sie im Terminal mit java -version. Fehlt Java, ist Eclipse Temurin (adoptium.net) eine kostenlose Quelle.

2. Validator und Konfiguration herunterladen

Beides liegt auf GitHub:

• Validator: github.com/itplr-kosit/validator – unter „Releases" die Datei validator-<version>-standalone.jar, aktuell 1.6.2.
• XRechnung-Konfiguration: github.com/itplr-kosit/validator-configuration-xrechnung – das ZIP der aktuellen Version, etwa xrechnung-3.0.2-validator-configuration-2026-01-31.zip. Entpacken Sie es in einen Ordner config; darin liegt die Datei scenarios.xml.

3. Prüfung starten

Im Ordner mit der JAR-Datei:

java -jar validator-1.6.2-standalone.jar -s config/scenarios.xml -r config rechnung.xml

-s zeigt auf die Szenariendatei, -r auf den Ordner mit den Schemata und Schematron-Regeln, danach folgen eine oder mehrere zu prüfende Dateien. Der Validator schreibt für jede Datei einen Bericht rechnung-report.xml neben die Aufrufstelle. Mit der Option -h legt er zusätzlich eine HTML-Fassung ab, die sich im Browser lesen lässt. Der Rückgabewert ist 0, wenn alles angenommen wurde, sonst die Zahl der abgelehnten Dateien.

Den Prüfbericht lesen

Der Bericht beginnt mit dem Ergebnis: angenommen oder abgelehnt. Darunter stehen die Prüfstufen mit ihren Meldungen. Jede Meldung hat drei Teile:

• Schwere: error (Fehler) oder warning (Warnung). Ein einziger Fehler führt zur Ablehnung. Warnungen ändern das Ergebnis nicht, weisen aber auf Angaben hin, die ein Empfänger beanstanden könnte – etwa einen unüblichen Rechnungstyp-Code.
• Regel-ID: BR-DE-15, BR-CO-10, BR-S-08. Das Präfix sagt, woher die Regel kommt: BR-DE aus der XRechnung, BR-CO sind Rechenregeln der EN 16931, BR-S/BR-E/BR-AE betreffen Steuerkategorien, BR-CL Codelisten.
• Text und Fundstelle: Die Meldung nennt das betroffene Feld mit seiner BT-Nummer und den XPath, an dem der Validator gesucht hat.

Ein Schemafehler sieht anders aus: keine Regel-ID, sondern eine Meldung des XML-Parsers wie cvc-datatype-valid mit Zeilenangabe. Dann ist die Datei strukturell falsch, und die Geschäftsregeln wurden gar nicht geprüft. Beheben Sie Schemafehler zuerst; danach tauchen oft weitere Meldungen auf.

Die zehn häufigsten Fehler und ihre Behebung

Die Regel-IDs stammen aus dem XRechnung-Schematron der KoSIT und der EN 16931.

1. BR-DE-1 – Zahlungsangaben fehlen. Eine XRechnung muss die Gruppe „Payment instructions" (BG-16) enthalten: Zahlungsart und bei Überweisung die Bankverbindung. Behebung: Zahlungsart 58 (SEPA-Überweisung) und IBAN eintragen.

2. BR-DE-15 – Leitweg-ID fehlt. Die „Buyer reference" (BT-10) ist Pflicht. Bei Behörden gehört dort die Leitweg-ID hinein, im B2B eine Kundenreferenz. Häufige Ursache: Die Leitweg-ID steht in der Bestellnummer (BT-13) oder im Freitext. Behebung: in BT-10 verschieben, Prüfziffer kontrollieren.

3. BR-DE-2 – Kontaktdaten des Verkäufers fehlen. Die Gruppe „Seller contact" (BG-6) mit Ansprechpartner, Telefon und E-Mail ist Pflicht. Behebung: alle drei Angaben hinterlegen – ein Feld allein reicht nicht.

4. BR-DE-16 – Steuernummer oder USt-IdNr. fehlt. Mindestens eine steuerliche Kennung des Verkäufers muss vorhanden sein: USt-IdNr. (BT-31) oder Steuernummer (BT-32). Behebung: eine der beiden im Firmenstamm eintragen; die USt-IdNr. gehört mit Länderkürzel DE hinein.

5. BR-CO-10 – Summe der Positionen stimmt nicht. Die Summe aller Positionsnettobeträge (BT-131) muss dem Feld „Sum of Invoice line net amount" (BT-106) entsprechen. Ursache: Positionen anders gerundet als die Kopfsumme, oder eine Position nach der Berechnung geändert. Behebung: neu berechnen, zwei Nachkommastellen, an einer Stelle runden.

6. BR-CO-15 – Bruttobetrag geht nicht auf. Rechnungsbetrag mit USt (BT-112) muss gleich Betrag ohne USt (BT-109) plus USt-Gesamtbetrag (BT-110) sein. Meist eine Folge von Fehler 5 oder ein Rundungsfehler beim USt-Betrag.

7. BR-DE-13 – Zahlungsart und Zahlungsgruppe passen nicht zusammen. Genau eine der Gruppen Überweisung (BG-17), Karte (BG-18) oder Lastschrift (BG-19) muss vorhanden sein. Entsteht, wenn Zahlungsart 58 angegeben ist, aber kein Kontoblock folgt – oder umgekehrt.

8. BR-DE-19 – IBAN fehlt oder ist ungültig. Bei SEPA-Überweisung (Code 58) muss das Feld „Payment account identifier" (BT-84) eine formal gültige IBAN enthalten. Behebung: IBAN ohne Leerzeichen eintragen, Prüfsumme kontrollieren.

9. BR-DE-21 – Falsche oder veraltete CustomizationID. Das Feld BT-24 muss exakt die Kennung der XRechnung-Version tragen, für 3.0: urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0. Ein Tippfehler oder eine 2.x-Kennung führt zur Ablehnung. Behebung: Kennung aus der Spezifikation kopieren; alte Software aktualisieren.

10. Datumsformat oder Dezimaltrennzeichen falsch. Kein Geschäftsregelfehler, sondern ein Schemafehler: Daten müssen als JJJJ-MM-TT vorliegen, Beträge mit Punkt und höchstens zwei Nachkommastellen. Meist ist eine Lokalisierung auf „Deutsch" im erzeugenden Programm der Übeltäter.

Klassiker jenseits der Top Ten: Kleinunternehmer nach § 19 UStG mit Steuerkategorie S und 0 % statt E; Mengeneinheit als Text statt Code (HUR, H87); fehlende E-Mail des Käufers (BT-49); weder Fälligkeit noch Zahlungsbedingungen bei positivem Zahlbetrag (BR-CO-25). Wie eine vollständige Datei aussieht, zeigt das XRechnung-Beispiel; welche Angaben bereitliegen müssen, der Artikel XRechnung erstellen.

Alternativen zum Selbst-Validieren

Drei Wege liefern ein Ergebnis ohne Kommandozeile:

ELSTER E-Rechnungs-Viewer. Kostenlos auf elster.de: Datei hochladen, Rechnung lesbar sehen, formale Fehler angezeigt, keine Speicherung. Ersetzt nicht die volle Regelprüfung, entdeckt aber die meisten Schema- und Pflichtfeldfehler.

Quba-Viewer. Kostenlos, Open Source, für Windows, macOS und Linux; öffnet XRechnung und ZUGFeRD lokal und zeigt Validierungsmeldungen. Für alle, die nichts hochladen möchten.

Der Pennio-Prüfer. Unter E-Rechnung prüfen lesen Sie eine XRechnung im Browser: Absender, Empfänger, Positionen, Steuern und Summen lesbar, dazu eine Prüfung der Pflichtfelder, der Rechenregeln und der deutschen Zusatzregeln (Leitweg-ID, Kontaktdaten). Nichts wird hochgeladen. Für die verbindliche Prüfung gegen sämtliche Schematron-Regeln bleibt der KoSIT-Validator maßgeblich.

Portal-Test. Die ZRE stellt registrierten Nutzern eine Testumgebung bereit, in der sich Dateien ohne echte Rechnung einreichen lassen – dieselbe Plattform, dieselben Regeln. Lohnt sich vor der ersten Behördenrechnung.

Für den Alltag ist keiner dieser Wege die Lösung, sondern ein Rechnungsprogramm mit eingebautem KoSIT-Validator, das jede Datei beim Festschreiben prüft. Mehr dazu im Artikel E-Rechnung prüfen; für das hybride Schwesterformat gilt dasselbe mit anderem Prüfer, siehe ZUGFeRD-Validator.

Wenn die Rechnung schon verschickt ist

Der Fehler fällt auf, aber die Rechnung ist schon raus – zwei Fälle:

Das Portal hat abgelehnt. Dann gilt die Rechnung als nicht eingereicht; die korrigierte Datei können Sie in der Regel unter derselben Nummer erneut einreichen. Bewahren Sie die Ablehnung mit Prüfbericht auf – sie belegt, warum es zwei Dateien mit einer Nummer gibt.

Der Kunde hat die Rechnung erhalten. Dann ist sie in der Welt und darf nicht mehr verändert werden – GoBD und § 14 UStG verlangen Unveränderbarkeit. Der Weg ist die Stornorechnung mit eigener Nummer und Bezug auf das Original, danach eine neue, korrekte Rechnung. Wie das geht, steht im Artikel Stornorechnung schreiben.

Beide Fälle zeigen, warum die Validierung vor dem Festschreiben gehört: Ist die Nummer gezogen und die Datei raus, kostet jeder Fehler zwei weitere Belege.

Häufige Fragen

Stand: September 2026. Quellen: KoSIT-Validator und XRechnung-Prüfkonfiguration (github.com/itplr-kosit), XRechnung-Spezifikation 3.0 mit Schematron-Regeln BR-DE (KoSIT), EN 16931 Geschäftsregeln BR-CO, E-Rechnungsverordnung (ERechV), § 14 UStG.