Validierungsfehler bei E-Rechnungen verstehen
Direkte Antwort: Ein Validierungsbericht listet Verstöße gegen Regeln mit einer ID. Die ID verrät die Herkunft: BR-xx und BR-CO-xx sind Geschäftsregeln der europäischen Norm EN 16931, BR-S/Z/E/AE/K/G/O-xx Steuerkategorie-Regeln, BR-CL-xx Codelisten, BR-DEC-xx Nachkommastellen, UBL-SR/UBL-CR/CII-SR/CII-DT Syntaxregeln, BR-DE-xx deutsche XRechnung-Regeln. Fehler mit Schweregrad „fatal“/„error“ führen beim KoSIT-Validator zur Ablehnung; „warning“ nicht. Technisch bedeutsam sind alle; umsatzsteuerlich relevant sind nach dem BMF nur Fehler, die Pflichtangaben betreffen.
Die vier Prüfstufen
- XML-Syntax: Ist die Datei wohlgeformt? Ein Syntaxfehler („Element nicht geschlossen“) stoppt alles – die Datei ist keine verarbeitbare E-Rechnung.
- XML-Schema (XSD): Stimmen Elementnamen, Reihenfolge und Datentypen mit UBL 2.1 bzw. CII D16B überein? Typische Meldung: „Element ‘cbc:ID’: This element is not expected. Expected is cbc:IssueDate.“ Bei Schemafehlern überspringt der Validator die Regelprüfung.
- Geschäftsregeln EN 16931 (Schematron): Inhaltliche Regeln, die über das Schema hinausgehen – Pflichtfelder, Summen, Codes.
- Nationale Regeln (XRechnung) bzw. Profilregeln (Factur-X): Zusätzliche Anforderungen des jeweiligen Standards.
Der Prüfbericht trennt diese Stufen, nennt Regel-ID, Originalmeldung, eine deutsche Erklärung und den XML-Pfad zur betroffenen Stelle.
Die häufigsten Fehler und was zu tun ist
| Regel | Bedeutung | Lösung |
|---|---|---|
| BR-DE-15 | Käuferreferenz (BT-10) fehlt | Leitweg-ID bzw. vereinbarte Referenz eintragen (Anleitung) |
| BR-DE-2, -5, -6, -7 | Verkäuferkontakt (Name, Telefon, E-Mail) fehlt | Ansprechperson mit Telefon und E-Mail angeben |
| BR-DE-1 / BR-DE-13 | Zahlungsangaben fehlen oder passen nicht zum Zahlungsmittel | Für Überweisung IBAN angeben; Code 58 = SEPA-Überweisung |
| BR-CO-10 … BR-CO-16 | Summen stimmen nicht: Positionssumme, Netto, Steuer, Brutto, Zahlbetrag | Rundung je Position prüfen; BT-106 muss die exakte Summe aller BT-131 sein |
| BR-CO-17 | Steuerbetrag ≠ Bemessungsgrundlage × Satz | Steuer je Kategorie auf 2 Stellen kaufmännisch runden, nicht je Position |
| BR-S-08 / BR-S-09 | Bemessungsgrundlage oder Steuerbetrag der Kategorie S passt nicht zu den Positionen | Alle Positionen und Nachlässe derselben Kategorie und desselben Satzes zusammenfassen |
| BR-E-10, BR-AE-10, BR-K-10 … | Befreiungsgrund fehlt (oder ist bei S angegeben) | Bei steuerfreien Kategorien Grund (BT-120) oder Code (BT-121) angeben |
| BR-CL-23 | Mengeneinheit nicht aus UN/ECE Rec. 20/21 | C62 oder H87 für Stück, HUR für Stunde, KGM für kg |
| BR-CL-10/11/21/25 | Schemakennung nicht aus ISO 6523 / EAS | Für GTIN 0160, für E-Mail als elektronische Adresse EM, Leitweg-ID 0204 |
| BR-DEC-xx | Mehr als zwei Nachkommastellen bei Beträgen | Beträge runden; Preise (BT-146) dürfen mehr Stellen haben |
| UBL-CR-xxx | Element in der EN 16931 nicht vorgesehen (Warnung) | Element entfernen, sofern nicht vom Profil erlaubt |
| CII-SR-xxx / UBL-SR-xxx | Kardinalität oder Struktur weicht ab (z. B. Element doppelt) | Struktur nach Syntaxbindung korrigieren |
| BR-TMP-x | Temporäre KoSIT-Regel, meist Datumsformat | Datum als YYYY-MM-DD (UBL) bzw. YYYYMMDD mit format 102 (CII) |
Beispiel: ein Bericht, Schritt für Schritt
Die Prüfung einer UBL-Datei liefert:
- Fehler BR-CO-16: „Amount due for payment (BT-115) = Invoice total amount with VAT (BT-112) − Paid amount (BT-113) + Rounding amount (BT-114).“ Im Reiter „Nachrechnung“ sieht man: Brutto 1.190,00, gezahlt 0,00, Zahlbetrag 1.000,00 – der Zahlbetrag wurde offenbar aus dem Nettobetrag übernommen. Software des Ausstellers korrigieren, neue Rechnung anfordern.
- Warnung BR-CL-23: Mengeneinheit „Stk“. Technisch unschön, verhindert die Annahme beim KoSIT-Validator nicht (Schweregrad in der Konfiguration auf „warning“ gesetzt), bei manchen Empfängern aber doch.
- Information UBL-CR-646: Unterpositionen – im Standardprofil ein Fehler, in der XRechnung-Extension erlaubt.
Ergebnis: „Technische Prüfung nicht bestanden“ wegen BR-CO-16. Die Rechnung ist formal eine E-Rechnung (kein Formatfehler), aber nicht ordnungsgemäß (Geschäftsregelfehler) – so auch die Einordnung des BMF.
Schweregrade und Annahme
Der KoSIT-Validator kennt „error“ (Ablehnung) und „warning“ (Annahme mit Hinweis) und passt einzelne CEN-Regeln per Konfiguration an – etwa BR-CL-23 und BR-CL-21 auf „warning“ im Standardprofil. Das Werkzeug hier übernimmt diese Konfiguration (Stand 2026-08-31), damit die Ergebnisse vergleichbar sind. Andere Empfänger (Buchhaltungssysteme, Peppol-Zugangspunkte) können strenger oder milder sein.
Was ein bestandener Bericht nicht bedeutet
Keine Regel prüft, ob die Leistung erbracht wurde, ob der Steuersatz richtig ist, ob die IBAN dem Lieferanten gehört oder ob die Rechnung echt ist. „Technische Prüfung bestanden“ ist eine notwendige, keine hinreichende Bedingung für die Zahlung. Das BMF empfiehlt, den Validierungsbericht aufzubewahren – er dokumentiert die Sorgfalt des Empfängers.
Häufige Fehler beim Umgang mit Berichten
- Warnungen ignorieren, die beim konkreten Empfänger Ablehnungsgründe sind (Portale veröffentlichen ihre Regeln).
- Die Datei „reparieren“, statt den Aussteller zu informieren: Eine veränderte Rechnung ist keine Rechnung des Ausstellers mehr.
- Alte Regelversionen nutzen: Prüfregeln ändern sich halbjährlich; der Bericht nennt die Version.
Grenzen
Erklärungen und Schweregrade beziehen sich auf CEN 1.3.16, XRechnung Schematron 2.6.0 (Spezifikation 3.0.2) und Factur-X 1.09.2. Peppol-spezifische Regeln (PEPPOL-EN16931-R*) sind nicht enthalten.
Passendes Werkzeug: E-Rechnung prüfen – lokal im Browser, ohne Datei-Upload.
Quellen
- CEN EN 16931 Validation Artefacts (Business Rules BR-*, BR-CO-*, BR-CL-*, Syntaxregeln UBL-*/CII-*) (abgerufen 21.10.2026)
- KoSIT XRechnung Schematron 2.6.0 (Regeln BR-DE-*, BR-DEX-*, BR-TMP-*) (abgerufen 21.10.2026)
- KoSIT Validator-Konfiguration XRechnung 2026-08-31 (Schweregrade, Annahme/Ablehnung) (abgerufen 21.10.2026)
- BMF-Schreiben vom 15.10.2025 – Formatfehler vs. Geschäftsregelfehler; Validierungsbericht aufbewahren (abgerufen 21.10.2026)