Häufige XRechnung-Fehler (BR-DE-*) und wie Sie sie beheben

Von evoicely · Zuletzt geprüft am 20. Oktober 2026

Fehler mit der Kennung BR-DE-* stammen aus den deutschen XRechnung-Regeln, die über die EN 16931 hinaus zusätzliche Pflichtangaben verlangen. Fast immer bedeuten sie: Ein Feld fehlt. Bei Rechnungen aus Stripe sind es meistens BR-DE-15 (keine Käuferreferenz), BR-DE-2 und BR-DE-5 bis 7 (kein Verkäuferkontakt mit Name, Telefon und E-Mail), BR-DE-1 (keine Zahlungsangaben), BR-DE-16 (weder USt-IdNr. noch Steuernummer des Verkäufers) und BR-DE-8/9 (Kunde ohne Ort oder Postleitzahl). Zu jeder Regel finden Sie unten den offiziellen Regeltext, die Ursache und das XML, das die Regel erfüllt. Welche Regeln Ihre eigene Datei verletzt, zeigt Ihnen unser kostenloser Validator.

Übersicht

Die Regeltexte stammen aus dem XRechnung-3.0.2-Schematron und den EN-16931-Regeln 1.3.16, wie sie in der Validator-Konfiguration der KoSIT vom 31. August 2026 enthalten sind (XRechnung-Schematron, Validierungsartefakte zur EN 16931). Die BR-DE-Texte sind im Original deutsch und hier wörtlich zitiert; die Regeln der EN 16931 und von Peppol sind im Original englisch, die Übersetzungen sind von uns. Die XML-Ausschnitte sind UBL und stammen aus einer vollständigen, fiktiven Rechnung, die diese Regeln besteht.

BR-DE-15: Käuferreferenz fehlt

[BR-DE-15] Das Element „Buyer reference“ (BT-10) muss übermittelt werden.

XRechnung verlangt BT-10 auf jeder Rechnung, nicht nur bei Behörden. Bei einem öffentlichen Auftraggeber ist es die Leitweg-ID; bei einem Unternehmen die Referenz, die Sie mit ihm vereinbart haben, etwa eine Bestell- oder Kundennummer. Stripe hat kein Feld für eine Käuferreferenz, ein Konverter muss sie also aus den Metadaten nehmen. Ein leeres Element zählt nicht und löst zusätzlich PEPPOL-EN16931-R008 aus.

<cbc:BuyerReference>PO-4711</cbc:BuyerReference>

In CII steht sie in ram:BuyerReference innerhalb von ram:ApplicableHeaderTradeAgreement.

BR-DE-2, BR-DE-5, BR-DE-6, BR-DE-7: Kontakt des Verkäufers

• BR-DE-2: Die Gruppe „SELLER CONTACT“ (BG-6) muss übermittelt werden.
• BR-DE-5: Das Element „Seller contact point“ (BT-41) muss übermittelt werden.
• BR-DE-6: Das Element „Seller contact telephone number“ (BT-42) muss übermittelt werden.
• BR-DE-7: Das Element „Seller contact email address“ (BT-43) muss übermittelt werden.

In der EN 16931 ist der Verkäuferkontakt optional, XRechnung macht alle drei Angaben zur Pflicht. Eine Stripe-Rechnung enthält zwar Ihren Firmennamen, aber keinen strukturierten Ansprechpartner mit Telefon und E-Mail, diese Angaben müssen also aus Ihren eigenen Einstellungen kommen. Als Kontakt genügt eine Abteilung wie „Buchhaltung“; ein Personenname ist nicht nötig.

<cac:AccountingSupplierParty>
  <cac:Party>
    ...
    <cac:Contact>
      <cbc:Name>Buchhaltung</cbc:Name>
      <cbc:Telephone>+49 30 1234567</cbc:Telephone>
      <cbc:ElectronicMail>billing@beispiel-software.example</cbc:ElectronicMail>
    </cac:Contact>
  </cac:Party>
