The checker above validates one e-invoice file against the rules of the country you choose. It runs the XML schema and the Schematron business rules that apply there, reports every finding with its rule identifier, and then forgets the file. It needs no account, keeps nothing, and accepts files up to 25 MB.
Which formats it validates
The checker recognises the file by its content, not its extension: a PDF is treated as a hybrid and its embedded XML extracted; an XML file is identified as UBL or CII by its namespace. The country you select picks the rule set.
| Country selected | Accepted files | Rules applied |
|---|---|---|
| Germany | XRechnung (UBL or CII), ZUGFeRD / Factur-X PDF, plain EN 16931 UBL or CII | EN 16931 schema and Schematron; XRechnung CIUS rules; Factur-X profile rules for ZUGFeRD; PDF/A-3 conformance for PDFs. The KoSIT validator is run for XRechnung documents. |
| France | Factur-X PDF, bare CII | EN 16931 CII rules and the Factur-X profile; PDF/A-3 conformance for PDFs |
| Belgium | UBL invoice or credit note | Peppol BIS Billing 3.0 rules (the OpenPeppol Schematron) on top of EN 16931 |
| Poland | FA(3) XML | FA(3) schema validation. FA(3) is not an EN 16931 document, so no EN 16931 rules are applied. |
The country is mandatory, because a Belgian invoice checked against German rules gives a confident answer that is confidently wrong. If unsure, choose the country of the recipient.
What "valid" means here
Valid means the file passed two layers: the XML schema of its syntax, and the Schematron business rules of the chosen rule set. Schema says every element is where the syntax allows it. Schematron says the content is coherent: totals add up, mandatory business terms are present, code lists are respected, and country-specific CIUS rules hold.
The rule sets are the published ones. For XRechnung the checker runs the KoSIT validator, an engine that "has no own validation rules" and takes them from published scenarios; for the other formats it runs the published Schematron of EN 16931, Factur-X or Peppol BIS in-process. Each finding names its rule (for example BR-CO-15), so you can look it up in the standard.
What it cannot tell you
A pass means the file is technically correct. It does not mean a specific recipient will accept it: a public-sector portal, a Peppol receiver or a French platform may apply rules of its own. Nor does it say the invoice is complete under national VAT law or that the tax treatment is right; that requires professional confirmation. The checker validates one file and sends, registers or looks up nothing.
Privacy, size and rate limits
The file is validated in memory and discarded. No file, digest or database row is written. The size limit is 25 MB, checked before a byte is parsed; a real e-invoice is a few hundred kilobytes.
Because the checker is public and each run costs seconds of CPU, it is rate-limited per client address: a burst of five checks, then one per minute. Over the limit you receive HTTP 429 with a Retry-After header. Invoices issued through KRONENWERK, including drafts created over the e-invoicing API, are validated at issuance without this limit.
Common errors and what they mean
| Finding | Usual cause | Fix |
|---|---|---|
| Schema error at the root element | UBL checked as CII or the reverse; a plain PDF without embedded XML | Check the file really is an e-invoice; a PDF with no XML attachment is not one. |
BR-CO-10 to BR-CO-15 | Line totals, tax totals and the amount due do not add up | Recalculate in the issuing system; rounding per line is the usual culprit. |
BR-S-08, BR-AE-*, BR-E-* | VAT breakdown missing or inconsistent with the category used on the lines (standard, reverse charge, exempt) | Every VAT category used on a line needs a matching breakdown with rate and exemption reason where required. |
| PDF/A-3 conformance failure | ZUGFeRD or Factur-X PDF that was re-saved or printed, losing its PDF/A structure | Regenerate from the issuing software; never edit the PDF afterwards. |
How KRONENWERK handles this
SUPPORTED The checker is the validation stack KRONENWERK runs on its own invoices: every XRechnung, ZUGFeRD, Factur-X, Peppol BIS or FA(3) document is validated before it can be issued, and incoming XRechnung, ZUGFeRD/Factur-X and UBL files are validated and read into bills in Expenses. The free checker exposes that receiving side without an account or storage. See the format pages for XRechnung, ZUGFeRD, Factur-X and FA(3), and receiving e-invoices in Germany.
Frequently asked questions
Is the file uploaded somewhere and kept?
It is sent to the checker, validated in memory and discarded. No copy, digest or record is stored.
Why do I have to choose a country?
Because the business rules differ: Germany, France, Belgium and Poland each apply their own rule set on top of, or instead of, EN 16931. A wrong country gives a wrong verdict.
My supplier's invoice fails. Do I still have to book it?
An invoice that arrived is still an invoice that arrived. Book it, keep it, and ask the supplier for a corrected one; whether the defects affect your input VAT deduction requires professional confirmation.