Zuletzt aktualisiert: Mai 2026
XRechnung Prüfbericht & Fehlermeldungen verstehen
Was sagt ein KoSIT-Prüfbericht aus?
Ein KoSIT-Prüfbericht zeigt, ob eine XRechnung den formalen Vorgaben des Standards entspricht. Er enthält das Prüfergebnis (konform oder nicht konform), die Bewertung (annehmen oder zurückweisen), den Dokumententyp (UBL oder CII), die verwendete Validator-Version sowie eine Liste verletzter Regeln mit Codes wie BR-DE-01 oder BR-CO-15. Erst das Lesen dieser Codes macht klar, wo ein BT-Feld fehlt oder falsch befüllt ist.
→ Jetzt XRechnung kostenlos online prüfen
Inhaltsverzeichnis
- XRechnung Prüfbericht & Fehlermeldungen verstehen
- Anatomie eines KoSIT-Prüfberichts
- Die häufigsten BR-DE-Fehler im Überblick
- UBL oder CII – warum die Syntax die Fehlermeldung verändert
- BT-Nummern-Glossar – die wichtigsten Felder
- „Konform, aber zurückzuweisen“ – was steckt dahinter?
- So gehen Sie nach einer Fehlermeldung vor
- XRechnung-Versionen – ein Überblick
- FAQ – XRechnung Prüfbericht
- Validierung jetzt selbst durchführen
Anatomie eines KoSIT-Prüfberichts
Der offizielle KoSIT-Validator gibt einen strukturierten Report im HTML- oder XML-Format aus. Er gliedert sich in fünf Bereiche:
- Dokumentinformationen: Dateiname, Prüfzeitpunkt, erkannter Dokumententyp (UBL Invoice, UBL CreditNote oder UN/CEFACT CII).
- Konformitätsergebnis: „konform“ oder „nicht konform“ gegenüber dem Standard XRechnung in der angewendeten Version.
- Bewertung: Der Bericht empfiehlt entweder Annahme oder Zurückweisung. Eine konforme Rechnung kann trotzdem zurückgewiesen werden, wenn fachliche Regeln (BR-CO-…) verletzt sind.
- Regelverletzungen: Liste mit Code, Schweregrad (error, warning) und betroffenem XPath. Hier finden Sie den Bezug zur BT-Nummer.
- Validator-Version: Welche Konfiguration der KoSIT zum Einsatz kam, etwa xrechnung-3.0.2-2024-09-30.
Die häufigsten BR-DE-Fehler im Überblick
Etwa 80 Prozent aller Zurückweisungen lassen sich auf eine überschaubare Liste von Regeln zurückführen. Die folgende Tabelle erklärt die häufigsten Codes mit Ursache und Lösung.
| Code | Bedeutung | Typische Ursache | Lösung |
|---|---|---|---|
| BR-DE-01 | Pflichtangabe Leitweg-ID fehlt | BT-10 (Buyer reference) nicht befüllt | Leitweg-ID des Empfängers im Feld cbc:BuyerReference eintragen. |
| BR-DE-02 | Kontaktinformation des Verkäufers unvollständig | BG-6 ohne Name, Telefon oder E-Mail | Mindestens BT-41, BT-42 und BT-43 ausfüllen. |
| BR-DE-03 | Stadt des Verkäufers fehlt | BT-37 leer | City in der Verkäuferadresse ergänzen. |
| BR-DE-04 | Postleitzahl des Verkäufers fehlt | BT-38 leer | PLZ in der Verkäuferadresse setzen. |
| BR-DE-05 | Ländercode des Verkäufers fehlt | BT-40 leer oder kein ISO 3166-1 | Zweistelligen ISO-Code (z. B. DE) eintragen. |
| BR-DE-09 | Stadt des Käufers fehlt | BT-52 leer | City in der Käuferadresse ergänzen. |
| BR-DE-15 | Käuferreferenz erforderlich | BT-10 fehlt oder nicht im erwarteten Format | Leitweg-ID oder Bestellnummer eintragen. |
| BR-DE-17 | Ungültiger Code für Rechnungsart | BT-3 nicht 380, 381, 384, 389 oder 875–881 | Korrekten UN/CEFACT-Code wählen. |
| BR-DE-21 | Bezeichnung der Rechnungsposition fehlt | BT-153 leer | Item name pro Position pflegen. |
| BR-DE-23 | Zahlungsbedingungen erforderlich | BT-20 oder BG-16 fehlen | Zahlungsmittel-Code (BT-81) und Fälligkeit setzen. |
| BR-DE-26 | IBAN bei SEPA-Überweisung erforderlich | BT-84 leer trotz Payment Means 58 | IBAN im Format ohne Leerzeichen eintragen. |
| BR-CO-10 | Summe der Positionsbeträge falsch | BT-106 weicht von Summe BT-131 ab | Positionsnettobeträge mathematisch konsistent berechnen. |
| BR-CO-13 | Zwischensumme inkonsistent | BT-109 ≠ BT-106 − BT-107 + BT-108 | Rabatte und Zuschläge auf Dokumentebene korrekt verrechnen. |
| BR-CO-15 | Bruttobetrag stimmt nicht | BT-112 ≠ BT-109 + BT-110 | Steuerbetrag prüfen und Rundungsdifferenzen ausgleichen. |
UBL oder CII – warum die Syntax die Fehlermeldung verändert
XRechnung erlaubt zwei Syntaxen: UBL 2.1 (häufig in Deutschland) und UN/CEFACT Cross Industry Invoice (CII). Der Prüfbericht verweist jeweils per XPath auf das betroffene Element. In UBL heißt das Empfängerland etwa /Invoice/cac:AccountingCustomerParty/cac:Party/cac:PostalAddress/cac:Country/cbc:IdentificationCode, in CII /rsm:CrossIndustryInvoice/ram:ApplicableHeaderTradeAgreement/ram:BuyerTradeParty/ram:PostalTradeAddress/ram:CountryID. Inhaltlich ist das dieselbe BT-Nummer (BT-55), nur der Pfad unterscheidet sich. Wer die BT-Nummer im Glossar nachschlägt, findet den Fehler unabhängig von der Syntax.
BT-Nummern-Glossar – die wichtigsten Felder
| BT-Nummer | Bedeutung |
|---|---|
| BT-1 | Rechnungsnummer (Invoice number) |
| BT-2 | Rechnungsdatum (Invoice issue date) |
| BT-3 | Rechnungstyp-Code (z. B. 380 = Handelsrechnung) |
| BT-5 | Währung der Rechnung |
| BT-9 | Fälligkeitsdatum |
| BT-10 | Käuferreferenz / Leitweg-ID |
| BT-23 | Geschäftsprozesstyp (z. B. urn:fdc:peppol.eu:2017:poacc:billing:01:1.0) |
| BT-24 | Spezifikations-Identifikator (XRechnung CIUS) |
| BT-27 | Name des Verkäufers |
| BT-44 | Name des Käufers |
| BT-48 | Steuernummer des Käufers (USt-IdNr.) |
| BT-81 | Zahlungsart-Code (z. B. 58 = SEPA Credit Transfer) |
| BT-84 | IBAN für SEPA-Überweisung |
| BT-106 | Summe der Positionsbeträge ohne Steuer |
| BT-112 | Bruttobetrag (Gesamtbetrag mit Steuer) |
| BT-115 | Zu zahlender Betrag |
„Konform, aber zurückzuweisen“ – was steckt dahinter?
Eine XRechnung kann technisch konform sein und trotzdem die Empfehlung „Zurückweisen“ auslösen. Der KoSIT-Validator prüft zwei Ebenen: die Konformität gegen das Schema und die fachlichen Geschäftsregeln (BR-CO-…). Verletzt eine Rechnung eine Business Rule, etwa weil Summen nicht zusammenpassen oder eine Pflichtangabe wie die IBAN bei Überweisungszahlungen fehlt, ist sie syntaktisch korrekt, aber fachlich unvollständig. In diesem Fall darf der Empfänger – gerade öffentliche Auftraggeber – die Rechnung formell ablehnen.
So gehen Sie nach einer Fehlermeldung vor
- Fehlercode notieren und im Bericht den XPath oder die BT-Nummer suchen.
- BT-Feld im erzeugenden System identifizieren (ERP, Rechnungsstellung, SAP).
- Korrigierte Datei erneut prüfen – idealerweise mit der gleichen Validator-Version.
- Häufigkeit dokumentieren: Tauchen Codes wie BR-DE-01 systematisch auf, liegt ein Konfigurationsproblem im Vorsystem vor.
XRechnung-Versionen – ein Überblick
Welche Version Ihr Validator anwendet, steht im Prüfbericht. Eine vollständige Versionstabelle mit Gültigkeitszeiträumen finden Sie auf der Übersichtsseite zur XRechnung. Wichtig für die Praxis: Ab dem 1. Januar 2025 gilt Version 3.0.2; Version 4.0 wird voraussichtlich Ende 2026 erwartet.
FAQ – XRechnung Prüfbericht
Wer stellt das Prüfmodul für die XRechnung bereit?
Die Koordinierungsstelle für IT-Standards (KoSIT) entwickelt und veröffentlicht den offiziellen Validator samt Konfigurationsdateien. Quelle: xoev.de.
Was bedeutet „nicht konform“ im Prüfbericht?
Die Datei verletzt mindestens eine Schemaregel oder Business Rule. Die Rechnung darf vom Empfänger zurückgewiesen werden, bis der Fehler behoben ist.
Worin unterscheiden sich UBL und CII bei XRechnung?
UBL und CII sind zwei zulässige Syntaxen mit identischem fachlichen Datenmodell. Die BT-Nummern bleiben gleich, die XML-Elementnamen und XPaths unterscheiden sich.
Reicht ein konformer Prüfbericht für die Versandfreigabe?
Nein. Konformität bedeutet nur Schema-Treue. Für die Praxis kommen Geschäftsregeln (BR-CO-…) und ggf. CIUS-spezifische Regeln wie BR-DE-… hinzu.
Validierung jetzt selbst durchführen
Sie möchten eine XRechnung sofort prüfen? Unser E-Rechnung Validator nutzt das aktuelle KoSIT-Prüfmodul, läuft browserbasiert und liefert den Bericht in wenigen Sekunden – ohne Registrierung. Für die Erzeugung und den Versand von XRechnungen direkt aus SAP empfehlen wir Ihnen unsere Lösung SAP E-Rechnung.
→ Zum kostenlosen E-Rechnung Validator