</cac:AccountingSupplierParty>

In UBL steht cac:Contact innerhalb von cac:Party nach cac:PartyLegalEntity. An der falschen Stelle lehnt schon das XML-Schema die Datei ab.

BR-DE-1: Zahlungsangaben fehlen

[BR-DE-1] Eine Rechnung (INVOICE) muss Angaben zu „PAYMENT INSTRUCTIONS“ (BG-16) enthalten.

In UBL ist das ein Element cac:PaymentMeans mit einem Code für die Zahlungsart (BT-81, aus der Codeliste UNTDID 4461). Es ist auch dann Pflicht, wenn die Rechnung schon bezahlt ist, was bei einem Stripe-Abo mit Kartenzahlung der Normalfall ist. Soll der Kunde noch überweisen, verwenden Sie Code 58 (SEPA-Überweisung) mit Ihrer IBAN:

<cac:PaymentMeans>
  <cbc:PaymentMeansCode>58</cbc:PaymentMeansCode>
  <cac:PayeeFinancialAccount>
    <cbc:ID>DE02120300000000202051</cbc:ID>
  </cac:PayeeFinancialAccount>
</cac:PaymentMeans>

Für eine bereits bezahlte Rechnung finden Sie die Kartencodes im nächsten Abschnitt. Alternativ nehmen Sie Code 1 (Zahlungsart nicht festgelegt), der keine weiteren Angaben braucht, und weisen die Zahlung als bereits gezahlten Betrag aus (BT-113, cbc:PrepaidAmount), sodass der fällige Betrag 0 ist.

BR-DE-23-a und BR-DE-24-a: Code und Angaben passen nicht zusammen

• BR-DE-23-a: Wenn BT-81 „Payment means type code“ einen Schlüssel für Überweisungen enthält (30, 58), muss BG-17 „CREDIT TRANSFER“ übermittelt werden. Fehlt die IBAN, schlägt außerdem BR-61 der EN 16931 an.
• BR-DE-24-a: Wenn BT-81 „Payment means type code“ einen Schlüssel für Kartenzahlungen enthält (48, 54, 55), muss genau BG-18 „PAYMENT CARD INFORMATION“ übermittelt werden.

Die -b-Varianten beider Regeln verbieten das Mischen: Bei einem Überweisungscode dürfen keine Karten- oder Lastschriftangaben vorkommen, bei einem Kartencode weder Bankkonto noch Lastschrift. Eine Kartenzahlung sieht so aus:

<cac:PaymentMeans>
  <cbc:PaymentMeansCode>48</cbc:PaymentMeansCode>
  <cac:CardAccount>
    <cbc:PrimaryAccountNumberID>4242</cbc:PrimaryAccountNumberID>
    <cbc:NetworkID>VISA</cbc:NetworkID>
  </cac:CardAccount>
</cac:PaymentMeans>

Schreiben Sie nie die vollständige Kartennummer in eine Rechnung. Nach BR-51 der EN 16931 dürfen gemäß den Sicherheitsstandards für Kartenzahlungen höchstens die ersten 6 und die letzten 4 Ziffern erscheinen; die letzten vier genügen.

BR-DE-16, BR-S-02 und BR-CO-26: USt-IdNr. oder Steuernummer des Verkäufers

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.

Fehlt einfach die USt-IdNr. des Verkäufers, sehen Sie meist drei Fehler auf einmal: BR-DE-16, BR-S-02 der EN 16931 (dieselbe Anforderung für Positionen zum Regelsteuersatz) und BR-CO-26 (der Verkäufer muss über eine Verkäuferkennung, eine Registernummer oder eine USt-IdNr. identifizierbar sein).

Auf einer Stripe-Rechnung steht Ihre USt-IdNr. in account_tax_ids, sofern Sie sie in Stripe hinterlegt haben. Mit USt-IdNr.:

