billxml / Fehlercodes / XRechnung-Ablehnung (DE)
XRechnung abgelehnt oder ungültig? Jede Fehlermeldung entschlüsselt — und wie Sie sie beheben
Deutschland stellt auf E-Rechnungen um. Das offizielle Bundesportal hält fest: „Ab dem 1. Januar 2025 wird – begleitet von Übergangsvorschriften – auch bei Umsätzen zwischen inländischen Unternehmern verpflichtend eine elektronische Rechnung (E-Rechnung) zu verwenden sein.“ (e-rechnung-bund.de, abgerufen am 11. September 2026). Wer eine XRechnung einreicht und abgelehnt wird, bekommt oft nur eine Regelkennung wie BR-DE-15 oder die Meldung, die Schematron-Validierung sei fehlgeschlagen. Diese Seite entschlüsselt die Fehlerfamilien, zitiert die amtlichen Regeltexte im Wortlaut und sagt pro Schicht, wer was korrigiert. Keine Häufigkeitsstatistiken, keine Sanktionsbeträge: Wir veröffentlichen nur, was sich aus offiziellen Quellen belegen lässt.
Die Ablehnung entschlüsseln: vier Prüfschichten
Eine XRechnung durchläuft mehrere Prüfschichten, bevor sie angenommen wird. Welche Schicht die Ablehnung ausgelöst hat, entscheidet über die Korrektur:
| Schicht | Was geprüft wird | Typische Meldung | Wer korrigiert |
|---|---|---|---|
| XML-Schema (XSD) | Syntax: wohlgeformtes XML, erlaubte Elemente und Datentypen nach UBL oder CII. | „schema-invalid“, „not valid against XSD“, Parserfehler. | Die exportierende Software — meist falsches Template oder unzulässiges Element. |
| EN 16931-Kernregeln | Geschäftsregeln der Europäischen Norm (Kennungen BR-*): Rechnungstyp, Steuersätze und -kategorien, Summen. | BR-CO-15 (Summen stimmen nicht), weitere BR--Kennungen ohne Zusatz. | Die Rechnungsdaten: fehlende Pflichtfelder nachtragen, Werte berichtigen. |
| XRechnung CIUS (BR-DE-n) | Nationale Zusatzregeln des deutschen Formats XRechnung, eine Schicht über der Norm. | BR-DE-15 (Buyer reference fehlt), BR-DE-21 (Specification identifier). | Rechnungsdaten oder Formatauswahl; die Regeltexte stehen unten im Wortlaut. |
| Peppol-Profil | Zusätzliche Regeln, wenn dieselbe Datei über Peppol läuft: PEPPOL-EN16931-*. | PEPPOL-EN16931-R004, PEPPOL-EN16931-R008. | Sendeseite und Access-Point-Konfiguration; unser Peppol-Vertiefungsführer behandelt diese Schicht. |
Zwei Dinge werden oft verwechselt. Erstens: Eine Datei kann gegen das XML-Schema validieren und trotzdem an den Geschäftsregeln scheitern — die Schematron-Prüfung läuft nach der Schema-Prüfung. Zweitens: Besteht eine Datei die BR-DE-Prüfung, sagt das nichts über die Peppol-Schicht aus, wenn sie über das Peppol-Netzwerk läuft. Die Schicht zu kennen, spart die falschen Korrekturen.
Ehrliche Anmerkung: Die verlinkten Detailseiten zu den Regeln sind derzeit französisch betitelt (unser Fehler-Atlas ist französisch aufgebaut); deutschsprachige Fassungen stehen auf der Roadmap. Wir verlinken sie trotzdem — Regelkennung, amtlicher Regeltext und XML-Pfad sind sprachunabhängig nutzbar. Wir tun nicht so, als wären die Seiten deutsch.
Die 25 BR-DE-Regeln im Wortlaut
Das Regelwerk XRechnung 3.0.2 — dasselbe Schematron, gegen das auch der kostenlose Validator auf billxml.com prüft — definiert 25 nummerierte Nationalregeln: BR-DE-1 bis BR-DE-31, mit Lücken (die Nummern 12, 13, 23, 24, 25 und 29 sind nicht vergeben). 18 Regeln sind als fatal markiert, 7 als Warnung; ob eine Warnung zur Ablehnung führt, entscheidet die empfangende Prüfung. Jeder Text unten ist der amtliche Schematron-Text, unverändert.
- BR-DE-1 · fatal —
[BR-DE-1] Eine Rechnung (INVOICE) muss Angaben zu "PAYMENT INSTRUCTIONS" (BG-16) enthalten. - BR-DE-2 · fatal —
[BR-DE-2] Die Gruppe "SELLER CONTACT" (BG-6) muss übermittelt werden. - BR-DE-3 · fatal —
[BR-DE-3] Das Element "Seller city" (BT-37) muss übermittelt werden. - BR-DE-4 · fatal —
[BR-DE-4] Das Element "Seller post code" (BT-38) muss übermittelt werden. - BR-DE-5 · fatal —
[BR-DE-5] Das Element "Seller contact point" (BT-41) muss übermittelt werden. - BR-DE-6 · fatal —
[BR-DE-6] Das Element "Seller contact telephone number" (BT-42) muss übermittelt werden. - BR-DE-7 · fatal —
[BR-DE-7] Das Element "Seller contact email address" (BT-43) muss übermittelt werden. - BR-DE-8 · fatal —
[BR-DE-8] Das Element "Buyer city" (BT-52) muss übermittelt werden. - BR-DE-9 · fatal —
[BR-DE-9] Das Element "Buyer post code" (BT-53) muss übermittelt werden. - BR-DE-10 · fatal —
[BR-DE-10] Das Element "Deliver to city" (BT-77) muss übermittelt werden, wenn die Gruppe "DELIVER TO ADDRESS" (BG-15) übermittelt wird. - BR-DE-11 · fatal —
[BR-DE-11] Das Element "Deliver to post code" (BT-78) muss übermittelt werden, wenn die Gruppe "DELIVER TO ADDRESS" (BG-15) übermittelt wird. - BR-DE-14 · fatal —
[BR-DE-14] Das Element "VAT category rate" (BT-119) muss übermittelt werden. - BR-DE-15 · fatal —
[BR-DE-15] Das Element "Buyer reference" (BT-10) muss übermittelt werden. - BR-DE-16 · fatal —
[BR-DE-16] Wenn in einer Rechnung die Steuercodes S, Z, E, AE, K, G, L oder M verwendet werden, muss mindestens eines der Elemente "Seller VAT identifier" (BT-31), "Seller tax registration identifier" (BT-32) oder "SELLER TAX REPRESENTATIVE PARTY" (BG-11) übermittelt werden. - BR-DE-17 · Warnung —
[BR-DE-17] Mit dem Element "Invoice type code" (BT-3) sollen ausschließlich folgende Codes aus der Codeliste UNTDID 1001 übermittelt werden: 326 (Partial invoice), 380 (Commercial invoice), 384 (Corrected invoice), 389 (Self-billed invoice) und 381 (Credit note),875 (Partial construction invoice), 876 (Partial final construction invoice), 877 (Final construction invoice). - BR-DE-18 · fatal —
[BR-DE-18] Skonto Zeilen in <name/> müssen diesem regulärem Ausdruck entsprechen: <value-of select="$XR-SKONTO-REGEX"/>. Die Informationen zur Gewährung von Skonto müssen wie folgt im Element "Payment terms" (BT-20) übermittelt werden: Anzugeben ist im ersten Segment "SKONTO", im zweiten "TAGE=n", im dritten "PROZENT=n". Prozentzahlen sind ohne Vorzeichen sowie mit Punkt getrennt von zwei Nachkommastellen anzugeben. Liegt dem zu berechnenden Betrag nicht BT-115, "fälliger Betrag" zugrunde, sondern nur ein Teil des fälligen Betrags der Rechnung, ist der Grundwert zur Berechnung von Skonto als viertes Segment "BASISBETRAG=n" gemäß dem semantischen Datentypen Amount anzugeben. Jeder Eintrag beginnt mit einer #, die Segmente sind mit einer # getrennt und eine Zeile schließt mit einer # ab. Am Ende einer vollständigen Skontoangabe muss ein XML-konformer Zeilenumbruch folgen. Alle Angaben zur Gewährung von Skonto müssen in Großbuchstaben gemacht werden. Zusätzliches Whitespace (Leerzeichen, Tabulatoren oder Zeilenumbrüche) ist nicht zulässig. Andere Zeichen oder Texte als in den oberen Vorgaben genannt sind nicht zulässig. - BR-DE-19 · Warnung —
[BR-DE-19] "Payment account identifier" (BT-84) soll eine korrekte IBAN enthalten, wenn in "Payment means type code" (BT-81) mit dem Code 58 SEPA als Zahlungsmittel gefordert wird. - BR-DE-20 · Warnung —
[BR-DE-20] "Debited account identifier" (BT-91) soll eine korrekte IBAN enthalten, wenn in "Payment means type code" (BT-81) mit dem Code 59 SEPA als Zahlungsmittel gefordert wird. - BR-DE-21 · Warnung —
[BR-DE-21] Das Element "Specification identifier" (BT-24) soll syntaktisch der Kennung des Standards XRechnung entsprechen. - BR-DE-22 · fatal —
[BR-DE-22] Das "filename"-Attribut aller "EmbeddedDocumentBinaryObject"-Elemente muss eindeutig sein - BR-DE-26 · Warnung —
[BR-DE-26] Wenn im Element "Invoice type code" (BT-3) der Code 384 (Corrected invoice) übergeben wird, soll PRECEDING INVOICE REFERENCE BG-3 mind. einmal vorhanden sein. - BR-DE-27 · Warnung —
[BR-DE-27] In BT-42 sollen mindestens drei Ziffern enthalten sein. - BR-DE-28 · Warnung —
[BR-DE-28] In BT-43 soll genau ein @-Zeichen enthalten sein, welches nicht von einem Leerzeichen, einem Punkt, aber mindestens zwei Zeichen auf beiden Seiten flankiert werden soll. Ein Punkt sollte nicht am Anfang oder am Ende stehen. - BR-DE-30 · fatal —
[BR-DE-30] Wenn "DIRECT DEBIT" BG-19 vorhanden ist, dann muss "Bank assigned creditor identifier" BT-90 übermittelt werden. - BR-DE-31 · fatal —
[BR-DE-31] Wenn "DIRECT DEBIT" BG-19 vorhanden ist, dann muss "Debited account identifier" BT-91 übermittelt werden.
Daneben definiert das Regelwerk Regeln mit eigenen Kennungen: BR-DE-CVD-01, BR-DE-CVD-02, BR-DE-CVD-03, BR-DE-CVD-04, BR-DE-CVD-05 (Zusatzangaben für bestimmte Beschaffungen, unter anderem Vertrags- und Losreferenzen und Fahrzeugkategorien) sowie BR-DE-TMP-32 (Angabe des Liefer-/Leistungsdatums). Auch diese Regeln haben eigene Atlas-Seiten.
Die vollständige Übersicht aller Regelsätze (EN 16931, Peppol BIS 3.0, XRechnung 3.0.2, Peppol CEN) steht im Fehler-Atlas; Familienübersichten: Identifikatoren und Codes, Summen, Daten, Adressen.
Motiv: Leitweg-ID fehlt oder ist falsch (BR-DE-15 / BT-10)
Ursache. Die XRechnung-Nationalregel BR-DE-15 verlangt im Wortlaut: „[BR-DE-15] Das Element "Buyer reference" (BT-10) muss übermittelt werden.“ — markiert als fatal. Bei Rechnungen an die öffentliche Hand trägt das Feld BT-10 die Leitweg-ID des Empfängers. Das offizielle Bundesportal führt die Leitweg-Identifikationsnummer ausdrücklich unter den Pflichtangaben nach § 5 E-Rechnungsverordnung des Bundes auf und hält fest: „Die Leitweg-ID wird Ihnen bei der Auftragserteilung mitgeteilt.“ Die zentrale Eingangsplattform OZG-RE prüft eingereichte Rechnungen nach Darstellung des Portals unter anderem auf „Leitweg-ID, Pflichtfelder ausgefüllt, Empfänger bekannt“. Fehlt die Leitweg-ID oder gehört sie zu einem anderen Empfänger, wird die Rechnung nicht weitergeleitet.
Lösung. Erfragen Sie die Leitweg-ID beim Auftraggeber — sie wird bei Auftragserteilung mitgeteilt — und tragen Sie sie unverändert in das Feld „Buyer reference“ (BT-10) ein (in UBL-Dateien das Element cbc:BuyerReference). Prüfen Sie im selben Zug die übrigen Empfängerangaben: Leitweg-ID und Empfänger gehören zusammen. Dann erneut einreichen.
Schicht: CIUS-Regel (fatal) plus Prüfung der Eingangsplattform. Korrektur durch: den Rechnungssteller.
Quellen: XRechnung 3.0.2 Schematron (BR-DE-15, unverändert); e-rechnung-bund.de — FAQ „Welche inhaltlichen Anforderungen müssen zur Erstellung einer E-Rechnung beachtet werden?“ und Prozessdarstellung der OZG-RE, abgerufen am 11. September 2026.
Motiv: XRechnung, ZUGFeRD oder Factur-X — falsches Format angekündigt
Ursache. XRechnung, ZUGFeRD und Factur-X sind eine Familie: Alle bauen auf der Norm EN 16931 auf — ZUGFeRD und Factur-X (die französische Ausprägung) als CII-Syntax, XRechnung wahlweise als UBL oder CII. Die Regelschichten unterscheiden sich trotzdem. Welche Regeln eine Datei durchläuft, entscheidet die angekündigte Spezifikation im Element „Specification identifier“ (BT-24): Regel BR-DE-21 verlangt im Wortlaut, dass BT-24 „syntaktisch der Kennung des Standards XRechnung entsprechen“ soll. Kündigt die Datei XRechnung an, laufen die BR-DE-Regeln; kündigt sie ZUGFeRD oder Factur-X an, laufen sie nicht. Die Eingangsplattform des Bundes prüft nach eigener Darstellung Rechnungen auf „Konformität zur Spezifikation XRechnung oder anderer in der EU zugelassener Standards in Syntax und Semantik wie z.B. ZUGFeRD 2.2.0“.
Lösung. Sorgen Sie dafür, dass Erzeugung und Ankündigung zusammenpassen: Wer XRechnung vereinbart hat, exportiert XRechnung (UBL oder CII) mit passender BT-24-Kennung; wer ZUGFeRD oder Factur-X vereinbart hat, sendet dieses Format. Syntaxregeln der gemeinsamen CII-Familie (z. B. CII-SR-465) und die Familie Identifikatoren und Codes stehen ebenfalls im Atlas.
Schicht: Formatwahl und CIUS-Ankündigung (BT-24). Korrektur durch: die exportierende Software.
Quellen: XRechnung 3.0.2 Schematron (BR-DE-21, unverändert); e-rechnung-bund.de — Startseite (Prüfverhalten der OZG-RE), abgerufen am 11. September 2026.
Prüfen Sie, bevor Sie erneut einreichen
Vor dem erneuten Einreichen die Datei in den kostenlosen Validator auf billxml.com laden: Die XRechnung-3.0.2-Regeln (UBL und CII) laufen dort unverändert, das Ergebnis kommt je Regel — inklusive EN 16931 und Peppol BIS. Ohne Konto; Dateien werden im Speicher geprüft und danach verworfen.
Rechnungsdatei kostenlos prüfen (kein Konto)Was ein Datei-Validator nicht leisten kann
Ein Validator prüft die Datei gegen die Regeln — nicht, ob die Leitweg-ID zum richtigen Empfänger gehört, nicht die Registrierung im Peppol-Netzwerk, nicht die Freischaltung eines Übertragungswegs bei der Eingangsplattform. Eine regelkonforme Datei kann also trotzdem abgelehnt werden, weil Empfänger oder Weg nicht stimmen; die Motive oben sagen pro Familie, wer korrigiert. Auf jeder Atlas-Seite zeigen wir den amtlichen Regeltext im Wortlaut und sagen genau, was der Validator prüft. Keine Häufigkeitsstatistiken, keine Marktanteile, keine Sanktionsbeträge: Diese Zahlen veröffentlichen wir nicht, weil wir sie nicht belegen können.
billxml ist keine Übermittlungsstelle und kein ÖPP: Formatvalidierung und Konvertierung machen wir selbst, die Zustellung läuft über Ihren eigenen Weg. Die Rechtsangaben zu Deutschland auf dieser Seite zitieren und datieren die offiziellen Seiten des Bundes (e-rechnung-bund.de); billxml ist mit dem Portal nicht verbunden.
In English — XRechnung rejected, briefly
Rejection has four layers. The XML schema comes first. Then the EN 16931 core rules (BR-*), then the German national rules of the XRechnung CIUS (BR-DE-*, all 25 quoted verbatim above), and finally the Peppol profile if the file travels over Peppol. A schema-valid file can still fail Schematron; which layer rejected you decides the fix. The classic German pitfall is BT-10. Rule BR-DE-15 (fatal) requires the Buyer reference; for public recipients it carries the Leitweg-ID, and per the official federal portal that ID is communicated with the order. XRechnung, ZUGFeRD and Factur-X share the EN 16931 core. But BR-DE rules only run when BT-24 announces XRechnung. The full guide above is in German. The free rule-level validator takes any invoice file, no account needed.
Häufige Fragen
Meine Datei ist schema-valide und wird trotzdem abgelehnt — woran liegt das?
Die Schema-Prüfung (XSD) und die Regelprüfung (Schematron) sind zwei Schichten: Eine Datei kann wohlgeformtes, schema-gültiges XML sein und trotzdem gegen Geschäftsregeln verstoßen. Die EN-16931-Kernregeln (BR-*) und die XRechnung-Nationalregeln (BR-DE-*) laufen erst nach der Schema-Prüfung. Die Ablehnungsmeldung nennt meist eine Regelkennung — oben im Wortlaut-Verzeichnis steht, was jede Kennung verlangt.
Wer muss in Deutschland E-Rechnungen empfangen können?
Das offizielle Bundesportal hält fest: „Ab dem 1. Januar 2025 wird – begleitet von Übergangsvorschriften – auch bei Umsätzen zwischen inländischen Unternehmern verpflichtend eine elektronische Rechnung (E-Rechnung) zu verwenden sein.“ Eine E-Rechnung liegt danach nur dann vor, wenn sie in einem strukturierten elektronischen Format ausgestellt, übermittelt und empfangen wird und eine elektronische Verarbeitung ermöglicht. Quelle: e-rechnung-bund.de, Seite „E-Rechnung zwischen Unternehmen (B2B)“, abgerufen am 11. September 2026.
Was ist der Unterschied zwischen BR-DE-*- und BR-*-Codes?
Sie stammen aus verschiedenen Schichten: BR-* sind die Geschäftsregeln der Europäischen Norm EN 16931 und gelten für alle darauf aufbauenden Formate; BR-DE-* sind die nationalen Zusatzregeln des deutschen Formats XRechnung. Eine Regel aus einer der Schichten kann die Annahme verhindern. Von jeder Regel zeigt unsere Fehlercode-Übersicht den amtlichen Text im Wortlaut.
Wo finde ich die Leitweg-ID für eine Rechnung an eine Bundesbehörde?
Die Leitweg-ID wird Ihnen nach Auskunft des offiziellen Bundesportals bei der Auftragserteilung mitgeteilt; das Portal führt sie unter den Pflichtangaben nach § 5 E-Rechnungsverordnung des Bundes. In der XRechnung gehört sie in das Feld „Buyer reference“ (BT-10) — Regel BR-DE-15 verlangt dieses Element und ist als fatal markiert. (Quelle: e-rechnung-bund.de, FAQ, abgerufen am 11. September 2026.)
Warum sind die Regel-Detailseiten auf Französisch?
Weil unser Fehler-Atlas bisher französisch aufgebaut ist — das sagen wir offen, statt so zu tun, als wären die Seiten deutsch. Deutschsprachige Fassungen stehen auf der Roadmap. Die Regelkennungen, amtlichen Regeltexte und XML-Pfade auf den Detailseiten sind sprachunabhängig nutzbar; genau deshalb verlinken wir sie.
Quellen auf dieser Seite: XRechnung 3.0.2 Schematron (UBL und CII, Regeltexte unverändert); e-rechnung-bund.de — „E-Rechnung zwischen Unternehmen (B2B)“, FAQ zu inhaltlichen Anforderungen (§ 5 E-Rechnungsverordnung) und Prozessdarstellung der OZG-RE, abgerufen am 11. September 2026. billxml veröffentlicht keine Ablehnungsstatistiken: Diese Daten haben wir nicht.