Beispielrechnungen im Test: 810 XRechnung- und ZUGFeRD-Muster gegen das aktuelle Regelwerk

Auf einen Blick

810

verschiedene Dateien, die ihr Herausgeber als gültiges Beispiel anbietet

548

bestehen das aktuelle Regelwerk

102

werden abgelehnt, ohne dass eine Regel greift: veraltete Fassung, unbekannte Kennung oder gar keine E-Rechnung

22 / 53

offiziellen ZUGFeRD-Beispielen: KoSIT und der Prüfbericht, den FeRD mitliefert, urteilen verschieden

Warum es das gibt

Ein Beispiel wird kopiert, nicht geprüft. Wer es als Vorlage nimmt, übernimmt seine Fehler — und seine Fassung. Die KoSIT ändert das Regelwerk etwa zweimal im Jahr; ein Beispiel, das bei seiner Veröffentlichung gültig war, bleibt im Netz, wenn sich die Regeln ändern.

Die Frage ist deshalb nicht, ob ein Beispiel einmal gültig war, sondern ob es heute durchgeht — beim Empfänger, der mit dem aktuellen Regelwerk prüft.

Methode

Gesammelt am 19. Oktober 2026: die offizielle KoSIT-Testsuite als Kontrollgruppe, die aktuellen ZUGFeRD-Beispielrechnungen von FeRD (Fassung 2.5.2 vom 22. September 2026), die EN-16931-Beispiele des CEN, die Beispielordner früherer FeRD-Pakete (1.0 bis 2.4), wie sie öffentlich auf GitHub liegen, die Testdateien von Mustangproject und horstoeko und die Downloads von 12 Anbieter- und Ratgeberseiten. Nur frei herunterladbare Dateien; was hinter einem Formular liegt, ist nicht dabei.

Gezählt werden nur Dateien, die ihr Herausgeber als gültiges Beispiel anbietet — per Ordnername (correct, examples, Beispiele), README oder Text auf der Download-Seite. Absichtlich fehlerhafte Testdateien sind getrennt erfasst und in keiner Zahl unten enthalten. Dateien mit identischem Inhalt (gleicher SHA-256) zählen einmal.

Geprüft mit dem KoSIT-Validator 1.6.3 und der XRechnung-Konfiguration v2026-08-31, derselben, die der NormAPI-Validator verwendet; bei ZUGFeRD-PDFs die eingebettete XML-Datei. Jede Datei bekommt genau ein Urteil, und das Urteil sagt, warum. Eine Datei, die XRechnung 2.1 angibt, wird abgelehnt, ohne dass eine einzige Regel geprüft wurde — sie zählt deshalb nicht als „an den Regeln gescheitert“, sondern als veraltet.

Die offiziellen ZUGFeRD-Beispiele: zwei Prüfungen, zwei Urteile

FeRD liefert zu jeder Beispielrechnung der Fassung 2.5.2 einen Prüfbericht mit, erstellt mit Valitool (DWC und validool UG). Bei 31 der 53 Rechnungen kommt der KoSIT-Validator zum selben Urteil, bei 22 nicht.

19 EXTENDED-Rechnungen nennt FeRDs Bericht „GÜLTIGE eRechnung“; die KoSIT-Konfiguration empfiehlt, sie abzulehnen. Sie prüft EXTENDED gegen die Kernregeln der EN 16931, und EXTENDED erlaubt Elemente, die diese Regeln ausschließen — am häufigsten ein formatiertes Datum (CII-DT-027), das FeRDs Bericht nicht beanstandet. Ein Fehler in der Datei ist das nicht zwingend. Ein Empfänger, der mit der KoSIT-Konfiguration prüft, lehnt sie trotzdem ab.

3 Rechnungen nennt FeRDs Bericht „FEHLERHAFT“; der KoSIT-Validator nimmt sie an.

Die Frage des BDI, wessen Prüfergebnis maßgeblich ist, stellt sich also schon bei den offiziellen Beispielen. Für Absender folgt daraus: EXTENDED nur, wenn der Empfänger es ausdrücklich verarbeitet, und mit dessen Prüfung testen. ZUGFeRD EXTENDED oder XRechnung?

Die Regeln ändern sich, die Beispiele bleiben

