XRechnung-Fehler beheben: Die 10 häufigsten Validierungsfehler

Die meisten XRechnung-Fehler haben drei Ursachen: Pflichtfelder der deutschen Geschäftsregeln (BR-DE) fehlen, Summen widersprechen den Rechenregeln der EN 16931, oder die Spezifikationskennung in BT-24 passt nicht. Jede Fehlermeldung nennt eine Regel-ID wie BR-DE-15 und meist ein Business Term (BT). Über diese beiden Angaben finden Sie das betroffene XML-Element und beheben den Fehler gezielt.

Stand: September 2026. Grundlage: XRechnung 3.0.2 und die KoSIT-Prüfkonfiguration für XRechnung 3.0.2. Dieser Beitrag ersetzt keine Steuerberatung.

Wie ist eine XRechnung-Fehlermeldung aufgebaut?

Eine XRechnung wird in drei Stufen geprüft. Zuerst prüft das XML-Schema (XSD) von UBL 2.1 oder UN/CEFACT CII, ob die Datei technisch korrekt aufgebaut ist. Danach folgen die Schematron-Regeln der europäischen Norm EN 16931 und zum Schluss die nationalen Regeln der XRechnung, die die KoSIT herausgibt. Die offiziellen Regeldateien liegen öffentlich in der Prüfkonfiguration der KoSIT auf GitHub (öffnet in neuem Tab).

Jede Regel hat eine Stufe. Verstöße der Stufe „fatal“ führen im KoSIT-Validator zur Empfehlung „reject“. Verstöße der Stufe „warning“ werden gemeldet, die Empfehlung bleibt aber „accept“. Eine Fehlermeldung sieht zum Beispiel so aus: [BR-DE-15] Das Element "Buyer reference" (BT-10) muss übermittelt werden. In Prüfberichten stehen die EN-Regeln oft mit führender Null (BR-02 statt BR-2). Unser Verzeichnis der XRechnung Fehlercodes erklärt die Codes einzeln.

Die 10 häufigsten XRechnung-Fehler im Überblick

Fehler 1 bis 10: Ursache und Lösung

1. BR-DE-15: Käuferreferenz (BT-10) fehlt

BR-DE-15 meldet, dass das Feld „Buyer reference“ fehlt oder leer ist. BT-10 ist in jeder XRechnung Pflicht. Bei Behörden steht dort die Leitweg-ID, im B2B-Verkehr reicht eine andere Referenz des Käufers, etwa Bestellnummer, Kostenstelle oder Name des Bestellers. Die Ursache ist fast immer ein leeres Feld in den Kundenstammdaten.

Lösung: Befüllen Sie in UBL cbc:BuyerReference direkt unter dem Wurzelelement, in CII ram:ApplicableHeaderTradeAgreement/ram:BuyerReference. Die Leitweg-ID erhalten Sie vom Auftraggeber; wie Sie sie finden, beschreibt unser Beitrag Leitweg-ID finden und beantragen. Die KoSIT-Regeln prüfen die Prüfziffer nicht. Die OZG-RE tut es und meldet sonst „Leitweg-ID ist nicht valide“, oft wegen falsch gesetzter Bindestriche oder Leerzeichen. Mit unserem Werkzeug können Sie die Leitweg-ID prüfen, bevor Sie die Rechnung senden.

2. BR-DE-2, BR-DE-5 bis BR-DE-7: Verkäuferkontakt unvollständig

BR-DE-2 verlangt die Gruppe SELLER CONTACT (BG-6). Darin sind drei Felder Pflicht: Ansprechpartner BT-41 (BR-DE-5), Telefon BT-42 (BR-DE-6) und E-Mail BT-43 (BR-DE-7). Die EN 16931 kennt diese Pflicht nicht, deshalb fehlen die Angaben in vielen Exporten.

Lösung: In UBL gehören die Werte nach cac:AccountingSupplierParty/cac:Party/cac:Contact in cbc:Name, cbc:Telephone und cbc:ElectronicMail. In CII nutzen Sie ram:SellerTradeParty/ram:DefinedTradeContact mit ram:PersonName, ram:TelephoneUniversalCommunication/ram:CompleteNumber und ram:EmailURIUniversalCommunication/ram:URIID. Als Ansprechpartner genügt eine Abteilung wie „Buchhaltung“, als E-Mail ein Sammelpostfach. Zwei Warnungen prüfen das Format: BR-DE-27 erwartet mindestens drei Ziffern in der Telefonnummer, BR-DE-28 genau ein @-Zeichen in der E-Mail-Adresse.

