ZUGFeRD and XRechnung validator: check e-invoices online
Upload an e-invoice (ZUGFeRD or Factur-X PDF, XRechnung XML) and have it validated against EN 16931 for free. We also check what other validators ignore: whether the bank details have been manipulated.
What is checked
Formal validity (KoSIT)
The invoice runs through the official KoSIT validator (KoSIT is Germany's Coordination Office for IT Standards), the same tool the German public administration uses. It is checked against EN 16931 and the German XRechnung rules (BR-DE). You get the violated rules in plain language, not just a red cross.
What you see versus what machines read
A ZUGFeRD PDF has two layers: what you see and what your accounting software imports. We compare both. If the IBAN printed in the PDF differs from the embedded XML, that is a red flag that pure format validators do not even look for.
Plausibility of the payment details
Is the IBAN valid according to its check digits at all? Does the IBAN country match the issuer's registered location? This is exactly where payment diversion fraud strikes: an otherwise genuine invoice where only the bank details have been swapped.
Which formats are checked
- ZUGFeRD (2.x and later) and Factur-X: PDF/A-3 with embedded XML. Upload the PDF and we extract the XML ourselves. More about the ZUGFeRD validator
- XRechnung: a pure XML file, the mandatory format for invoices to German public-sector clients. More about the XRechnung validator
- EN 16931 in general, in both the CII and UBL syntax.
- An ordinary PDF without embedded XML is not an e-invoice. We tell you that clearly, too. What makes an e-invoice
Got an error message?
The KoSIT validator responds with rule identifiers such as BR-DE-15 or BR-CO-25. What they mean in plain language and how to fix them is explained in our reference of all EN 16931 and XRechnung rules.
With a free account we check even more
- Bank change detection: an alert when a known supplier suddenly bills with a different IBAN.
- IBAN vault: approve or block bank details per supplier, optionally with four-eyes approval.
- Mailbox automation: incoming invoices are checked automatically before anyone pays.
- Duplicate check & check history: spot duplicate invoices and look up past results.
Frequently asked questions about e-invoice validation
Is the ZUGFeRD validator really free?
Yes. Three checks per day are free. You do not need an account, just your email address, which we use to show you the result. With a free account the quota increases, and you also get bank change detection, the IBAN vault and a check history.
Which validator do you use in the background?
The official KoSIT validator, the same tool provided by the Koordinierungsstelle für IT-Standards (KoSIT, Germany's Coordination Office for IT Standards) and used by the German public administration for incoming invoices. We check against EN 16931 and the German XRechnung rules.
What is the difference between ZUGFeRD and XRechnung?
XRechnung is a pure XML file and the mandatory format for invoices to public-sector clients in Germany. ZUGFeRD (and its French counterpart Factur-X) is a PDF/A-3 that carries the same structured data as embedded XML, so it is readable by people and machines at the same time. Both comply with EN 16931, and our validator accepts both.
Is my invoice stored?
No. With the free check without an account, the file is processed only for the check and discarded afterwards; it is not stored permanently. Processing takes place on servers in Germany.
Why does the check say "not an e-invoice" when it is one?
Usually it is a copy rather than the original. If a ZUGFeRD PDF is opened in a viewer and saved again, printed ("Save as PDF") or scanned, it looks unchanged but loses all attachments and with them the embedded XML. Use the original file exactly as you received it.
What do errors like BR-DE-15 or BR-CO-25 mean?
They are identifiers of the business rules from EN 16931 and the German XRechnung standard respectively. BR-DE-15, for example, requires the Leitweg-ID (the routing ID of German public-sector recipients, Buyer reference, BT-10). You will find all rules with their official text in our error code reference.
Does the check also detect forged invoices?
It detects the most common manipulation of genuine-looking invoices: swapped bank details. To do this, we compare the IBAN visible in the PDF with the embedded data, verify the check digits and match the IBAN country against the issuer's location. This is no guarantee that the content is genuine, but it is exactly the comparison that pure format validators lack.
Is the check also available as an API?
Yes, via POST /v1/check, for example to check every incoming invoice automatically before it is booked. Details are in the documentation.