Auf dieser Seite

Geprüft auf Basis von XRechnung 3.0.2 / KoSIT-Validator v1.6.x, Validator-Konfiguration 2026-01-31 (Stand Februar 2026). Dieser Artikel richtet sich an ERP-Berater, IT-Verantwortliche und Steuerberater mit technischem Hintergrund.

Eine XRechnung besteht aus strukturiertem XML – doch „das XML ist vorhanden" reicht nicht. Drei unabhängige Prüfebenen entscheiden, ob die Datei normkonform ist: die Schemastruktur (XSD), die europäischen Geschäftsregeln (EN 16931) und die deutschen Sonderregeln (CIUS BR-DE). Wer alle drei Ebenen kennt, kann Validierungsfehler im ERP-System gezielt beheben und seinen Rechnungseingang dauerhaft sauber halten.

Den kaufmännischen Überblick und die Tool-Demonstration bietet die Angebots-Seite zu XRechnung prüfen und validieren. Weitere Werkzeuge für den Rechnungseingang sind in den Lösungen im Überblick zusammengestellt.

Die drei Validierungsebenen im Überblick

Ebene Standard Werkzeug Typischer Fehlertyp
1 – Struktur XML Schema (XSD) KoSIT Validator, Saxon Syntax, Elementreihenfolge, Pflichtattribute, Datumsformat
2 – BWL-Logik EN 16931-1 (CEN-Schematron) KoSIT, CEN-Schematron-Paket Berechnungsregeln, Code-Listen (ISO 4217, UN/CEFACT), Steuerlogik
3 – CIUS DE XRechnung CIUS BR-DE (Schematron) xrechnung-schematron v2.5.0 Leitweg-ID, Zahlungsanweisungen, dt. Pflichtfelder, Spezifikations-URI

Alle drei Ebenen zusammen ergeben die vollständige KoSIT-Validierung. Der KoSIT Validator ist Open Source (Apache 2.0) und die Referenzimplementierung – sämtliche öffentlichen Online-Validatoren laufen intern auf diesem Stack.

Ebene 1: XML-Schema (XSD)

Das XML-Schema definiert die erlaubte Struktur einer XRechnung: Elementnamen, Reihenfolge, Datentypen und Pflichtattribute. Eine Datei, die hier scheitert, ist strukturell ungültig – kein Schematron-Lauf startet.

Typische XSD-Fehler:

  • Fehlende oder falsch geschriebene Namespaces (UBL: urn:oasis:names:specification:ubl:schema:xsd:Invoice-2, CII: urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100)
  • Elemente in falscher Reihenfolge – UBL und CII schreiben jeweils eine strenge Elementsequenz vor
  • Ungültige Datumsformate: ISO 8601 (YYYY-MM-DD) ist Pflicht; 31.03.2025 oder 2025/03/31 schlagen fehl

XSD-Prüfung im Browser: Produktionsreife JavaScript-Implementierungen für XML-Schema sind nicht verfügbar. Für reine Browser-Umgebungen übernimmt Saxon-JS die Schematron-Prüfung (Ebenen 2 + 3). Ebene 1 erfordert serverseitig Java oder einen KoSIT-REST-Daemon (siehe unten).

Ebene 2: Schematron EN 16931

Die EU-Norm EN 16931-1 definiert das semantische Datenmodell für elektronische Rechnungen. Der zugehörige Schematron-Satz – herausgegeben durch das CEN Technical Committee 434 – prüft Geschäftslogik:

  • BR-CO-17: Umsatzsteuerberechnung je Steuergruppe – BT-117 = round(BT-116 × BT-119 / 100, 2). Rundungsabweichungen über 0,01 EUR gelten als Fehler.
  • BR-CO-09 / BR-CO-10 / BR-CO-11: Summenintegrität – Positionssummen, Gesamtnettobetrag, Steuerbetrag und Bruttobetrag müssen algebraisch korrekt aufgehen.
  • Code-Listen: Währung nach ISO 4217, Mengeneinheit nach UN/CEFACT Rec. 20, Ländercode nach ISO 3166-1 alpha-2. Freitext statt Code löst BR-CL-Fehler aus.
  • Steuercode-Logik: Steuercode S (Standardsatz) erfordert befülltes BT-119 (Steuerprozentsatz); Steuercode E (steuerbefreit) erfordert BT-121 (Steuerbefreiungsgrund) oder BT-120 (VATEX-Code).