23 Dateien scheitern an genau einer Regel: CII-SR-465, „nur ein Ansprechpartner des Verkäufers (BT-41)“. Die CEN-Regeln führen sie als Warnung; die KoSIT hat sie mit der Fassung v2026-08-31, veröffentlicht am 2. September 2026, zum Fehler hochgestuft. Betroffen sind vor allem die XRECHNUNG-Beispiele der FeRD-Pakete 2.3 bis 2.4.0 (2024–2025), wie sie auf GitHub liegen. Bei ihrer Veröffentlichung waren sie gültig. Das aktuelle FeRD-Paket 2.5.2 enthält keine XRECHNUNG-Beispiele mehr.

Ähnlich BR-CL-25: Mehrere EN-16931-Beispiele aus den FeRD-Paketen 2.0 bis 2.2 geben die elektronische Adresse mit dem Schema 9958 an, der früheren Kennung für die Leitweg-ID. Die aktuelle EAS-Codeliste führt sie nicht mehr; an ihre Stelle trat 0204.

55 Dateien geben eine Fassung an, die das aktuelle Regelwerk nicht mehr kennt: XRechnung 1.2 bis 2.3 (29) und ZUGFeRD 1.0 (26). Sie werden abgelehnt, ohne dass eine Regel geprüft wird — mit einer Meldung, die keine Regel nennt.

Die Beispiele zum Download auf Anbieter- und Ratgeberseiten

12 Seiten bieten zusammen 57 Beispieldateien an. 48 davon bestehen. Bei 4 Seiten besteht mindestens eine Datei nicht; was genau, steht unter der Tabelle.

getzugferd.com

Zwei Dateien sind MINIMUM und BASIC WL — von der Seite selbst als Buchungshilfe und nicht als vollständige Rechnung gekennzeichnet. Alle übrigen bestehen.

zugferd-minimum-beispiel.pdf — keine E-Rechnung (MINIMUM/BASIC WL)zugferd-basic-wl-beispiel.pdf — keine E-Rechnung (MINIMUM/BASIC WL)

hyreka.de

Das XRechnung-Beispiel wird abgelehnt: Die Käuferreferenz BT-10 fehlt (BR-DE-15), ebenso die elektronischen Adressen von Käufer und Verkäufer (PEPPOL-EN16931-R010, -R020). Das ZUGFeRD-Beispiel besteht.

XRechnung-Beispiel.xml — abgelehnt: Geschäftsregeln (BR-DE-15, PEPPOL-EN16931-R010, PEPPOL-EN16931-R020)

orgaMAX

Das XRechnung-Beispiel (UBL) und das ZUGFeRD-Beispiel (ein PDF mit XRechnung in CII) werden beide mit PEPPOL-EN16931-R008 abgelehnt: ein leeres Element. In der XML-Datei ist es die elektronische Adresse des Käufers, <cbc:EndpointID schemeID="EM"/>.

orgaMAX_Beispielrechnung_XRechnung.xml — abgelehnt: Geschäftsregeln (PEPPOL-EN16931-R008)orgaMAX_Beispielrechnung_ZUGFeRD.pdf — abgelehnt: Geschäftsregeln (PEPPOL-EN16931-R008)

PDFlib

Die Dateien stammen von 2019/2020. Das ZUGFeRD-1.0-Beispiel hat eine Fassung, die das Regelwerk nicht mehr kennt; das ZUGFeRD-2.0-Beispiel schreibt die Profilkennung mit „EN16931“ in Großbuchstaben, die die Prüfung nicht erkennt. Das Factur-X-Beispiel besteht.

zugferd1_invoice_pdfa3b.pdf — veraltete Fassungzugferd2_invoice_pdfa3b.pdf — unbekannte Profilkennung

solytics.de

Beide XRechnung-Beispiele geben als Kennung „urn:cen.eu:en16931:2017#compliant#urn:xoev-de:kosit:standard:xrechnung_3.0“ an: den Namensraum der Fassungen bis 2.x mit der Versionsnummer 3.0. Diese Kennung definiert keine Fassung; die Prüfung erkennt die Dateien nicht als XRechnung und lehnt sie ab, ohne eine Regel anzuwenden. Für 3.0 lautet sie „…#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0“.

xrechnung-beispiel-ubl.xml — unbekannte Profilkennungxrechnung-beispiel-cii.xml — unbekannte Profilkennung

Profile, die keine E-Rechnung sind

41 Beispieldateien sind ZUGFeRD MINIMUM oder BASIC WL. Das BMF nennt ZUGFeRD ab Version 2.0.1 als zulässiges Format, ausgenommen genau diese beiden Profile; sie tragen nur Grunddaten einer Rechnung. Die KoSIT-Konfiguration hat für sie kein Prüfszenario. Als Vorlage für eine Rechnung taugen sie nicht, als Beispiel für das Profil schon — wenn es so gekennzeichnet ist.