3. BR-DE-3, BR-DE-4, BR-DE-8, BR-DE-9: Ort oder Postleitzahl fehlt

Die EN 16931 verlangt in Anschriften nur den Ländercode. Die XRechnung verlangt zusätzlich Ort und Postleitzahl des Verkäufers (BR-DE-3 für BT-37, BR-DE-4 für BT-38) und des Käufers (BR-DE-8 für BT-52, BR-DE-9 für BT-53). Geben Sie eine abweichende Lieferanschrift an, gelten BR-DE-10 und BR-DE-11 entsprechend. Typische Ursache: Die Anschrift steht im Quellsystem in einem einzigen Textfeld.

Lösung: Trennen Sie die Anschrift in Straße, Postleitzahl und Ort. In UBL heißen die Elemente cbc:PostalZone und cbc:CityName unter cac:PostalAddress, in CII ram:PostcodeCode und ram:CityName unter ram:PostalTradeAddress.

4. BR-DE-21: Spezifikationskennung in BT-24 falsch

BR-DE-21 prüft, ob BT-24 der Kennung der XRechnung entspricht. Für Version 3.0 lautet sie urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0. Häufige Ursachen sind ältere Kennungen mit xoev-de aus XRechnung 2.x, Tippfehler oder die reine Kennung der EN 16931, urn:cen.eu:en16931:2017.

Die Regel selbst ist nur eine Warnung. Der KoSIT-Validator wählt sein Prüfszenario aber anhand von BT-24. Passt die Kennung zu keinem Szenario, lautet die Empfehlung „reject“. Mit der reinen Kennung der EN 16931 werden nur die europäischen Regeln geprüft, und die Datei gilt beim Empfänger nicht als XRechnung. Lösung: cbc:CustomizationID (UBL) oder rsm:ExchangedDocumentContext/ram:GuidelineSpecifiedDocumentContextParameter/ram:ID (CII) korrigieren. Die Vorversion der XRechnung 4.0 erschien im September 2026, die finale Fassung wird für Frühjahr 2027 erwartet. Stellen Sie erst um, wenn Ihre Empfänger die neue Version annehmen.

5. BR-DE-1 und BR-DE-23: Zahlungsangaben fehlen oder passen nicht

BR-DE-1 verlangt die Gruppe PAYMENT INSTRUCTIONS (BG-16), mindestens also einen Zahlungsartcode in BT-81. BR-DE-23 greift bei Überweisung: Steht in BT-81 der Code 30 oder 58, muss die Gruppe CREDIT TRANSFER (BG-17) mit der IBAN in BT-84 folgen, und die Gruppen für Karte (BG-18) und Lastschrift (BG-19) dürfen nicht vorkommen. Für Lastschrift mit Code 59 verlangen BR-DE-25, BR-DE-30 und BR-DE-31 die Gläubiger-ID (BT-90) und die IBAN des Zahlers (BT-91).

Lösung: In UBL cac:PaymentMeans/cbc:PaymentMeansCode und cac:PaymentMeans/cac:PayeeFinancialAccount/cbc:ID füllen, in CII ram:SpecifiedTradeSettlementPaymentMeans/ram:TypeCode und ram:PayeePartyCreditorFinancialAccount/ram:IBANID. Schreiben Sie die IBAN ohne Leerzeichen, sonst meldet die Warnung BR-DE-19 eine ungültige IBAN. Ist ein Betrag offen, geben Sie außerdem ein Fälligkeitsdatum (BT-9) oder Zahlungsbedingungen (BT-20) an. Ältere Prüfkonfigurationen, etwa die KoSIT-Konfiguration vom Oktober 2024, verlangen das als Regel BR-CO-25; in der Konfiguration vom 31. August 2026 (CEN-Schematron 1.3.16) ist diese Regel entfallen.

6. BR-DE-18: Skonto falsch formatiert

BR-DE-18 ist ein fataler Fehler. Skonto muss in den Zahlungsbedingungen (BT-20) maschinenlesbar stehen: #SKONTO#TAGE=14#PROZENT=2.00#. Der Prozentsatz braucht einen Punkt und genau zwei Nachkommastellen, alles steht in Großbuchstaben, ohne Leerzeichen, und nach jeder Skontozeile folgt ein Zeilenumbruch. Gilt der Skonto nur für einen Teilbetrag, folgt das Segment #BASISBETRAG=…# mit zwei Nachkommastellen.

