Eine E-Rechnung kann formal korrekt aussehen und trotzdem abgewiesen werden, weil eine einzige Geschäftsregel verletzt ist. Die meisten Fehler fallen in wenige Gruppen: fehlende Pflichtfelder, Rechenfehler, falsche Steuerangaben und falsche Formate. Dieser Artikel erklärt zehn typische Fehler in Klartext und zeigt, wie Sie sie automatisch finden.
Wie eine E-Rechnung geprüft wird
Die Prüfung läuft in zwei Stufen:
- Schema-Prüfung: Ist das XML technisch richtig aufgebaut? Stimmen Tag-Namen, Reihenfolge und Datentypen?
- Geschäftsregeln (Schematron): Stimmen die Inhalte? Hier greifen die Regeln der EN 16931 (Präfix BR, BR-CO, BR-S usw.) und bei XRechnung die deutschen Zusatzregeln (BR-DE).
Das offizielle Regelwerk für XRechnung und das Prüfwerkzeug veröffentlicht die KoSIT. Öffentliche Rechnungseingangsplattformen prüfen nach denselben Regeln. Wer vorher gegen dieselben Regeln prüft, vermeidet die meisten Ablehnungen dort.
Die Regelnummern unten beziehen sich auf XRechnung 3.0.2. Einzelne Nummern können sich mit neuen Versionen ändern. Ein gutes Prüfprotokoll nennt immer die Regel und die Version, gegen die geprüft wurde.
Zehn typische Fehler
1. Käuferreferenz fehlt (BR-DE-15)
Die XRechnung verlangt immer eine Käuferreferenz im Feld BT-10. Bei öffentlichen Auftraggebern ist das die Leitweg-ID, bei Unternehmen eine vereinbarte Referenz wie die Bestellnummer. Der Fehler ist deshalb so häufig, weil das Feld in vielen Programmen optional ist. Bei Leitweg-IDs kommt ein zweiter Fehler dazu: Tippfehler, die die Prüfziffer ungültig machen. Übernehmen Sie die Leitweg-ID immer aus der Bestellung, nie aus dem Gedächtnis.
2. Summen stimmen nicht (BR-CO-10, BR-CO-13, BR-CO-15, BR-CO-16)
Die Norm rechnet nach: Die Summe der Positionsbeträge muss der Nettosumme entsprechen, Netto plus Steuer muss den Bruttobetrag ergeben, und der Zahlbetrag muss Brutto minus Anzahlungen sein. Schon ein Cent Abweichung reicht für eine Ablehnung. Ursache sind meist Rabatte, die im PDF auftauchen, im XML aber nicht als Abschlag erfasst sind.
3. Steuerbetrag uneinheitlich gerundet
Die Norm berechnet die Steuer je Steuersatz auf die Summe der Nettobeträge und rundet dann auf zwei Stellen (BR-CO-17). Die offizielle Regel lässt dabei eine kleine Toleranz zu, eine Rundung pro Position allein führt also nicht zur Ablehnung. Kritisch wird es, wenn die Beträge untereinander nicht mehr aufgehen, etwa die Steuer je Satz nicht zur Steuersumme passt oder Netto plus Steuer nicht den Bruttobetrag ergibt (BR-CO-14, BR-CO-15). Ein Rechenbeispiel steht in E-Rechnung aus JSON erzeugen.
4. Falsche Steuerkategorie oder fehlender Befreiungsgrund
Jeder Steuerbetrag hat eine Kategorie: S (Normalsatz), Z (Nullsatz), E (steuerbefreit), AE (Steuerschuldnerschaft des Leistungsempfängers), K (innergemeinschaftliche Lieferung) und weitere. Typische Fehler: Kategorie S mit 0 %, Kategorie E ohne Befreiungsgrund (BR-E-10) oder AE ohne die USt-IdNr. beider Seiten. Die Kategorie muss zum tatsächlichen Umsatz passen. Das ist eine steuerliche Frage, keine technische.
5. Kontaktdaten des Verkäufers fehlen (BR-DE-2, BR-DE-6, BR-DE-7)
XRechnung verlangt eine Kontaktstelle des Verkäufers mit Telefonnummer und E-Mail-Adresse. In der EN 16931 allein ist das nicht Pflicht, deshalb fehlt es oft bei Rechnungen aus nicht-deutscher Software.
6. Zahlungsangaben fehlen (BR-DE-1)
XRechnung verlangt Zahlungsanweisungen. Bei Überweisung gehört eine IBAN dazu. Fehlt die Angabe, weiß die Kreditorenbuchhaltung des Kunden nicht, wohin sie zahlen soll.
7. Währung fehlt oder ist falsch (BR-05, BR-CL-04)
Der Rechnungswährungscode ist Pflicht und muss ein ISO-4217-Code sein, also EUR und nicht € oder Euro. Wird in einer Fremdwährung abgerechnet, muss die Umsatzsteuer zusätzlich in Euro angegeben werden.
8. Datumsformat falsch
UBL erwartet 2026-09-25, CII erwartet im Format 102 20260925. 25.09.2026 ist in UBL ein Schemafehler; in CII meldet der aktuelle KoSIT-Validator es als Warnung, künftig als Fehler. Das passiert, wenn Daten aus einer Tabelle oder einem deutschen Formular ungeprüft ins XML wandern. Dasselbe gilt für Beträge: Dezimaltrennzeichen ist der Punkt, nicht das Komma.
9. Spezifikationskennung oder Profil falsch (BR-01, BR-DE-21)
Im Feld BT-24 steht, nach welchen Regeln die Rechnung gebaut ist. Fehlt sie, greift BR-01. Steht dort eine veraltete XRechnung-Version, findet der aktuelle KoSIT-Validator kein passendes Prüfszenario und weist die Rechnung ab. Bei ZUGFeRD ist der häufigste Fall ein Profil MINIMUM oder BASIC WL, das rechtlich keine E-Rechnung ist. Mehr dazu in XRechnung oder ZUGFeRD.
10. Codes außerhalb der Codelisten
Mengeneinheiten, Länder, Zahlungsarten und Rechnungstypen stammen aus festen Codelisten. Std. ist keine gültige Einheit, HUR (Stunde) oder C62 (Stück) schon. Deutschland ist kein Ländercode, DE schon.
Ein Beispiel: prüfen per API
Die Muster GmbH erhält die Rechnung RE-2026-0042 als XRechnung und will sie prüfen, bevor sie in die Buchhaltung geht. Mit formkorrekt ist das ein einziger Aufruf:
curl -X POST https://formkorrekt.com/v1/invoices/validate \
-H "Authorization: Bearer $KEY" \
--data-binary @RE-2026-0042.xml
Die Rechnung hat keine Käuferreferenz. Die Antwort (gekürzt) nennt Format, Profil, Prüfversion und jeden Befund mit Fundstelle und Korrekturhinweis:
{
"status": "invalid",
"format": "xrechnung-ubl",
"profile": "EN16931",
"findings": [{
"severity": "error",
"code": "BR-DE-15",
"message_de": "Die Käuferreferenz (BT-10) fehlt. Bei Rechnungen an öffentliche Auftraggeber ist die Leitweg-ID anzugeben.",
"fix_hint": "Feld 'invoice.buyer.buyer_reference' befüllen."
}]
}
Die Prüfung selbst antwortet mit HTTP 200, auch wenn die Rechnung Fehler hat. Entscheidend ist das Feld status (valid oder invalid). So kann ein Skript den Eingang automatisch aussortieren. Eine Prüfung zählt als ein Dokument. Die Rechnung wird nur im Arbeitsspeicher verarbeitet und nicht gespeichert.
Manche Fehler lassen sich eindeutig beheben, zum Beispiel falsch berechnete Summen, eine fehlende Spezifikationskennung oder falsch formatierte Daten und Zahlen. Dafür gibt es /v1/invoices/repair. Die Antwort listet jede Änderung mit Regel, Fundstelle und altem und neuem Wert. Alles, was eine inhaltliche Entscheidung braucht, etwa eine fehlende Käuferreferenz oder eine Steuerkategorie, wird nicht geraten und bleibt als Befund stehen. Eine Reparatur funktioniert nur mit reinem XML, nicht mit PDF.
Ob Sie eine fremde Rechnung selbst reparieren sollten, ist eine eigene Frage. Bei Eingangsrechnungen ist der saubere Weg meist, den Absender um eine korrigierte Rechnung zu bitten. Reparieren lohnt sich vor allem bei Ihren eigenen Ausgangsrechnungen.
Häufige Fragen
Warnung oder Fehler: Was muss ich beheben?
Fehler (error) führen zur Ablehnung, Warnungen (warning) nicht. Warnungen zeigen trotzdem oft, dass etwas unsauber ist, und sollten angesehen werden.
Reicht es, ZUGFeRD im PDF-Reader zu öffnen? Nein. Der PDF-Reader zeigt nur das sichtbare PDF. Geprüft werden muss das eingebettete XML, denn das ist rechtlich maßgeblich.
Darf ich eine fehlerhafte Eingangsrechnung ablehnen? Sie dürfen den Absender um Korrektur bitten. Nach dem BMF-Schreiben vom 15. Oktober 2025 sind Verstöße gegen Geschäftsregeln, die keine umsatzsteuerlichen Pflichtangaben betreffen (etwa eine fehlende Käuferreferenz), umsatzsteuerlich unbeachtlich. Fehlen dagegen Pflichtangaben nach § 14 UStG, ist die Rechnung nicht ordnungsgemäß. Den Einzelfall klären Sie mit Ihrer Steuerberatung.
Weiterlesen: E-Rechnungspflicht 2025 bis 2028 · XRechnung oder ZUGFeRD · E-Rechnung aus JSON erzeugen · E-Rechnung in der Kanzlei