We tested our validator against 114 real invoices and published where it was wrong

Anyone can claim their e-invoice checker is accurate. We ran ours against every file in the public ZUGFeRD corpus, a collection of real and sample invoices produced by independent tools, and published the result. It found two defects. Both were ours.

What we tested

The ZUGFeRD corpus is a public collection of Factur-X and ZUGFeRD invoices produced by independent implementations, split by its maintainers into files that should validate and files that should not. We took all 114 files in the ZUGFeRD 2.x set, ran each one through the same checker this site runs, and compared our verdict against theirs.

We counted only scored rules, meaning the mandatory and arithmetic rules. Warnings are shown in a report but never move the score, so that a valid French or Italian invoice is not marked down for missing a German-only field.

Where we agree: every profile that carries invoice lines, 100%

Of the 91 files the corpus says should validate, we now agree on all 91, with a minimum score of 100.

ZUGFeRD profile	Files	We agree	Carries invoice lines
EN16931	46	46 (100%)	yes
EXTENDED	10	10 (100%)	yes
BASIC	7	7 (100%)	yes
MINIMUM	6	6 (100%)	no, by design
BASIC WL	5	5 (100%)	no, by design
Unstated	17	17 (100%)	yes

Measured 2026-09-20 against the ZUGFeRD 2.x set. Rerun it yourself with the steps below.

What the test found, and it was us

Before this exercise we agreed on 76 of the 91. The 15 disagreements were not defects in anyone else's files. Every one of them was a defect in our own checker, and the corpus is what exposed them.

1. We failed correct invoices that carried a document-level charge

All four EXTENDED invoices failed the rule BR-CO-13, which requires that the invoice total without VAT equals the line total, minus document allowances, plus document charges. Their arithmetic was right. One of them states:

Field	Value in the file
Line total (BT-106)	457.20
Allowances (BT-107)	11.21
Charges (BT-108)	3.00
Total without VAT (BT-109)	448.99

457.20 minus 11.21 plus 3.00 is 448.99, exactly what the file says. We read the charge only by adding up individual allowance and charge entries, and this invoice carries its charge solely as a document total, so we computed 445.99 and told a correct invoice it was wrong. We now read both figures where the standard states them outright.

A false positive is the worst failure a validator has. It is worse than missing a defect, because it sends someone hunting a problem that does not exist in their own file, and they have no way to tell our bug from their error.

2. We scored MINIMUM and BASIC WL as though they were full invoices

MINIMUM and BASIC WL carry no invoice lines. That is what the profiles are for: they are booking aids and payment references, not complete invoices. We reported the missing lines as failures, so a perfectly valid MINIMUM file came back at 79 out of 100 with the advice to add an invoice line, which is wrong advice for that profile.

We now read the profile from the document, mark the line-dependent rules as not applicable, and say so in plain words: this file carries no invoice lines by design, and it is not a full EN16931 invoice.

What this checker does not do

The corpus also contains 23 files that are supposed to fail. We pass 22 of them, and that is the honest limit of this tool rather than a hidden strength.

Those files fail against the full ZUGFeRD specification, which covers the PDF container as well as the invoice data: PDF/A-3 conformance, XMP metadata, how the XML attachment is named and embedded. We check the invoice content against around forty of the highest-value EN16931 business rules. We do not check the container, and a green score here is not a statement that your PDF is a conformant ZUGFeRD file.

If you need full specification conformance, use a validator built for that. If you need to know whether the invoice data itself will be accepted or rejected on the receiving side, that is what this does.

Nobody else's file was broken

It is worth saying plainly, because the opposite would have been the more flattering result. Not one file in this corpus turned out to be defective because of the tool that produced it. Every disagreement traced back to our code. The implementations represented here got it right and our checker did not, until we fixed it.

Reproduce it

1. Clone the corpus: git clone --depth 1 https://github.com/ZUGFeRD/corpus.git
2. Take every PDF and XML under ZUGFeRDv2/correct and ZUGFeRDv2/fail.
3. Run each one through the validator on this site and compare the scored rules against the folder it came from.

If you find a case where we disagree with the corpus and we are the one that is wrong, that is a bug worth reporting, and this page exists so you can check rather than take our word for it.

Why publish the mistakes rather than the score?

Because the score alone is not checkable. Every validator claims to be accurate. The useful thing to publish is the method, the file set, and the cases where the tool was wrong, so that somebody can repeat the test and reach their own verdict.

Does a green score here mean my invoice is legally compliant?

No. It means the invoice data satisfies the format and arithmetic rules we check. It does not decide your tax obligations or whether you are using the right channel for your country, and it is not legal advice.

How often is this rerun?

It is rerun when the rule set changes. The date under the results table is the last measurement, and the steps above let you rerun it at any time.