Es gibt Handbücher zu EN 16931 mit dreihundert Seiten. Was darin fehlt, ist die Antwort auf die einzige Frage, die beim ersten Versand zählt: welche Regeln schlagen in der Praxis tatsächlich zu?
Diese Liste entstand anders als die Handbücher. Wir haben vierzig Rechnungsdokumente — zwanzig Fälle, jeweils als XRechnung (UBL) und als ZUGFeRD (CII) — durch den Validator des Mustangprojects geschickt, mit den Prüfregeln der KoSIT für XRechnung 3.0. Was hier steht, sind die Regeln, die dabei angeschlagen haben, mit den Fehlermeldungen, die der Validator wirklich ausgibt.
Vorab: wer prüft da eigentlich?
Ein Prüflauf besteht aus drei Schichten, die aufeinanderliegen:
| Schicht | Woher | Was sie prüft |
|---|---|---|
| XML-Schema | UBL 2.1 bzw. CII D16B | Ist die Datei überhaupt wohlgeformt? |
| EN 16931 Schematron | CEN | Betriebswirtschaftliche Regeln: BR-…, BR-CO-… |
| CIUS XRechnung | KoSIT | Deutsche Zusätze: BR-DE-…, dazu Peppol-Regeln |
Wichtig für die Fehlersuche: eine Datei kann schema-valide und trotzdem ungültig sein. Die meisten Ablehnungen kommen aus der zweiten und dritten Schicht. Und: die XRechnung-Prüfung ist strenger als die ZUGFeRD-Prüfung. Wer gegen XRechnung besteht, besteht in der Regel auch gegen ZUGFeRD — der umgekehrte Schluss gilt nicht.
1. BR-CO-26 — der Verkäufer ist nicht identifizierbar
Im Detail: BR-CO-26 — Ursache, Lösung und XML-Beispiel.
In order for the buyer to automatically identify a supplier, the Seller identifier (BT-29), the Seller legal registration identifier (BT-30) and/or the Seller VAT identifier (BT-31) shall be present.
Im Klartext: Mindestens eine von drei Kennungen muss beim Verkäufer stehen. Eine Kennung (BT-29), eine Handelsregisternummer (BT-30) oder eine Umsatzsteuer-Identifikationsnummer (BT-31).
Die Falle: Die deutsche Steuernummer ist keine davon. Sie ist BT-32 und steht im
XML als PartyTaxScheme mit dem Schema FC. Für BR-CO-26 zählt sie nicht.
Betroffen ist damit ausgerechnet die größte Gruppe: Kleinunternehmer und Freiberufler ohne USt-IdNr. und ohne Registereintrag. Inhaltlich ist ihre Rechnung einwandfrei, der Validator weist sie ab.
Die Lösung: Steuernummer zusätzlich als BT-29 mitgeben. In UBL:
<cac:PartyIdentification>
<cbc:ID>21/123/45678</cbc:ID>
</cac:PartyIdentification>
In CII entsprechend ram:ID als erstes Kind von ram:SellerTradeParty. Es wird dabei nichts
erfunden — es ist dieselbe Kennung, unter der das Finanzamt den Verkäufer führt. Mehr dazu
unter Kleinunternehmer und E-Rechnung.
2. PEPPOL-EN16931-R010 — die E-Mail des Empfängers fehlt
Im Detail: PEPPOL-EN16931-R010 — Ursache, Lösung und XML-Beispiel.
Buyer electronic address MUST be provided
Im Klartext: BT-49, die elektronische Adresse des Empfängers, ist in XRechnung 3.0 Pflicht. § 14 UStG kennt dieses Feld nicht, weshalb es in vielen Rechnungsprogrammen als optional geführt wird. Für die XRechnung ist es verbindlich.
<cac:AccountingCustomerParty>
<cac:Party>
<cbc:EndpointID schemeID="EM">buchhaltung@kunde.de</cbc:EndpointID>
Gut zu wissen: Diese Regel greift nur bei der XRechnung-Prüfung. Dieselbe Rechnung als ZUGFeRD läuft durch. Wer beides erzeugt, braucht die Adresse trotzdem — sonst ist eine der beiden Dateien unbrauchbar.
3. BR-27 — der Einzelpreis darf nicht negativ sein
Im Detail: BR-27 — Ursache, Lösung und XML-Beispiel.
Im Klartext: Der Preis pro Einheit (BT-146) muss null oder positiv sein. Immer.
Die Falle: Bei einer Gutschrift oder einem Storno ist der Reflex, die Beträge negativ zu setzen. Das ist falsch. Eine Gutschrift wird über die Menge negativ, nicht über den Preis:
<cbc:InvoicedQuantity unitCode="H87">-6</cbc:InvoicedQuantity>
<cac:Price>
<cbc:PriceAmount currencyID="EUR">145.00</cbc:PriceAmount>
</cac:Price>
Das Ergebnis ist rechnerisch dasselbe und regelkonform. Zusätzlich gehört der Dokumenttyp
angepasst: 381 für eine Gutschrift, 384 für eine korrigierte Rechnung — nicht 380.
4. BR-DE-5, BR-DE-6, BR-DE-7 — Absenderkontakt unvollständig
Im Detail: BR-DE-5, BR-DE-6 und BR-DE-7 — jeweils mit Ursachen, Lösung und der Frage, was zu tun ist, wenn die Rechnung schon raus ist.
Im Klartext: Die XRechnung verlangt beim Verkäufer eine Kontaktgruppe (BG-6) mit Ansprechpartner, Telefonnummer und E-Mail-Adresse. Alle drei. Fehlt eines, weist die Prüfung ab.
Das ist der häufigste Stolperstein beim ersten Behördenauftrag: die Rechnung, die an Geschäftskunden immer funktioniert hat, fällt durch, weil auf ihr keine Telefonnummer steht.
<cac:Contact>
<cbc:Name>P. Beispiel</cbc:Name>
<cbc:Telephone>0431 1234567</cbc:Telephone>
<cbc:ElectronicMail>rechnung@betrieb.de</cbc:ElectronicMail>
</cac:Contact>
5. BR-DE-15 — Leitweg-ID fehlt
Im Detail: BR-DE-15 — Ursache, Lösung und XML-Beispiel.
Im Klartext: BT-10, die Käuferreferenz, ist in der XRechnung Pflicht. Bei öffentlichen Auftraggebern ist das die Leitweg-ID.
Aufbau, Prüfziffer und wo man sie herbekommt, steht in einem eigenen Beitrag: Leitweg-ID: Aufbau, Prüfziffer und wo du sie findest.
6. BR-DE-18 — der Skonto-Block braucht einen Zeilenumbruch
Im Detail: BR-DE-18 — Ursache, Lösung und XML-Beispiel.
Im Klartext: Skonto wird in der XRechnung in einem fest formatierten Textblock in den Zahlungsbedingungen (BT-20) angegeben:
#SKONTO#TAGE=14#PROZENT=2.00#BASISBETRAG=1245.00#
Die Falle, die niemand erwartet: Nach dem letzten # MUSS ein Zeilenumbruch stehen.
Endet das Feld direkt nach dem Raute-Zeichen, schlägt die Regel an. Ein unsichtbares Zeichen
entscheidet über gültig und ungültig — das findet niemand durch Nachdenken, nur durch Prüfen.
7. PEPPOL-EN16931-R008 — kein leeres Lieferelement
Im Detail: PEPPOL-EN16931-R008 — Ursache, Lösung und XML-Beispiel.
Im Klartext: Das Element cac:Delivery darf nicht leer sein. Wer es vorsorglich schreibt
und kein Lieferdatum hat, produziert genau das:
<cac:Delivery/> <!-- ungültig -->
Richtig ist: entweder mit Inhalt oder gar nicht. Das gilt für mehrere optionale Gruppen. Die Regel dahinter: In EN 16931 ist eine leere Gruppe kein „nicht angegeben", sondern ein Fehler.
8. BR-CO-15 — die Summen müssen aufgehen
Im Detail: BR-CO-15 — Ursache, Lösung und XML-Beispiel.
Im Klartext: Bruttobetrag (BT-112) = Nettobetrag (BT-109) + Steuerbetrag (BT-110). Auf den Cent.
Die Falle liegt im Runden. Der Steuerbetrag wird einmal pro Steuergruppe auf den Nettobetrag dieser Gruppe gerechnet und dann gerundet — nicht pro Position. Wer je Zeile rundet und aufsummiert, landet bei Rechnungen mit vielen Positionen regelmäßig einen Cent daneben, und der Validator weist ab.
Zwei Positionen à 4,995 € netto mit 19 %:
| Verfahren | Steuer | Ergebnis |
|---|---|---|
| pro Position runden | 0,95 + 0,95 | 1,90 € — falsch |
| pro Steuergruppe runden | 19 % von 9,99 = 1,8981 | 1,90 € — richtig |
Hier gleich, aber schon bei drei Positionen läuft es auseinander. Wer intern in ganzen Cent rechnet und kaufmännisch rundet, hat das Problem nicht.
9. BR-DE-21 — Rechnungsnummer und Dokumenttyp müssen zusammenpassen
Im Detail: BR-DE-21 — Ursache, Lösung und XML-Beispiel.
Im Klartext: Eine korrigierte Rechnung (384) muss die Nummer der ursprünglichen Rechnung
in BT-25 nennen. Wer eine Korrektur ohne Bezug schickt, hat aus Sicht des Empfängers zwei
unverbundene Rechnungen — und aus Sicht der Prüfung einen Fehler.
10. Falsche ZUGFeRD-Benennung im PDF
Diese Regel steht in keinem Schematron, sie fällt erst beim Empfänger auf.
Im Klartext: Seit ZUGFeRD 2.1 muss die eingebettete XML-Datei im PDF/A-3
factur-x.xml heißen. Frühere Versionen nannten sie zugferd-invoice.xml. Programme, die
noch die alte Benennung schreiben, produzieren PDFs, in denen der Empfänger die strukturierten
Daten nicht findet — das PDF sieht richtig aus, die Automatisierung greift ins Leere.
Prüfen lässt sich das mit einem Blick in die XMP-Metadaten des PDF: dort muss der
Namensraum urn:factur-x:pdfa:CrossIndustryDocument:invoice:1p0# stehen und der Dateiname
factur-x.xml.
Wie du selbst prüfst
Drei Wege, in aufsteigender Verbindlichkeit:
- Unser E-Rechnungs-Validator. Datei hineinziehen, Prüfmeldungen mit Regel-IDs im Klartext. Ohne Anmeldung, ohne Zeitlimit.
- Der offizielle Prüfdienst der KoSIT. Maßgeblich für XRechnung, wenn es um die Anerkennung durch eine Behörde geht.
- Mustangproject als Kommandozeilenwerkzeug. Wenn du es in eigene Abläufe einbauen willst.
Und die Regel, die alle Regeln überflüssig macht: prüfen, bevor die Datei rausgeht. Eine abgewiesene Rechnung kostet nicht nur die Korrektur, sie verschiebt das Zahlungsziel um die Zeit, die niemand mitgerechnet hat.
Alle Regeln zum Nachschlagen
Zu jeder dieser Regeln — und zu weiteren zehn — gibt es eine eigene Seite mit dem wörtlichen Regeltext, den realen Ursachen, einem XML-Beispiel falsch gegen richtig und zwei Fragen, die sonst niemand beantwortet: was der Empfänger überhaupt sieht, und ob du dieselbe Rechnungsnummer noch einmal verwenden darfst.
Zur Fehlerdatenbank: alle 20 Prüfregeln
Kurz zusammengefasst
- Die XRechnung-Prüfung ist strenger als die ZUGFeRD-Prüfung — prüfe gegen die strengere.
- BR-CO-26 trifft Kleinunternehmer: Steuernummer allein genügt nicht, sie muss zusätzlich als BT-29 stehen.
- BT-49, die E-Mail des Empfängers, ist in XRechnung 3.0 Pflicht, obwohl § 14 UStG sie nicht verlangt.
- Gutschriften werden über negative Mengen gebaut, nie über negative Preise.
- Umsatzsteuer einmal pro Steuergruppe runden, nie pro Position.
- Leere optionale Elemente sind Fehler, keine Leerstellen.
- Der Anhang im ZUGFeRD-PDF heißt seit Version 2.1
factur-x.xml.
Grundlage sind 40 Prüfläufe vom 25. Juli 2026 gegen Mustangproject 2.24 mit den KoSIT-Regeln für XRechnung 3.0. Die Regelwerke werden zweimal jährlich fortgeschrieben — Regel-IDs bleiben stabil, Formulierungen können abweichen.