XRechnung abgelehnt: Prüfbericht lesen und die häufigsten Fehler beheben

Ein Rechnungsportal oder Ihr Kunde lehnt die E-Rechnung ab, und im Prüfbericht stehen Codes wie BR-DE-15 oder BR-CO-10. Diese Seite erklärt, wie der Bericht aufgebaut ist und was hinter den häufigsten Ablehnungen steckt.

So ist ein Prüfbericht aufgebaut

Die meisten Portale und Prüfprogramme in Deutschland verwenden die Prüfkonfiguration der KoSIT. Sie prüft in Stufen:

1. Schema: Ist die Datei formal richtig aufgebaut (richtige Elemente, richtige Reihenfolge)?
2. EN 16931: die europäischen Geschäftsregeln (Codes wie BR-…, BR-CO-…, BR-S-…, BR-CL-…).
3. XRechnung: die zusätzlichen deutschen Regeln (Codes BR-DE-…), nur wenn die Datei als XRechnung gekennzeichnet ist.

Jede Meldung hat eine Stufe. Fehler führen zur Empfehlung „ablehnen“. Warnungen und Hinweise lassen die Rechnung gültig, sollten aber trotzdem behoben werden. Wichtig: Kümmern Sie sich zuerst nur um die Fehler. Ein einziger fehlender Wert kann mehrere Folgemeldungen auslösen.

Die Fundstelle (z. B. /Invoice/cac:LegalMonetaryTotal) sagt, wo im XML der Fehler sitzt. Die Begriffe BT-… und BG-… sind die Nummern der Felder aus der Norm EN 16931, etwa BT-10 = Käuferreferenz.

Die häufigsten Gründe für eine Ablehnung

1. Käuferreferenz oder Leitweg-ID fehlt

BR-DE-15 (Käuferreferenz fehlt) ist bei Rechnungen an Behörden der Klassiker. Die Leitweg-ID gehört in das Feld Käuferreferenz (BT-10). Auch bei Unternehmen verlangt XRechnung das Feld; dort steht meist eine Bestell- oder Kostenstellennummer, die der Empfänger vorgibt.

2. Summen und Rundung

Summenfehler entstehen fast immer, weil die Software anders rundet, als die Norm rechnet:

• BR-CO-10: Die Summe der Positionsnettobeträge (BT-106) muss genau der Summe der einzelnen Positionen (BT-131) entsprechen. Ursache sind oft Positionen mit mehr als zwei Nachkommastellen oder Rabatte, die nur im PDF, aber nicht im Positionsbetrag stehen.
• BR-CO-13: Nettogesamtbetrag (BT-109) = Positionssumme − Nachlässe + Zuschläge auf Rechnungsebene.
• BR-CO-15: Bruttobetrag (BT-112) = Nettogesamtbetrag + Umsatzsteuer.
• BR-CO-17 und BR-S-08: Die Steuer wird je Steuerkategorie aus der Summe der Nettobeträge berechnet und dann gerundet – nicht je Position gerundet und anschließend addiert.

Tipp: Runden Sie jeden Positionsbetrag auf zwei Nachkommastellen, bevor Sie summieren, und stellen Sie Rabatte als Nachlass in der Position oder auf Rechnungsebene dar, damit die Rechnung in sich aufgeht.

3. Zahlungsangaben

• BR-DE-1: XRechnung verlangt Zahlungsanweisungen (BG-16), also mindestens den Code der Zahlungsart.
• {{BR-DE-23-a}} und BR-61: Bei Überweisung (Zahlungsart 30 oder 58) muss die Bankverbindung mit IBAN angegeben sein. Geben Sie die IBAN ohne Leerzeichen an und nur einmal.
• BR-CO-25: Ist ein Betrag offen, braucht die Rechnung ein Fälligkeitsdatum oder Zahlungsbedingungen.

4. Kontaktdaten des Verkäufers

XRechnung verlangt einen Ansprechpartner mit Telefonnummer und E-Mail-Adresse: BR-DE-2, BR-DE-5, BR-DE-6, BR-DE-7. Diese Felder fehlen oft, wenn die Rechnungsvorlage sie nur im Briefkopf des PDFs hat.

5. Falsche oder unbekannte Spezifikationskennung

Die Spezifikationskennung (BT-24) sagt dem Prüfprogramm, nach welchen Regeln es prüfen soll. Für XRechnung 3.0 lautet sie urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0. Fehlt sie oder passt sie nicht (BR-01, BR-DE-21), melden Portale „unbekanntes Profil“ oder prüfen nach falschen Regeln. ZUGFeRD-Rechnungen in den Profilen MINIMUM und BASIC WL enthalten nicht alle Pflichtangaben einer E-Rechnung; viele Empfänger lehnen sie deshalb ab.

6. Formfehler im XML

• PEPPOL-EN16931-R008: leere Elemente wie <cbc:Note/>. Lassen Sie Felder ohne Wert ganz weg.
• BR-CL-23: Mengeneinheiten müssen Codes sein (z. B. H87 für Stück, HUR für Stunde), keine Abkürzungen wie „Stk“.
• BR-CL-04: Währung als EUR, nicht „€“.

So gehen Sie vor

1. Rechnung im kostenlosen Prüfer öffnen. Er verwendet die Regeldateien der KoSIT und läuft in Ihrem Browser; die Datei wird nicht hochgeladen.
2. Nur die Fehler ansehen, von oben nach unten. Zu jedem erklärten Code gibt es eine Seite mit dem Feld in UBL und CII.
3. Den Fehler in der Vorlage oder Einstellung der Rechnungssoftware beheben, nicht von Hand im XML – sonst kommt er bei der nächsten Rechnung wieder.
4. Neu erzeugen, erneut prüfen, dann versenden.

Wenn Sie Rechnungen aus eigener Software oder einer Automatisierung erzeugen, können Sie dieselbe Prüfung vor dem Versand per API einbauen.

Technische Hinweise zum Datenformat, keine Steuer- oder Rechtsberatung. Ob Steuersatz, Leistung und Beträge in der Sache stimmen, klären Sie mit Ihrer Steuerberatung. Prüfklar ist kein Angebot der KoSIT.