Eine XRechnung-Validierung bricht nicht ab, sie liefert einen Prüfbericht mit Zeilen wie „val-xsd” oder einem Code „BR-DE-15”. Diese Meldungen sind kein Fließtext, sondern ein fester Verweis auf eine konkrete Regel. Wer den Code kennt, findet die Ursache in Sekunden statt beim Durchsuchen der ganzen Rechnung.
Die meisten Ablehnungen haben eine von drei Ursachen: ein kaputtes XML-Schema, eine verletzte Geschäftsregel oder ein inhaltlich falscher Rechnungswert. Dieser Artikel ordnet die häufigsten Codes den drei Kategorien zu und nennt zu jedem die konkrete Lösung.
Was zeigt der Prüfbericht des KoSIT-Validators überhaupt?
Der KoSIT-Validator, die Referenzsoftware der Koordinierungsstelle für IT-Standards, prüft eine hochgeladene XRechnung in drei Schritten: die Verwendung des korrekten Syntaxschemas, die EN-16931-Kernregeln und die XRechnungs-spezifischen Regeln. Jeder Schritt erzeugt eigene Zeilen im Prüfbericht. Die offizielle Validator-Dokumentation des Landes Baden-Württemberg zeigt den Aufbau eines solchen Berichts: eine Tabelle mit den Spalten Pos (welcher Prüfschritt, zum Beispiel val-xsd), Code (die verletzte Regel), Grad (Fehler, Warnung oder Information) und Text (die eigentliche Meldung).
Das Ergebnis ist eine Empfehlung, keine automatische Entscheidung: Bei null Fehlern erscheint ein grün hervorgehobener Bericht mit der Empfehlung „anzunehmen und weiter zu verarbeiten”. Enthält der Bericht Fehler, erscheint er rot mit der Empfehlung, das Dokument zurückzuweisen. Enthält er nur Warnungen, kann trotz bestehender Mängel eine Annahme empfohlen werden, weil die konkrete Stelle die Fehler aktuell toleriert.
Für die Konformitätsprüfung macht es keinen Unterschied, ob Sie die Datei direkt beim KoSIT-Validator, in einem Behördenportal oder im eigenen E-Rechnungs-Prüfer hochladen. Alle nutzen dieselben Schematron-Regeln und dieselbe XML-Schema-Prüfung aus der aktuellen XRechnung-Version.
Formatfehler: Wenn das XML selbst nicht lesbar ist
Ein Formatfehler bedeutet, dass die Datei nicht einmal die Grundstruktur einhält, die das UBL- oder CII-Schema vorschreibt. Die Prüfung schlägt bereits in Stufe eins fehl, bevor überhaupt eine Geschäftsregel geprüft wird.
Typisches Beispiel aus der Praxis ist der XML-Schema-Fehlercode cvc-complex-type.2.4.a, dokumentiert in der offiziellen Validator-Beschreibung des Landes Baden-Württemberg. Die Meldung lautet sinngemäß „Invalid content was found starting with element X. One of Y is expected” und bedeutet: An dieser Stelle im XML steht ein Element, das die Schema-Reihenfolge an dieser Position nicht zulässt, meist weil ein vorheriges Pflichtelement fehlt oder ein optionales Element in der falschen Reihenfolge steht. UBL- und CII-Schemata verlangen eine strikte Elementreihenfolge, Freitext-Editoren oder handgepflegte XML-Dateien verletzen sie leicht.
Weitere häufige Formatfehler-Muster:
| Ursache | Typische Meldung | Lösung |
|---|---|---|
| Pflichtelement fehlt oder steht an falscher Position | cvc-complex-type.2.4.a (Invalid content, element expected) | Reihenfolge und Vollständigkeit gegen das UBL- oder CII-Schema prüfen, am besten mit einem Generator statt von Hand |
| Datumsformat nicht XML-konform | ein Xerces-Code aus der Gruppe cvc-datatype-valid | Datum im Format JJJJ-MM-TT übermitteln, kein deutsches TT.MM.JJJJ |
| Pflichtfeld leer oder zu kurz | ein Xerces-Code aus der Gruppe cvc-minLength-valid | Feld mit dem geforderten Mindestinhalt befüllen, zum Beispiel eine nicht leere Rechnungsnummer |
Ein Formatfehler lässt sich fast nie manuell im XML reparieren, ohne das Dokument erneut zu zerstören. Schneller ist es, die Rechnung mit einem Generator neu zu erzeugen, der das Schema von sich aus einhält.
Geschäftsregelfehler: die häufigsten BR-DE- und EN-16931-Codes
Eine Geschäftsregel (Business Rule, kurz BR) prüft nicht die Struktur, sondern eine logische Bedingung zwischen Feldern. Die Codes mit dem Zusatz „DE” stammen aus den ergänzenden nationalen Geschäftsregeln der Spezifikation XRechnung, Codes ohne „DE” aus dem europäischen EN-16931-Kern. Die folgende Tabelle zeigt die Regeln, die in der Praxis am häufigsten auftauchen, mit dem genauen Wortlaut aus der aktuellen Spezifikation XRechnung 3.0.2.
| Code | Regel laut Spezifikation | Typische Ursache | Lösung |
|---|---|---|---|
BR-DE-15 | Das Element „Buyer reference” (BT-10) muss übermittelt werden. | Die Leitweg-ID fehlt oder wurde leer gelassen. | Leitweg-ID beim Auftraggeber erfragen und in BT-10 eintragen, auf Aufbau und Prüfziffer kontrollieren. |
BR-DE-1 | Eine Rechnung muss Angaben zu „Payment instructions” (BG-16) enthalten. | Zahlungsart und Kontodaten wurden nicht mit exportiert. | IBAN oder SEPA-Zahlungsart im Rechnungsentwurf ergänzen, bevor die XRechnung erzeugt wird. |
BR-25 | Jede Rechnungsposition muss den Namen des Postens (BT-153) enthalten. | Eine Position hat keine oder eine leere Artikelbezeichnung. | Jeder Position einen Namen geben, eine kurze Leistungsbeschreibung reicht aus. |
BR-DE-17 | Der Rechnungstyp-Code (BT-3) muss einem zugelassenen Code aus der Liste UNTDID 1001 entsprechen (u. a. 380, 384, 389, 381, 326, 875, 876, 877). | Der Generator oder das ERP setzt einen nicht zulässigen oder keinen Typcode. | Rechnungstyp korrekt wählen, etwa 380 für eine normale Rechnung, 384 für Storno oder Berichtigung und 381 für eine kaufmännische Gutschrift. |
BR-DE-18 | Skonto-Angaben im Feld „Payment terms” (BT-20) müssen dem Format SKONTO#TAGE=n#PROZENT=n# folgen. | Skonto wurde als Freitext statt im vorgeschriebenen Format übermittelt. | Skonto nur über ein Programm eintragen, das dieses Format automatisch erzeugt, nicht frei formulieren. |
BR-DE-21 | Das „Specification identifier” (BT-24) soll syntaktisch der Kennung des Standards XRechnung entsprechen. | Eine veraltete oder falsche CustomizationID, oft Rest einer älteren XRechnung-Version. | Export-Einstellung auf die aktuelle XRechnung-Version 3.0.2 umstellen. |
BR-S-8 / BR-S-9 | Der Steuerbetrag je Kategorie muss dem Nettobetrag multipliziert mit dem Steuersatz entsprechen. | Rundungsdifferenz zwischen Positionssumme und ausgewiesener Steuer, meist durch Float-Rundung in der Quellsoftware. | Steuerberechnung prüfen; Beträge dürfen nur mit exakter Dezimalarithmetik berechnet werden, nicht mit Gleitkomma. |
BR-E-1 | Wird eine Position mit Umsatzsteuerkategorie „Exempt from VAT” berechnet, muss genau eine passende Umsatzsteueraufschlüsselung mit demselben Kategoriecode vorhanden sein. | Die Steuerbefreiung wurde in der Position, aber nicht in der Steueraufschlüsselung der Rechnung hinterlegt. | Kategorie und Befreiungsgrund an beiden Stellen konsistent setzen. |
Diese Liste ist eine Auswahl der am häufigsten gemeldeten Regeln, keine vollständige Wiedergabe. Die Spezifikation XRechnung führt in Abschnitt 12.6 die ergänzenden nationalen Geschäftsregeln bis BR-DE-31, einzelne Nummern dazwischen wurden im Lauf der Versionen gestrichen oder durch eine europäische Regel ersetzt. Für eine Übersicht aller Pflichtfelder, auf die sich diese Regeln beziehen, siehe die XRechnung-BT-Felder-Übersicht. Die Regeln BR-AE-01 bis BR-AE-10 zu Reverse Charge erklärt der Ratgeber Reverse Charge in der XRechnung. Wie die Skontozeile für BR-DE-18 aussehen muss, zeigt die Anleitung Skonto in der XRechnung.
Wann ist eine Meldung inhaltlich, nicht nur technisch?
Nicht jede rote Prüfmeldung hat dieselbe steuerliche Folge. Das Bundesministerium der Finanzen unterscheidet in seinem Schreiben vom 15. Oktober 2025 ausdrücklich zwischen Formatfehlern, Geschäftsregelfehlern ohne Verletzung umsatzsteuerlicher Pflichtangaben und Fehlern an den eigentlichen Pflichtangaben einer Rechnung. Eine fehlende Leitweg-ID etwa ist laut BMF umsatzsteuerlich unbeachtlich, kann eine Rechnung aber trotzdem bei einem Portal oder Auftraggeber zurückweisen lassen. Wie Sie diese drei Kategorien im Einzelfall auseinanderhalten und wann eine Meldung tatsächlich den Vorsteuerabzug betrifft, erklärt der Artikel BMF-Schreiben zur E-Rechnung: Validierung und Fehler richtig einordnen im Detail.
Praxisbeispiel: eine abgelehnte Dienstleistungsrechnung lesen
Eine Freelancerin stellt einer Bundesbehörde eine Beratungsrechnung über 2.400 € aus. Der Prüfbericht meldet zwei Fehler:
BR-DE-15: Buyer reference (BT-10) fehlt. Ursache: Die Leitweg-ID des Amtes wurde beim Anlegen der Rechnung nicht eingetragen.BR-25: Item name (BT-153) fehlt in Position 1. Ursache: Die Position wurde nur mit Menge und Preis angelegt, die Leistungsbeschreibung blieb leer.
Beide Fehler lassen sich beheben, ohne die Rechnung neu zu erstellen: Leitweg-ID beim Amt erfragen und in BT-10 eintragen, Position 1 um eine kurze Beschreibung wie „Beratungsleistung laut Auftrag vom 03.09.2026” ergänzen. Nach der Korrektur zeigt eine erneute Prüfung null Fehler, der Bericht wird grün, und die Empfehlung lautet „anzunehmen und weiter zu verarbeiten”.
So lesen Sie einen Prüfbericht Schritt für Schritt
- Datei hochladen. Laden Sie die XRechnung im E-Rechnungs-Prüfer hoch, kostenlos bis zu drei Prüfungen pro Monat ohne Anmeldung.
- Fehlerzahl prüfen. Ein Bericht mit null Fehlern ist konform, auch wenn Warnungen stehen bleiben. Ein Bericht mit mindestens einem Fehler wird mit der Empfehlung zur Zurückweisung markiert.
- Code nachschlagen. Suchen Sie den gemeldeten Code (
BR-DE-…,BR-…,BR-S-…oder einen XML-Schema-Code wiecvc-…) in der Tabelle oben oder in der Spezifikation XRechnung. - Betroffenes Feld identifizieren. Jede Regel nennt die betroffene BT- oder BG-Nummer. Die BT-Felder-Übersicht zeigt, welches Eingabefeld dahintersteckt.
- Korrigieren und neu erzeugen. Beheben Sie die Ursache in der Quelle, nicht im XML selbst, und exportieren Sie die XRechnung erneut.
- Erneut prüfen. Wiederholen Sie die Validierung, bis der Bericht keine Fehler mehr zeigt.
Kommt Ihre Datei mit der Meldung „Buyer electronic address MUST be provided“ zurück, zeigt XRechnung-Fehler R010: elektronische Adresse des Käufers angeben den passenden Wert und das Schema.
Wer eine XRechnung von Grund auf neu erstellt, findet den vollständigen Ablauf inklusive Leitweg-ID-Beschaffung im Artikel XRechnung erstellen: Schritt-für-Schritt-Anleitung.
XRechnung validieren und Prüfbericht lesen
Laden Sie Ihre XRechnung hoch und sehen Sie Fehler und Warnungen mit Code und betroffenem Feld. Drei Prüfungen pro Monat kostenlos, ohne Anmeldung.
Was Sie jetzt tun
- Hochladen und den Prüfbericht Zeile für Zeile gegen die Tabelle oben abgleichen, statt nur die erste Fehlermeldung zu lesen.
- Formatfehler über einen Generator beheben, nicht durch manuelle XML-Bearbeitung.
- Bei wiederkehrenden Auftraggebern Leitweg-ID, elektronische Adresse und Zahlungsdaten einmal hinterlegen, damit
BR-DE-15undBR-DE-1gar nicht erst auftreten.
Was bedeutet die Spalte „Pos“ oder „val-xsd“ im Prüfbericht?
Muss ich jede Fehlermeldung sofort beheben?
Wo finde ich die vollständige Liste aller BR-DE-Regeln?
Ersetzt eine bestandene Validierung die inhaltliche Prüfung der Rechnung?
Warum lehnt ein Portal meine Rechnung trotz grünem Validierungsergebnis ab?
Quellen
- Spezifikation XRechnung, Version 3.0.2 — Koordinierungsstelle für IT-Standards (KoSIT), veröffentlicht 20.06.2024; abgerufen am 06.10.2026. xeinkauf.de
- Dokumentation E-Rechnungs-Validator — IT Baden-Württemberg (BITBW), zuletzt geändert 15.01.2026; abgerufen am 06.10.2026. erechnungsvalidator.service-bw.de
- Einführung der obligatorischen E-Rechnung: Änderung des Anwendungsschreibens — Bundesministerium der Finanzen, 15.10.2025; abgerufen am 06.10.2026. Originalschreiben
- validator-configuration-xrechnung — Koordinierungsstelle für IT-Standards (KoSIT/itplr-kosit), GitHub-Repository; abgerufen am 06.10.2026. github.com/itplr-kosit
Das passende Werkzeug können Sie ohne Konto öffnen: Rechnung prüfen.