<cac:PartyTaxScheme>
  <cbc:CompanyID>DE123456789</cbc:CompanyID>
  <cac:TaxScheme>
    <cbc:ID>VAT</cbc:ID>
  </cac:TaxScheme>
</cac:PartyTaxScheme>

Haben Sie nur eine Steuernummer, gehört sie in BT-32: ein cac:PartyTaxScheme mit dem Steuerschema FC statt VAT. Damit sind BR-DE-16 und BR-S-02 erfüllt, BR-CO-26 aber nicht, denn BT-32 gehört nicht zu den Kennungen, die BR-CO-26 akzeptiert. Ergänzen Sie dann eine Registernummer (BT-30, etwa Ihre Handelsregisternummer, in cac:PartyLegalEntity/cbc:CompanyID) oder eine Verkäuferkennung (BT-29).

Eine USt-IdNr. muss mit dem Ländercode beginnen, also DE123456789 statt 123456789; sonst schlägt BR-CO-09 an.

BR-DE-8 und BR-DE-9: Ort und Postleitzahl des Käufers

BR-DE-8: Das Element „Buyer city“ (BT-52) muss übermittelt werden. BR-DE-9: Das Element „Buyer post code“ (BT-53) muss übermittelt werden. Die Gegenstücke für den Verkäufer sind BR-DE-3 und BR-DE-4. Fehlt die Anschrift des Käufers ganz, schlägt stattdessen BR-10 der EN 16931 an, fehlt der Ländercode, BR-11.

Stripe verlangt für einen Kunden keine Anschrift: customer_address auf der Rechnung kann leer (null) sein (Invoice-Objekt). Erfassen Sie die Rechnungsanschrift im Checkout oder tragen Sie sie beim Kunden ein, bevor die Rechnung finalisiert wird; danach aktualisiert Stripe die Kopie auf der Rechnung nicht mehr.

<cac:PostalAddress>
  <cbc:StreetName>Hauptstraße 5</cbc:StreetName>
  <cbc:CityName>München</cbc:CityName>
  <cbc:PostalZone>80331</cbc:PostalZone>
  <cac:Country>
    <cbc:IdentificationCode>DE</cbc:IdentificationCode>
  </cac:Country>
</cac:PostalAddress>

PEPPOL-EN16931-R020 und R010: elektronische Adressen

Seller electronic address MUST be provided (R020: Die elektronische Adresse des Verkäufers muss angegeben werden) und Buyer electronic address MUST be provided (R010: dasselbe für den Käufer). Die Regeln tragen Peppol-Kennungen, gehören aber zum Regelwerk von XRechnung 3.0. Die elektronische Adresse (BT-34 für den Verkäufer, BT-49 für den Käufer) gibt an, wohin die Rechnung zugestellt werden kann. Außerhalb von Peppol funktioniert eine E-Mail-Adresse mit dem Schema EM:

<cbc:EndpointID schemeID="EM">billing@beispiel-software.example</cbc:EndpointID>

Sie steht in cac:Party vor der Postanschrift. Ohne das Attribut schemeID erhalten Sie BR-62 (Verkäufer) bzw. BR-63 (Käufer), mit einem Schema, das nicht in der EAS-Codeliste steht, BR-CL-25. Für den Käufer bietet sich die E-Mail-Adresse des Kunden auf der Stripe-Rechnung an (customer_email), sofern er Ihnen keine Peppol-ID oder eigene Rechnungsadresse genannt hat.

PEPPOL-EN16931-R008: leere Elemente

Document MUST not contain empty elements. Das Dokument darf keine leeren Elemente enthalten. Ein Generator, der jedes Feld schreibt, auch wenn der Wert in Stripe leer ist, erzeugt etwa <cbc:Note></cbc:Note>. Die Lösung liegt im Generator: Elemente ohne Wert weglassen. Die Fundstelle in der Fehlermeldung zeigt, welches Element leer war.

