Sample e-invoices put to the test: 810 XRechnung and ZUGFeRD files against the current rules

At a glance

810

distinct files their publisher offers as a valid sample

548

pass the current rule set

102

are rejected without any rule applying: an outdated version, an unknown identifier, or not an e-invoice at all

22 / 53

official ZUGFeRD samples: KoSIT and the validation report FeRD ships with them reach different verdicts

Why this exists

A sample gets copied, not checked. Whoever uses it as a template inherits its mistakes — and its version. KoSIT changes the rule set about twice a year; a sample that was valid when published stays online when the rules move.

So the question is not whether a sample was once valid, but whether it passes today — at a recipient who validates with the current rule set.

Method

Collected on 19 October 2026: the official KoSIT test suite as the control group, FeRD's current ZUGFeRD sample invoices (release 2.5.2 of 22 September 2026), CEN's EN 16931 examples, the sample folders of earlier FeRD packages (1.0 to 2.4) as they sit publicly on GitHub, the test files of Mustangproject and horstoeko, and the downloads offered on 12 vendor and guide sites. Freely downloadable files only; anything behind a form is not included.

Only files their publisher offers as a valid sample are counted — by folder name (correct, examples, Beispiele), README, or the wording on the download page. Deliberately broken test files are recorded separately and appear in none of the numbers below. Files with identical content (same SHA-256) count once.

Checked with KoSIT validator 1.6.3 and the XRechnung configuration v2026-08-31, the same one NormAPI's validator uses; for ZUGFeRD PDFs, the embedded XML. Every file gets exactly one verdict, and the verdict says why. A file declaring XRechnung 2.1 is rejected without a single rule being checked — so it counts as outdated, not as "failed the rules".

The official ZUGFeRD samples: two checks, two verdicts

FeRD ships a validation report with every sample invoice of release 2.5.2, produced with Valitool (DWC and validool UG). On 31 of the 53 invoices the KoSIT validator reaches the same verdict; on 22 it does not.

FeRD's report calls 19 EXTENDED invoices "GÜLTIGE eRechnung" (a valid e-invoice); the KoSIT configuration recommends rejecting them. It checks EXTENDED against the EN 16931 core rules, and EXTENDED permits elements those rules exclude — most often a formatted date (CII-DT-027), which FeRD's report does not object to. That is not necessarily a defect in the file. A recipient that validates with the KoSIT configuration rejects it all the same.

FeRD's report calls 3 invoices "FEHLERHAFT" (faulty); the KoSIT validator accepts them.

So the BDI's question — whose validation result is the authoritative one — already arises with the official samples. For senders: use EXTENDED only when the recipient explicitly processes it, and test with the recipient's check. ZUGFeRD EXTENDED or XRechnung?

The rules move, the samples stay

23 files fail exactly one rule: CII-SR-465, "only one seller contact point (BT-41)". The CEN rules flag it as a warning; KoSIT raised it to an error in release v2026-08-31, published on 2 September 2026. Mostly affected are the XRECHNUNG samples of FeRD packages 2.3 to 2.4.0 (2024–2025), as they sit on GitHub. They were valid when published. FeRD's current package 2.5.2 no longer contains XRECHNUNG samples.

Similarly BR-CL-25: several EN 16931 samples from FeRD packages 2.0 to 2.2 give the electronic address with scheme 9958, the former identifier for the Leitweg-ID. The current EAS code list no longer carries it; 0204 replaced it.

55 files declare a version the current rule set no longer knows: XRechnung 1.2 to 2.3 (29) and ZUGFeRD 1.0 (26). They are rejected without any rule being checked — with a message that names no rule.

The samples offered for download on vendor and guide sites

12 sites offer 57 sample files between them. 48 of those pass. On 4 sites at least one file does not; what exactly is listed below the table.

getzugferd.com

Two files are MINIMUM and BASIC WL — labelled by the page itself as a booking aid, not a complete invoice. All the others pass.

zugferd-minimum-beispiel.pdf — not an e-invoice (MINIMUM/BASIC WL)zugferd-basic-wl-beispiel.pdf — not an e-invoice (MINIMUM/BASIC WL)

hyreka.de

The XRechnung sample is rejected: the buyer reference BT-10 is missing (BR-DE-15), and so are the buyer's and seller's electronic addresses (PEPPOL-EN16931-R010, -R020). The ZUGFeRD sample passes.