Lösung: Schreiben Sie freien Text wie „2 % Skonto bei Zahlung innerhalb von 14 Tagen“ in eine eigene Zeile ohne führendes #. Nur Zeilen, die mit # beginnen, werden gegen das Muster geprüft. In UBL liegt BT-20 in cac:PaymentTerms/cbc:Note, in CII in ram:SpecifiedTradePaymentTerms/ram:Description.

7. BR-CO-10 und die Summenkette: Beträge stimmen nicht

BR-CO-10 verlangt, dass BT-106 exakt der Summe aller Positionsnettobeträge (BT-131) entspricht. Darauf bauen weitere Regeln auf: BR-CO-13 prüft den Nettobetrag BT-109 (Positionen minus Nachlässe BT-107 plus Zuschläge BT-108), BR-CO-15 den Bruttobetrag BT-112 (BT-109 plus Steuer BT-110) und BR-CO-16 den Zahlbetrag BT-115 (BT-112 minus Anzahlungen BT-113 plus Rundung BT-114).

Ursache ist meist Rundung. Beispiel: 7 Stück zu 1,235 € ergeben 8,645 €. Die Position muss mit 8,65 € in BT-131 stehen, denn Beträge haben höchstens zwei Nachkommastellen. BT-106 ist dann die Summe der bereits gerundeten Positionen. Wer ungerundet summiert und erst die Summe rundet, erzeugt Cent-Differenzen.

8. BR-S-08 und BR-CO-17: Umsatzsteuer-Aufschlüsselung fehlerhaft

Für jeden Steuersatz braucht die Rechnung eine eigene Aufschlüsselung (BG-23). BR-S-08 verlangt, dass die Bemessungsgrundlage BT-116 je Satz der Summe der passenden Positionen plus Zuschläge minus Nachlässe entspricht. BR-CO-17 verlangt, dass der Steuerbetrag BT-117 gleich BT-116 × BT-119 / 100 ist, gerundet auf zwei Nachkommastellen. Beispiel: Positionen zu 19 % über 99,99 € ergeben 18,9981 € und damit 19,00 € Steuer.

Bei Kategorie E (steuerfrei, etwa Kleinunternehmer nach § 19 UStG) verlangt BR-E-10 einen Befreiungsgrund in BT-120 oder BT-121. Bei Reverse Charge (Kategorie AE) verlangt BR-AE-10 den Grund „Reverse charge“. BR-DE-14 verlangt den Steuersatz BT-119 immer, bei E und AE also 0. In UBL liegen die Werte in cac:TaxTotal/cac:TaxSubtotal, in CII in ram:ApplicableHeaderTradeSettlement/ram:ApplicableTradeTax.

9. BR-CO-9, BR-CO-26, BR-S-02: Steuernummer fehlt oder steht im falschen Feld

Häufig steht die Steuernummer im Feld für die USt-IdNr. (BT-31). Dann schlägt BR-CO-9 an, weil BT-31 mit einem Ländercode wie „DE“ beginnen muss. BR-CO-26 verlangt eine Kennung des Verkäufers (BT-29, BT-30 oder BT-31), BR-S-02 bei steuerpflichtigen Positionen BT-31, BT-32 oder BT-63. Die FAQ der OZG-RE nennt BR-CO-9 und BR-CO-26 ausdrücklich als Hinweis auf eine fehlerhafte Eingabe der Steuernummer.

Lösung: Die USt-IdNr. gehört in UBL in cac:PartyTaxScheme/cbc:CompanyID mit TaxScheme VAT, die Steuernummer in einen zweiten cac:PartyTaxScheme mit TaxScheme FC. In CII ist es ram:SpecifiedTaxRegistration/ram:ID mit schemeID="VA" oder schemeID="FC". Die Angabe ist zugleich Pflichtangabe nach § 14 Abs. 4 UStG.

10. Schemafehler: Die Datei ist technisch fehlerhaft

Scheitert schon das XML-Schema, laufen die Geschäftsregeln oft gar nicht erst. Unser Fehlerverzeichnis fasst diese Fälle als SCHEMA-001 (nicht wohlgeformt), SCHEMA-002 (falscher Namensraum oder Wurzelelement) und SCHEMA-003 (Pflichtelement fehlt oder steht an falscher Stelle) zusammen. Der KoSIT-Validator zeigt sie als Schema-Meldungen, etwa „cvc-complex-type.2.4.a: Invalid content was found starting with element …“.