BR-CO-14, BR-CO-15, BR-CO-16: Summen gehen nicht auf

• BR-CO-14: Gesamtbetrag der Umsatzsteuer (BT-110) = Σ Steuerbetrag je Umsatzsteuerkategorie (BT-117).
• BR-CO-15: Gesamtbetrag einschließlich Umsatzsteuer (BT-112) = Gesamtbetrag ohne Umsatzsteuer (BT-109) + Gesamtbetrag der Umsatzsteuer (BT-110).
• BR-CO-16: Fälliger Betrag (BT-115) = Gesamtbetrag einschließlich Umsatzsteuer (BT-112) − gezahlter Betrag (BT-113) + Rundungsbetrag (BT-114).

Diese Prüfungen sind centgenau. Meist schlagen sie an, wenn die Summen von einer Stelle stammen (Stripes total) und die Steueraufschlüsselung anderswo neu berechnet wird. Stripe rundet die Steuer je Position, daher kann die Steuer je Steuersatz um einen Cent von „Bemessungsgrundlage × Steuersatz“ abweichen. Die Prüfung je Kategorie (BR-CO-17, BR-S-09) toleriert das: Nach den aktuellen Regeln muss die Abweichung kleiner als eine Währungseinheit sein. Verwenden Sie also Stripes eigene Steuerbeträge je Steuersatz und leiten Sie BT-110, BT-112 und BT-115 daraus ab, statt Stripes Summen mit Ihrer eigenen Steuerberechnung zu mischen. Beträge dürfen höchstens zwei Nachkommastellen haben: 29.970 verletzt BR-DEC-23.

BR-AE-10 und BR-AE-02: Reverse Charge

Verkaufen Sie an ein Unternehmen in einem anderen EU-Land und schuldet der Leistungsempfänger die Steuer (Reverse Charge), ist die Umsatzsteuerkategorie AE mit dem Satz 0. Zwei Regeln fangen die meisten Fehler ab:

• BR-AE-10: Die Steueraufschlüsselung für Reverse Charge muss einen Befreiungsgrund als Code (BT-121) mit der Bedeutung „Reverse charge“ oder den Befreiungsgrund als Text (BT-120) „Reverse charge“ enthalten (oder den entsprechenden Standardtext in einer anderen Sprache).
• BR-AE-02: Eine Rechnung mit Reverse-Charge-Positionen muss die USt-IdNr. des Verkäufers (oder seine Steuernummer bzw. die USt-IdNr. seines Steuervertreters) sowie die USt-IdNr. des Käufers (BT-48) oder dessen Registernummer (BT-47) enthalten.

In Stripe ist das ein Kunde mit tax_exempt auf reverse und einer USt-IdNr. in customer_tax_ids. Die Aufschlüsselung sieht dann so aus:

<cac:TaxCategory>
  <cbc:ID>AE</cbc:ID>
  <cbc:Percent>0</cbc:Percent>
  <cbc:TaxExemptionReasonCode>VATEX-EU-AE</cbc:TaxExemptionReasonCode>
  <cbc:TaxExemptionReason>Reverse charge</cbc:TaxExemptionReason>
  <cac:TaxScheme>
    <cbc:ID>VAT</cbc:ID>
  </cac:TaxScheme>
</cac:TaxCategory>

Ob ein Umsatz unter Reverse Charge fällt, ist eine steuerliche Frage, keine der Validierung. Die Regeln prüfen nur, ob die Rechnung in sich stimmig ist, wenn Sie das entschieden haben.

BR-DE-21 und „kein Szenario“: die Spezifikationskennung

BR-DE-21 (Warnung): Das Element „Specification identifier“ (BT-24) soll syntaktisch der Kennung des Standards XRechnung entsprechen. Für XRechnung 3.0 lautet sie:

<cbc:CustomizationID>urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0</cbc:CustomizationID>