Ebene 3: Schematron CIUS BR-DE (deutsche Sonderregeln)

Die deutschen CIUS-Regeln sind im Paket itplr-kosit/xrechnung-schematron (v2.5.0, Februar 2026, MIT-Lizenz) veröffentlicht. Sie ergänzen EN 16931 um nationale Anforderungen – eine Rechnung kann EN-16931-konform sein und trotzdem an CIUS BR-DE scheitern.

Wichtige CIUS BR-DE-Regeln im Überblick:

Regel Betroffenes Feld Was wird geprüft
BR-DE-15 BT-10 Buyer Reference Feld muss vorhanden und nicht leer sein
BR-DE-1 BG-16 Zahlungsanweisungen Wenn BT-20 (Zahlungsbedingungen) gesetzt, muss BG-16 vollständig befüllt sein
BR-DE-2 BT-31 / BT-32 USt-IdNr. oder Steuernummer des Verkäufers ist Pflicht
BR-DE-25 BT-24 Specification Identifier Muss gültigen XRechnung-Spezifikations-URI enthalten

Die Kompilierungskette: .sch-Quellen → SchXslt 1.10.1 → .xsl → optional .sef.json für Saxon-JS im Browser.

KoSIT-Validator: CLI und REST-Daemon

Der KoSIT Validator (Apache 2.0, Java 11+) ist die Referenzimplementierung. Er kombiniert alle drei Ebenen in einem Lauf und liefert einen SVRL-Report (Schematron Validation Reporting Language) sowie optional ein HTML-Protokoll.

CLI-Betrieb

java -jar validationtool-1.6.x-standalone.jar \
  -s xrechnung-configuration-2026-01-31.xml \
  -o ./reports \
  rechnung.xml

Die Konfigurationsdatei xrechnung-configuration-2026-01-31.xml aus dem Paket validator-configuration-xrechnung bündelt die abgestimmte Kombination: KoSIT Validator v1.6.0 + xrechnung-schematron v2.5.0 + CEN-Schematron für EN 16931.

REST-Daemon-Modus

Der -D-Schalter startet einen HTTP-Server – ideal für ERP-Integration oder als Microservice im Docker-Container:

java -jar validationtool-1.6.x-standalone.jar \
  -s xrechnung-configuration-2026-01-31.xml \
  -D -H localhost -P 8080

Dokumente werden dann per HTTP POST eingereicht:

curl -X POST http://localhost:8080/ \
  -F "file=@rechnung.xml" \
  --output report.xml

Der Report enthält strukturierten SVRL mit svrl:failed-assert-Elementen je verletzter Regel – maschinenlesbar für automatische Weiterverarbeitung.

Browser-Pipeline: Saxon-JS + SchXslt

Für rein client-seitige Prüfung ohne Datei-Upload eignet sich folgende Pipeline, die Ebenen 2 und 3 vollständig abdeckt:

xrechnung-schematron v2.5.0
  └─ .sch-Quellen (EN-16931 + BR-DE-Regeln)
       └─ SchXslt 1.10.1  →  .xsl (XSLT 3.0)
            └─ sef-Kompilierung  →  .sef.json
                 └─ Saxon-JS 2.x im Browser  →  SVRL-Report
                      └─ SVRL-Parser  →  lesbare Fehlerliste

Die .sef.json-Dateien werden offline vorcompiliert und als statische Assets ausgeliefert – kein Build-Schritt im Browser, keine externe Abhängigkeit zur Laufzeit. Saxon-JS führt die XSLT-3.0-Stylesheets direkt im JavaScript-Kontext aus.