XRechnung-Beispiel.xml — rejected: business rules (BR-DE-15, PEPPOL-EN16931-R010, PEPPOL-EN16931-R020)

orgaMAX

The XRechnung sample (UBL) and the ZUGFeRD sample (a PDF carrying XRechnung in CII) are both rejected with PEPPOL-EN16931-R008: an empty element. In the XML file it is the buyer's electronic address, <cbc:EndpointID schemeID="EM"/>.

orgaMAX_Beispielrechnung_XRechnung.xml — rejected: business rules (PEPPOL-EN16931-R008)orgaMAX_Beispielrechnung_ZUGFeRD.pdf — rejected: business rules (PEPPOL-EN16931-R008)

PDFlib

The files date from 2019/2020. The ZUGFeRD 1.0 sample is a version the rule set no longer carries; the ZUGFeRD 2.0 sample spells its profile identifier with "EN16931" in capitals, which the check does not recognise. The Factur-X sample passes.

zugferd1_invoice_pdfa3b.pdf — outdated versionzugferd2_invoice_pdfa3b.pdf — unknown profile identifier

solytics.de

Both XRechnung samples declare "urn:cen.eu:en16931:2017#compliant#urn:xoev-de:kosit:standard:xrechnung_3.0": the namespace of versions up to 2.x with the version number 3.0. No version defines that identifier, so the check does not recognise the files as XRechnung and rejects them without applying a rule. For 3.0 it reads "…#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0".

xrechnung-beispiel-ubl.xml — unknown profile identifierxrechnung-beispiel-cii.xml — unknown profile identifier

Profiles that are not e-invoices

41 sample files are ZUGFeRD MINIMUM or BASIC WL. The German Federal Ministry of Finance lists ZUGFeRD from version 2.0.1 as a permitted format, excluding exactly these two profiles; they carry only an invoice's basic data. The KoSIT configuration has no scenario for them. They are no template for an invoice, though they are a fair example of the profile — when labelled as such.

Every publisher

A file counts once per publisher. Where the same publisher offers a file more than once (as the German and English edition of a package, say), it counts once.

Of the rejections after checking, 94 are EXTENDED, where the KoSIT configuration is not the only authoritative tool (see above).

The most frequent reasons outside EXTENDED

Outside EXTENDED, 541 files were checked against a current scenario; 39 of them were rejected. These rules appeared most often in the reports (number of files):

• 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

Which samples you can use

• For XRechnung: the KoSIT test suite. All 86 files pass; it is the reference the rule set itself is tested against, and it is republished with every release.
• For ZUGFeRD: the BASIC and EN 16931 samples from FeRD's current package 2.5.2. All 28 pass the KoSIT validator.
• From a website: only with the date it was checked. The sites whose files all passed here are in the table above — as of 19 October 2026.

What follows if you generate e-invoices

1. A sample is a snapshot. Re-check your templates and test files after every new KoSIT release — CII-SR-465 invalidated samples on 2 September that had passed until then.
2. Check the profile identifier first. An outdated or misspelt identifier is rejected without a single rule message; it is the failure easiest to overlook in a report.
3. EXTENDED only by agreement with the recipient, and tested with the recipient's tool.
4. MINIMUM and BASIC WL are no template for an invoice.

The data

Every file as one row: publisher, file URL, SHA-256, declared profile, scenario, verdict and rule codes — including the deliberately broken and the unclear files, which the numbers above leave out. With the URL and the checksum every row can be re-checked. Under CC BY 4.0.

How to cite this measurement

NormAPI (2026). Sample e-invoices put to the test: 810 XRechnung and ZUGFeRD files against the current rules. https://normapi.com/en/study/sample-invoices

A snapshot of one day. When a new KoSIT release appears we repeat the run and carry the date here forward. A correction is recorded as one.

What this measurement does not show

• A snapshot as of 19 October 2026. Sites and packages get updated; a finding from today may be out of date tomorrow.
• What was freely downloadable was checked. The FeRD Infopaket and FNFE's Factur-X packages sit behind a form and are not included; the sample folders of older FeRD packages come from a public copy on GitHub.
• One checking tool: the official KoSIT configuration. For EXTENDED it is not the only authoritative tool — see above.
• Peppol BIS files fall outside the XRechnung configuration and are not judged.
• Library test files count only where the library itself declares them valid. That is a weaker statement than a published sample.
• Corrections are welcome. If something here is wrong, write to us — it will be corrected with a date.