E-Rechnung validieren: Die 7 Fehler, an denen ZUGFeRD-Rechnungen scheitern
E-Rechnung validieren leicht gemacht: Diese sieben EN-16931-Regeln lassen ZUGFeRD- und XRechnungen durchfallen — mit konkreten Beispielen und Lösungen.
Vellonode Team
Redaktion
„Ihre Rechnung wurde abgelehnt: BR-CL-01"
Eine solche Meldung ist der Moment, in dem die meisten Unternehmen zum ersten Mal merken, dass eine E-Rechnung mehr ist als ein PDF mit Anhang. Der Empfänger hat nichts falsch gemacht, sein System auch nicht — die Rechnung entspricht schlicht nicht der europäischen Norm EN 16931.
Das Tückische daran: Die Rechnung sieht optisch einwandfrei aus. Der Fehler steckt im eingebetteten XML, das kein Mensch liest. Wer seine E-Rechnung validieren lässt, findet solche Probleme, bevor der Kunde sie findet.
Dieser Artikel zeigt die sieben Regeln, an denen in der Praxis die meisten Rechnungen scheitern — und wie Sie jede davon abstellen.
Warum Sie jede E-Rechnung validieren sollten
Seit dem 1. Januar 2025 muss jedes inländische Unternehmen E-Rechnungen im B2B-Bereich empfangen können (§ 14 UStG in der Fassung des Wachstumschancengesetzes). Viele Empfänger haben deshalb Systeme im Einsatz, die eingehende Rechnungen automatisch gegen EN 16931 prüfen und bei Verstößen zurückweisen — ohne dass ein Mensch sie je sieht.
Eine abgelehnte Rechnung bedeutet: keine Zahlung, keine Fälligkeit, kein Vorsteuerabzug beim Kunden. Bei öffentlichen Auftraggebern ist die Prüfung verpflichtend, im B2B-Bereich zunehmend Standard.
Der Maßstab in Deutschland ist der KoSIT-Validator — die offizielle Prüfsoftware der Koordinierungsstelle für IT-Standards. Er kennt drei Urteile: ACCEPTABLE (angenommen), WARNING (angenommen mit Hinweisen) und REJECT (abgelehnt). Was dieser Validator ablehnt, lehnen die meisten Empfängersysteme ebenfalls ab.
Die 7 häufigsten Validierungsfehler
1. Ungültiger Rechnungstyp-Code (BR-CL-01)
Jede E-Rechnung trägt in Feld BT-3 einen Typcode aus der Codeliste UNTDID 1001. 380 steht für die Handelsrechnung, 381 für die Gutschrift, 384 für die Rechnungskorrektur.
Der Klassiker: Eine Software schreibt 220 in das Feld — das ist in UNTDID 1001 eine Bestellung, kein Rechnungstyp. Der Validator wirft BR-CL-01, und der Anwender sieht nur eine Regelnummer, mit der er nichts anfangen kann.
Lösung: Prüfen Sie, welcher Code tatsächlich gespeichert ist — nicht, welcher im Auswahlfeld angezeigt wird. Beides kann auseinanderlaufen.
2. Falsche Mengeneinheit (BR-CL-23)
Einheiten werden nicht als Text geschrieben, sondern als Code nach UN/ECE Rec. 20/21: C62 für Stück, HUR für Stunde, MTR für Meter, KGM für Kilogramm.
Ein häufiger Fehler entsteht durch naheliegende Abkürzungen: Aus „kW" wird KW — diesen Code gibt es nicht. Kilowatt ist KWT. Die Rechnung fällt komplett durch, wegen einer einzigen Position.
Lösung: Verwenden Sie nur Codes aus der offiziellen Liste. Im Zweifel ist C62 (Stück) die sichere Wahl — eine erfundene Abkürzung ist es nie.
3. Summen, die nicht aufgehen (BR-CO-10)
Die Summe der Positionsnettobeträge (BT-131) muss exakt der Positionssumme im Rechnungskopf (BT-106) entsprechen. Abweichungen von einem Cent reichen für eine Ablehnung.
Ursache sind fast immer Rundungen: Die Software rundet je Position auf zwei Stellen, rechnet die Kopfsumme aber aus ungerundeten Werten.
Lösung: Kopfsummen immer aus den bereits gerundeten Positionswerten bilden, nie parallel berechnen.
4. Verkäufer nicht eindeutig identifizierbar (BR-CO-26)
Diese Regel überrascht selbst erfahrene Buchhalter. EN 16931 verlangt mindestens eine dieser drei Angaben zum Verkäufer:
- BT-29 — Kennung des Verkäufers (z. B. Handelsregisternummer, GLN)
- BT-30 — Rechtliche Registrierung (z. B. HRB-Nummer)
- BT-31 — Umsatzsteuer-Identifikationsnummer
Die Steuernummer (BT-32) zählt ausdrücklich nicht dazu. Steuerlich genügt sie nach § 14 Abs. 4 Nr. 2 UStG — für die maschinelle Identifikation des Ausstellers reicht sie der Norm nicht.
Lösung: Wenn Sie keine USt-IdNr. haben, beantragen Sie eine kostenlos beim Bundeszentralamt für Steuern. Das ist der einfachste Weg, diese Regel dauerhaft zu erfüllen.
5. Fehlende Fälligkeitsangabe (BR-CO-25)
Ist ein Betrag zu zahlen (BT-115 größer null), muss die Rechnung entweder ein Fälligkeitsdatum (BT-9) oder Zahlungsbedingungen im Klartext (BT-20) enthalten. „Zahlbar sofort" genügt — gar nichts genügt nicht.
6. XRechnung-Pflichtfelder fehlen (BR-DE-*)
Hier liegt eine gefährliche Falle: Eine Rechnung kann EN-16931-konform sein und trotzdem als XRechnung durchfallen. Die deutsche Ausprägung verlangt zusätzlich:
| Regel | Anforderung |
|---|---|
| BR-DE-1 | Zahlungsbedingungen (BG-16) sind Pflicht |
| BR-DE-2 | Kontaktdaten des Verkäufers (BG-6) |
| BR-DE-5/6 | Name und Telefonnummer des Ansprechpartners |
| BR-DE-7 | E-Mail-Adresse des Verkäufers |
| BR-DE-15 | Leitweg-ID als Käuferreferenz (BT-10) bei Behörden |
Wer an öffentliche Auftraggeber liefert und die Leitweg-ID nicht vorab erfragt, kann die Rechnung nicht zustellen.
7. Steuerbeträge passen nicht zum Steuersatz (BR-CO-17)
Für jede Steuerkategorie muss gelten: Bemessungsgrundlage × Steuersatz = ausgewiesener Steuerbetrag, gerundet auf zwei Stellen. Rechnet Ihre Software den Steuersatz aus Beträgen zurück (etwa bei Importen aus Zahlungsdienstleistern), entstehen Werte wie 18,997 % — und die Regel schlägt fehl.
Checkliste: E-Rechnung validieren in 5 Schritten
- Vor dem ersten Versand eine Testrechnung gegen den KoSIT-Validator laufen lassen — nicht nur gegen die Prüfung Ihrer eigenen Software.
- Profil festlegen: ZUGFeRD mindestens im Profil EN 16931 (Comfort). Alles darunter — insbesondere „Minimum" und „Basic WL" — ist nicht E-Rechnungs-konform.
- Stammdaten einmalig prüfen: USt-IdNr., vollständige Anschrift, Ansprechpartner mit Telefon und E-Mail. Diese Felder verursachen die meisten Wiederholungsfehler.
- Einheiten und Steuerkategorien in den Artikelstammdaten hinterlegen, statt sie je Rechnung neu einzutippen.
- Bei jeder Änderung erneut prüfen — ein gespeichertes Prüfergebnis beschreibt die Fassung von gestern, nicht die von heute.
Ein häufiges Missverständnis: Die eingebaute Prüfung vieler Rechnungsprogramme meldet „gültig", obwohl der KoSIT-Validator ablehnt. Interne Prüfungen decken meist nur die Pflichtfelder ab, nicht die rund 200 Geschäftsregeln der Norm. Maßgeblich ist immer das Urteil des offiziellen Validators.
Was tun, wenn eine Rechnung bereits abgelehnt wurde?
Lassen Sie zuerst die abgelehnte E-Rechnung validieren, um die tatsächliche Ursache zu sehen — die Regelnummer aus der Ablehnung nennt sie meist nur verkürzt. Korrigieren Sie dann die Ursache und stellen Sie die Rechnung neu aus — mit derselben Rechnungsnummer, solange die fehlerhafte Fassung den Empfänger nie erreicht hat. Wurde sie bereits zugestellt und verbucht, brauchen Sie stattdessen eine formale Rechnungskorrektur.
Dokumentieren Sie außerdem, welche Regel gebrochen wurde. In fast allen Fällen liegt die Ursache in den Stammdaten oder in der Konfiguration — und wiederholt sich sonst bei jeder weiteren Rechnung.
Jede E-Rechnung validieren, bevor sie das Haus verlässt
Der wirksamste Hebel ist, die Prüfung an den Anfang zu stellen: nicht nach dem Versand, sondern davor. Wer bestehende PDF-Rechnungen in ZUGFeRD überführt, kann beide Schritte zusammenlegen — Daten auslesen, Einheitencodes und Steuerkategorien normgerecht zuordnen, XML erzeugen und direkt gegen EN 16931 prüfen.
Vellonode liest PDF-Rechnungen per KI aus, erzeugt daraus valides ZUGFeRD 2.4 und prüft jede Datei bei jedem Abruf mit dem offiziellen KoSIT-Validator. Befunde erscheinen im Klartext statt als Regelnummer — inklusive der Hinweise, die eine Rechnung zwar nicht ungültig machen, beim Empfänger aber Rückfragen auslösen. Sie können das ohne Installation testen.
Verwandter Artikel: XRechnung erstellen: Alle Pflichtfelder im Überblick