Typische Ursachen: Elemente in falscher Reihenfolge (UBL schreibt sie vor), Datum im falschen Format (UBL 2026-09-28, CII 20260928 mit format="102"), Dezimalkomma statt Punkt, ein unmaskiertes & oder ein falscher Namensraum. Zum Nachsehen können Sie die XML-Datei öffnen und formatiert anzeigen lassen. Der Aufbau beider Syntaxen steht in unserem Beitrag zur XRechnung-XML-Struktur.

Welche Warnungen sollten Sie trotzdem beheben?

Warnungen blockieren die Prüfung nicht, können aber beim Empfänger Rückfragen auslösen:

• BR-DE-17: BT-3 soll einer dieser Codes sein: 326 (Teilrechnung), 380 (Rechnung), 384 (korrigierte Rechnung), 389 (Gutschrift im Gutschriftsverfahren), 381 (Gutschrift/Rechnungskorrektur), 875, 876 und 877 (Abschlags-, Teilschluss- und Schlussrechnung im Bau).
• BR-DE-26: Bei Code 384 soll die ursprüngliche Rechnung in BG-3 referenziert sein (UBL cac:BillingReference/cac:InvoiceDocumentReference/cbc:ID).
• BR-DE-19 und BR-DE-20: IBAN bei SEPA-Überweisung (58) oder SEPA-Lastschrift (59) ungültig.
• BR-DE-27 und BR-DE-28: Telefonnummer oder E-Mail-Adresse formal auffällig.

Fatal ist dagegen BR-DE-22: Eingebettete Anhänge brauchen eindeutige Dateinamen. Mehr dazu im Beitrag XRechnung mit Anhang.

Formatfehler, Geschäftsregelfehler, Inhaltsfehler: Was sagt das BMF?

Das BMF-Schreiben vom 15.10.2025 (öffnet in neuem Tab) unterscheidet drei Fehlerklassen (Rn. 6a, 6b und 35a):

Ein Inhaltsfehler kann auch vorliegen, wenn die Validierung nichts meldet, etwa bei 7 % statt 19 %. Die Validierung ersetzt nicht die Prüfung durch den Empfänger. Ein Unternehmer darf sich aber auf das technische Ergebnis einer geeigneten Validierungsanwendung verlassen. Bewahren Sie den Prüfbericht als Nachweis auf; wie, steht im Beitrag E-Rechnung archivieren. Die umsatzsteuerlichen Angaben können Sie mit unserem Werkzeug Pflichtangaben prüfen.

XRechnung abgelehnt: Was tun?

Beim Bund laufen Rechnungen über die OZG-RE. Laut FAQ der E-Rechnung des Bundes (öffnet in neuem Tab) weist entweder die Plattform wegen formaler oder rechnerischer Fehler zurück oder der Empfänger wegen inhaltlicher Fehler. So gehen Sie vor:

1. Status prüfen: Die OZG-RE kennt die Status Neu, Duplikat erkannt, Bereitgestellt, Zugestellt, Zurückgewiesen und Gelöscht.
2. Details öffnen: Bei Versand per E-Mail oder Peppol führt das Lupensymbol in der Rechnungsübersicht zu den Detailergebnissen der formalen Prüfung. Bei Weberfassung und Upload können Sie direkt auf der Plattform validieren.
3. Regel-ID nachschlagen und den Fehler im Quellsystem beheben, nicht per Hand im XML.
4. Neu validieren, zum Beispiel mit unserem XRechnung Validator, der die offiziellen KoSIT-Regeln verwendet und jede Meldung erklärt.
5. Erneut einreichen. Hat der Empfänger zurückgewiesen, lesen Sie seine Bemerkung und klären Sie mit der Rechnungsstelle, ob er eine korrigierte Rechnung erwartet.

Im B2B-Verkehr gibt es keine zentrale Plattform. Ob eine fehlerhafte Datei abgelehnt wird, entscheidet die Software des Empfängers.

So vermeiden Sie XRechnung-Fehler dauerhaft

Nutzen Sie nach Software-Updates und vor einem Wechsel auf XRechnung 4.0 eine bekannte, gültige Datei als Referenz; unser XRechnung Muster eignet sich dafür. Wer keine eigene Software hat, kann eine XRechnung erstellen, die die Pflichtfelder der Fehler 1 bis 6 abfragt. Die Schritte im Detail zeigt unsere Anleitung zum Erstellen einer XRechnung. Weitere Beiträge finden Sie in der Kategorie Validierung und Fehler.