Alle Herausgeber

Eine Datei zählt je Herausgeber einmal. Bietet derselbe Herausgeber eine Datei mehrfach an (etwa als deutsche und englische Fassung eines Pakets), zählt sie einmal.

Von den Ablehnungen nach Prüfung entfallen 94 auf EXTENDED, wo die KoSIT-Konfiguration nicht das einzige maßgebliche Werkzeug ist (siehe oben).

Die häufigsten Gründe außerhalb von EXTENDED

Außerhalb von EXTENDED wurden 541 Dateien gegen ein aktuelles Szenario geprüft; 39 davon wurden abgelehnt. Diese Regeln standen am häufigsten im Bericht (Anzahl der Dateien):

• CII-SR-465 · 24
• BR-CL-25 · 10
• PEPPOL-EN16931-R008 · 2
• CII-DT-024 · 1
• BR-CL-11 · 1
• BR-TMP-2 · 1
• CII-SR-466 · 1
• BR-DE-15 · 1
• PEPPOL-EN16931-R010 · 1
• PEPPOL-EN16931-R020 · 1

Welche Beispiele Sie nehmen können

• Für XRechnung: die KoSIT-Testsuite. Alle 86 Dateien bestehen; sie ist die Referenz, gegen die das Regelwerk selbst getestet wird, und erscheint mit jeder neuen Fassung.
• Für ZUGFeRD: die BASIC- und EN-16931-Beispiele aus FeRDs aktuellem Paket 2.5.2. Alle 28 bestehen beim KoSIT-Validator.
• Von einer Website: nur mit dem Datum der Prüfung. Die Seiten, deren Dateien hier alle bestanden haben, stehen in der Tabelle oben — Stand 19. Oktober 2026.

Was daraus folgt, wenn Sie E-Rechnungen erzeugen

1. Ein Beispiel ist eine Momentaufnahme. Prüfen Sie Ihre Vorlagen und Testdateien nach jeder neuen KoSIT-Fassung erneut — CII-SR-465 hat am 2. September Beispiele ungültig gemacht, die bis dahin bestanden.
2. Zuerst die Profilkennung. Eine veraltete oder falsch geschriebene Kennung führt zur Ablehnung ohne eine einzige Regelmeldung; das ist der Fehler, den man im Bericht am leichtesten übersieht.
3. EXTENDED nur in Absprache mit dem Empfänger und mit dessen Prüfwerkzeug getestet.
4. MINIMUM und BASIC WL sind keine Vorlage für eine Rechnung.

Die Daten

Jede Datei als eine Zeile: Herausgeber, Adresse der Datei, SHA-256, angegebenes Profil, Prüfszenario, Urteil und Regelcodes — auch die absichtlich fehlerhaften und die unklaren Dateien, die in den Zahlen oben nicht enthalten sind. Mit der Adresse und der Prüfsumme lässt sich jede Zeile nachprüfen. Unter CC BY 4.0.

So zitieren Sie diese Messung

NormAPI (2026). Beispielrechnungen im Test: 810 XRechnung- und ZUGFeRD-Muster gegen das aktuelle Regelwerk. https://normapi.de/studie/beispielrechnungen

Eine Momentaufnahme eines Tages. Erscheint eine neue KoSIT-Fassung, wiederholen wir den Lauf und schreiben das Datum hier fort. Eine Korrektur wird als solche vermerkt.

Was diese Messung nicht zeigt

• Ein Stand vom 19. Oktober 2026. Seiten und Pakete werden aktualisiert; ein Befund von heute kann morgen überholt sein.
• Geprüft wurde, was frei herunterladbar war. Das FeRD-Infopaket und die Factur-X-Pakete der FNFE liegen hinter einem Formular und sind nicht dabei; die Beispielordner älterer FeRD-Pakete stammen aus einer öffentlichen Kopie auf GitHub.
• Ein Prüfwerkzeug: die offizielle KoSIT-Konfiguration. Für EXTENDED ist sie nicht das einzige maßgebliche Werkzeug — siehe oben.
• Peppol-BIS-Dateien liegen außerhalb der XRechnung-Konfiguration und sind nicht beurteilt.
• Testdateien von Bibliotheken zählen nur, wenn die Bibliothek sie selbst als gültig ausweist. Das ist eine schwächere Aussage als ein veröffentlichtes Beispiel.
• Korrekturen sind willkommen. Ist eine Angabe falsch, schreiben Sie uns — sie wird mit Datum korrigiert.