In der Praxis sehen Sie BR-DE-21 selbst selten. Der KoSIT-Validator wendet die XRechnung-Regeln nur an, wenn BT-24 einer der ihm bekannten Kennungen entspricht. Eine Datei mit falscher oder veralteter Kennung, etwa xrechnung_2.3, wird deshalb mit dem Hinweis abgelehnt, dass kein Szenario gegriffen hat, ganz ohne Regelmeldungen. Wird eine Datei ohne Fehlerliste abgelehnt, prüfen Sie zuerst BT-24. Wie die Szenarien funktionieren, erklärt unser Leitfaden XRechnung validieren.

Warnungen und Hinweise, die eine Datei nicht ungültig machen

• BR-DE-19 (Warnung): „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. Sie schlägt bei einer falschen Prüfziffer an, meist ein Tippfehler, mit dem das Geld nicht ankommt. Beheben Sie ihn, obwohl es nur eine Warnung ist.
• BR-DE-27 (Warnung): In BT-42 sollen mindestens drei Ziffern enthalten sein. Platzhalter wie „-“ als Telefonnummer lösen sie aus.
• BR-DE-28 (Warnung): Die E-Mail-Adresse des Verkäufers (BT-43) soll genau ein @ enthalten, mit mindestens zwei Zeichen auf jeder Seite.
• BR-DE-TMP-32 (Hinweis): Eine Rechnung sollte zur Angabe des Liefer-/Leistungsdatums entweder BT-72 „Actual delivery date“, BG-14 „Invoicing period“ oder in jeder Rechnungsposition BG-26 „Invoice line period“ enthalten. Abo-Positionen in Stripe haben einen Leistungszeitraum, den Sie dafür verwenden können.
• BR-DE-17 (Warnung): Der Rechnungstyp (BT-3) soll einer der Codes 326, 380, 384, 389, 381, 875, 876 oder 877 sein. Eine normale Rechnung ist 380, eine Rechnungskorrektur (Credit note) 381; die 389 steht für eine Gutschrift im Sinne der Selbstfakturierung.

Die Korrektur prüfen

Beheben Sie eine Fehlergruppe nach der anderen und prüfen Sie dazwischen erneut: Ein fehlendes übergeordnetes Element kann Fehler in seinen Unterelementen verdecken. Unser Validator zeigt jeden Befund mit seiner Fundstelle im Dokument und stellt die Rechnung lesbar dar, sodass Sie das gerade ergänzte Feld sehen.

Weitere Leitfäden

• XRechnung validieren: der KoSIT-Validator, seine Szenarien und sein Prüfbericht.
• Mapping a Stripe invoice to EN 16931 (auf Englisch): woher jedes dieser Felder in Stripe kommt.
• Was ist eine Leitweg-ID?: die Käuferreferenz für öffentliche Auftraggeber.
• XRechnung öffnen und lesen: wenn Sie sehen wollen, was in einer Datei steht.
• E-Rechnungspflicht in Deutschland für Stripe-Nutzer: wer ab wann E-Rechnungen ausstellen muss.

Was evoicely dabei übernimmt

Prüfen Sie Ihre XRechnung auf diese Fehler, kostenlos und ohne Anmeldung. evoicely füllt diese Felder, wenn es aus Ihren Stripe-Rechnungen XRechnung und ZUGFeRD macht: Verkäuferkontakt, USt-IdNr. und IBAN aus Einstellungen, die Sie einmal festlegen, die Käuferreferenz aus den Metadaten, und jede Datei wird vor dem Versand gegen diese Regeln geprüft. Jetzt starten, kostenlos für 10 E-Rechnungen im Monat.

Dies sind allgemeine Informationen, keine Rechts- oder Steuerberatung. Wer die Validierungsregeln besteht, hat damit noch nicht geklärt, welche umsatzsteuerliche Behandlung gilt; klären Sie mit Ihrer Steuerberatung, was für Ihr Unternehmen gilt.