Diese Pipeline erfasst in der Praxis über 95 % der praxisrelevanten Fehler. Reine Ebene-1-Fehler (kaputtes XML, falsche Namespace-Deklaration) fallen bereits beim XML-Parsen im Browser auf, bevor Schematron anläuft.

Datenschutzvorteil: Da alle Verarbeitungsschritte lokal im Browser stattfinden, verlässt das XML-Dokument das Endgerät nicht – datenschutzrechtlich relevant bei Rechnungen mit personenbezogenen Daten.

Fehlercode-Lexikon

BR-CO-17 {#br-co-17}

Regeltext (EN 16931): VAT category tax amount (BT-117) = VAT category taxable amount (BT-116) × (VAT category rate (BT-119) / 100)

Ursache: Rundungsabweichung oder falsch konfigurierter Steuersatz. Viele ERP-Systeme runden Zwischenwerte auf vier oder mehr Nachkommastellen und liefern BT-117-Werte, die sich von der XML-Nachberechnung auf zwei Stellen um mehr als 0,01 EUR unterscheiden.

Behebung:

  1. BT-116 (Nettobetrag je Steuergruppe) und BT-119 (Steuersatz) aus der XML-Datei auslesen.
  2. BT-117 manuell nachrechnen: round(BT-116 × BT-119 / 100, 2).
  3. Abweichung > 0,01 EUR → ERP-Rundungslogik prüfen oder Steuerkonfiguration korrigieren.
  4. Mehrere Steuergruppen (z. B. 7 % und 19 %): jede Gruppe wird separat geprüft – alle müssen stimmen.

BR-DE-15 {#br-de-15}

Regeltext (CIUS BR-DE): Das Element „Buyer reference" (BT-10) muss übermittelt werden.

Betroffenes Feld: BT-10 Buyer Reference – im B2G-Kontext: Leitweg-ID der empfangenden Behörde; im B2B-Kontext: interne Bestell- oder Projektreferenz des Käufers.

Ursache: BT-10 fehlt in der XML-Datei oder ist leer.

Behebung:

  1. Leitweg-ID beim Rechnungsempfänger erfragen – sie hat die Form 991-12345678-06 (Trennzeichen Bindestrich, keine Leerzeichen, kein anderes Sonderzeichen).
  2. In den Kundenstammdaten hinterlegen, damit jede ausgehende Rechnung das Feld automatisch befüllt.
  3. XML-Element prüfen:
    • UBL: <cbc:BuyerReference>991-12345678-06</cbc:BuyerReference>
    • CII: <ram:BuyerOrderReferencedDocument><ram:IssuerAssignedID>991-12345678-06</ram:IssuerAssignedID></ram:BuyerOrderReferencedDocument>

BR-DE-1 {#br-de-1}

Regeltext (CIUS BR-DE): Wenn Zahlungsbedingungen (BT-20) angegeben werden, müssen vollständige Zahlungsanweisungen (BG-16) übermittelt werden.

Ursache: BT-20 (Zahlungsbedingungstext, z. B. „Zahlbar netto 30 Tage") ist befüllt, aber BG-16 (Zahlungsanweisungen) fehlt – oder BT-81 (Zahlungsart-Code nach UNCL4461) ist nicht gesetzt. Betrifft eine andere Regelschicht als BR-DE-15 und ein anderes Feld.

Behebung:

  1. BT-81 mit gültigem UNCL4461-Code befüllen (z. B. 58 für SEPA-Überweisung).
  2. Passende Zahlungsdetailgruppe ergänzen:
    • BG-17 (Überweisung): IBAN in BT-84, optional BIC in BT-86.
    • BG-19 (Lastschrift): Mandatsreferenz in BT-89, Gläubiger-ID in BT-90.
  3. Alternativ: BT-20 leer lassen, wenn keine expliziten Zahlungsbedingungen benötigt werden – dann entfällt auch die Pflicht für BG-16.

BT-121 – Steuerbefreiungsgrund {#bt-121}

Regeltext (EN 16931, BR-E-1): Bei Steuercode E (Steuerbefreiung, Steuersatz 0 %) muss BT-121 (Freitext-Begründung) oder BT-120 (VATEX-Code nach EN-16931-Codeliste) vorhanden sein.

Ursache: Rechnung mit 0 % USt ohne Angabe des Befreiungsgrunds. Häufig bei Kleinunternehmern (§ 19 UStG), innergemeinschaftlichen Lieferungen oder Ausfuhrlieferungen.

Behebung:

  1. VATEX-Freitext in BT-121 eintragen, z. B. „Steuerbefreiung gemäß § 4 Nr. 1b UStG – innergemeinschaftliche Lieferung".
  2. Alternativ oder ergänzend: VATEX-Code in BT-120 aus der EN-16931-Codeliste, z. B. VATEX-EU-IC (innergemeinschaftliche Lieferung) oder VATEX-EU-79-C (§ 19 UStG Kleinunternehmer).
  3. ERP-Steuercode-Konfiguration prüfen: der Buchungsschlüssel für 0-%-Positionen muss BT-121 oder BT-120 automatisch mitliefern.

Integrität ohne Signatur: innerbetriebliches Kontrollverfahren (IKV) nach § 14 UStG

XRechnung schreibt keine kryptografische Signatur vor. Das ist kein Versehen: Das BMF-Einführungsschreiben vom 15. Oktober 2024 (Az. III C 2 – S 7287-a/23/10001:007, Fachzusammenfassung bei Deloitte Tax News) stellt klar: Echtheit und Unversehrtheit können durch ein innerbetriebliches Kontrollverfahren (IKV) gesichert werden – einen verlässlichen Prüfpfad, der die empfangene Rechnung mit der zugrunde liegenden Leistung verknüpft. Rechtsgrundlage ist § 14 Abs. 3 Satz 4 UStG.

Was das IKV in der Praxis bedeutet:

  1. Abgleich Bestellung / Lieferung / Rechnung – die Drei-Wege-Prüfung (Purchase Order Matching) ist das klassische IKV.
  2. Formale Validierung als IKV-Bestandteil – der dokumentierte Nachweis, dass jede eingehende Rechnung eine Schematron-Prüfung durchlaufen hat, ist Bestandteil des Prüfpfads.
  3. Aufbewahrungspflicht: Laut BMF-FAQ zur E-Rechnungspflicht muss der strukturierte XML-Teil „unversehrt in seiner ursprünglichen Form" aufbewahrt werden. Das PDF-Rendering ist keine Aufbewahrungsgrundlage.
  4. XML vorrangig bei Hybridformaten – bei ZUGFeRD und Factur-X gilt der eingebettete XML-Teil als maßgeblich gegenüber der visuellen PDF-Ansicht.

Eine qualifizierte elektronische Signatur (QES) ist eine gleichwertige Alternative zum IKV, aber nicht zwingend erforderlich. Wer weder QES noch dokumentiertes IKV nachweisen kann, riskiert im Betriebsprüfungsfall den Verlust des Vorsteuerabzugs. Im Zweifel Steuerberater konsultieren.

Den zeitlichen Rahmen der E-Rechnungspflicht – inklusive Übergangsregelungen 2025–2028 – erklärt die Seite E-Rechnungspflicht 2025–2028.

Ausblick: XRechnung 4.0

KoSIT plant XRechnung 4.0 für die zweite Jahreshälfte 2026, abhängig von der finalen Veröffentlichung der EN 16931-1:2026 (TC 434-Abstimmung für Mitte 2026 angekündigt). Bis dahin ist XRechnung 3.0.2 der gültige Standard. Nach Erscheinen von 4.0 wird es eine Übergangsphase geben, in der beide Versionen akzeptiert werden. Validator-Konfiguration, Schematron-Pakete und ERP-Integrationen, die Versionsnummern explizit nennen, müssen dann aktualisiert werden.

Aktuelle Roadmap: xeinkauf.de/aktuelles/xrechnung/xrechnung-4-umsetzung

Rechnungseingang sauber, Vorsteuer gesichert

Wer eingehende XRechnungen automatisch gegen alle drei Prüfebenen laufen lässt, hat Fehler im Beleg erkannt, bevor sie gebucht werden – und was das wirklich bedeutet: ein dokumentierter Prüfpfad, der im Betriebsprüfungsfall den Vorsteuerabzug und die Glaubwürdigkeit gegenüber dem Finanzamt absichert.

Im Navigator das Passende finden Live-Demo ansehen
Christopher Helm, Maximilian Geissinger, Uwe Martens - die Gründer von liqui.de

Gebaut von Leuten, die denselben Engpass aus der Praxis kennen.

Navigator: Alle Inhalte entlang der Financial Supply Chain auf einen Blick
Navigator: der visuelle Index entlang der Financial Supply Chain
Welche Java-Version braucht der KoSIT-Validator?

Java 11 oder höher. Für den produktiven Dauerbetrieb empfiehlt sich Java 17 LTS. Bei Java 11 muss `org.glassfish.jaxb:jaxb-runtime` als explizite Maven- oder Gradle-Abhängigkeit eingebunden werden, da sie in dieser Version als optional markiert ist.

Kann ich den KoSIT-Validator ohne eigene Java-Infrastruktur nutzen?

Ja – entweder über einen öffentlichen Online-Validator (die intern auf dem KoSIT-Stack laufen) oder über den Browser-Validator-Ansatz mit Saxon-JS für Ebenen 2 und 3. Der Dienst führt alle drei Ebenen serverseitig durch; das Dokument verlässt dabei keine Unternehmensinfrastruktur, da die Prüfung im Eingangs-Postfach stattfindet.

Was ist der Unterschied zwischen EN 16931 und CIUS BR-DE?

EN 16931 ist die europäische Norm – sie gilt für alle EU-Mitgliedstaaten und setzt das semantische Datenmodell für E-Rechnungen. CIUS BR-DE (Core Invoice Usage Specification) ist die **deutsche Einschränkung** dieser Norm: Sie definiert zusätzliche Pflichtfelder und schärfere Regeln, die speziell für Deutschland gelten. Eine XRechnung muss beide Schichten bestehen – eine EN-16931-konforme Rechnung kann trotzdem an BR-DE-15 scheitern, weil die Leitweg-ID eine rein deutsche Anforderung ist.

Warum schlägt mein Validator auf Ebene 3 an, obwohl Ebene 2 grün ist?

CIUS-Regeln sind **zusätzlich** zur EN 16931, kein Subset davon. Typisches Szenario: Die Rechnung besteht die europäischen Geschäftsregeln vollständig, aber BT-10 (Leitweg-ID, BR-DE-15) fehlt oder BG-16 (Zahlungsanweisungen, BR-DE-1) ist unvollständig. Beide Felder sind spezifische deutsche Anforderungen ohne Entsprechung in der europäischen Norm.

Muss ich eine qualifizierte Signatur einsetzen, um §14 UStG zu erfüllen?

Nein – laut BMF-Einführungsschreiben vom 15.10.2024 genügt ein innerbetriebliches Kontrollverfahren (IKV), das einen verlässlichen Prüfpfad zwischen Leistung und Rechnung herstellt. Eine qualifizierte Signatur ist eine gleichwertige Alternative, aber keine Pflicht. Im konkreten Einzelfall entscheidet der Steuerberater.

Wann kommt XRechnung 4.0 und muss ich sofort migrieren?

XRechnung 4.0 ist für H2 2026 geplant, abhängig von EN 16931-1:2026. Es wird eine Übergangsphase geben, in der beide Versionen akzeptiert werden. Aktuelle Informationen veröffentlicht KoSIT auf xeinkauf.de.

Verwandte Seiten: XRechnung prüfen – kaufmännischer Überblick · ZUGFeRD und Factur-X erklärt · E-Rechnungspflicht 2025–2028