UBL Validator
UBL 2.1 · EN 16931Validate a UBL 2.1 invoice against the OASIS XML Schema and the EN 16931 business rules, and get the official rule identifier and document location for every problem found.
Your document never leaves your device — the file is read and parsed in this browser tab.
Drop an XML document here, or choose a file
Read in your browser. Never uploaded. Up to 12.0 MB.
What this validator checks
Validating an electronic invoice is not one question but several, and collapsing them into a single verdict hides the only information that helps you fix a document. This tool reports each layer separately.
- File — the bytes are well-formed XML and passed the security screen. A document carrying a DOCTYPE is refused before parsing.
- Syntax — the root element's namespace URI identifies the document as UBL 2.1. The prefixes it uses are irrelevant.
- XML Schema — the OASIS UBL 2.1 schema set. This checks structure and datatypes: whether elements exist, appear in the order the schema requires, and hold values of the right type.
- EN 16931 business rules — the ConnectingEurope validation artefacts 1.3.16. This checks meaning: whether the totals add up, whether the terms a VAT category requires are present, whether codes come from the required lists.
Structural and semantic validation are different things
XML Schema cannot express "the sum of the line net amounts must equal the line total" — it describes shape, not arithmetic. That is why a document can be entirely schema-valid and still fail rules like BR-CO-10 or BR-CO-15. Those live in the business rule layer, which is executed separately.
The dependency runs one way. If a document is not schema-valid, the business rules are skipped, not failed: those rules navigate structures the schema guarantees, so running them over a broken document produces noise rather than information. The rules layer says "skipped"; the schema failure makes the overall verdict "invalid".
Official rules, unmodified
No EN 16931 rule is reimplemented here. The published stylesheet is executed as published by a conformant XSLT 3.0 processor, which is why every finding carries the standard's own identifier — BR-* for presence and cardinality, BR-CO-* for conditions and calculations, BR-CL-* for code lists, and the UBL-specific UBL-SR-* and UBL-CR-* families — together with the artefact's own message text.
Running the rules under a conformant processor is what makes the arithmetic trustworthy. The rules compare exact decimal values, and an engine that treats them as binary floating-point numbers gets sums like 0.1 + 0.2 wrong and cannot tell apart two totals that differ in the sixteenth digit. Those are amounts a real invoice can carry.
The artefact versions are pinned and checksummed in this project. A validator that quietly pulls the newest rules gives different answers on different days for the same file; the exact versions used are shown under Technical details with every report.
This site is not an official EU service and is not affiliated with OASIS, CEN or ConnectingEurope. It runs the official artefacts and tells you which version it used.
Why CII is not validated here
The EN 16931 1.3.16 release binds the standard to UBL 2.1 and, separately, to UN/CEFACT CII D16B. The French Factur-X baseline targets CII D22B. Those are different syntax releases and their rule packages are not interchangeable.
A CII document does not record which release it follows — every release publishes under the same namespace URI — so there is no safe way to choose a package by inspecting the file. Opening a CII document here identifies it and shows its content, and reports both validation layers as unsupported. Read more on the CII reference page, or open the document in the CII viewer.
CII can be validated on this site — just not by guessing. The France e-invoice validator asks you to choose a validation target, and the D22B rules run because that target requires D22B — not because the file proved anything about its release. Inside a Factur-X PDF the container narrows the choice, which is why the Factur-X validator usually needs no question asked.
Your invoice stays on your device
The file is read by your browser and validated in a background thread inside this page. The schema and rule files are downloaded from this site — they are our own static assets — but your invoice is never transmitted. You can confirm this in your browser's network panel: validating produces requests for the rule files and nothing else.
Related
To read a document rather than validate it, use the UBL viewer. For the structure behind these elements see UBL 2.1 for invoicing, and for the semantic model and its rule families see EN 16931.
Frequently asked questions
Is my invoice uploaded anywhere?
No. The file is read by your browser and validated in a background thread inside this page. The schema and rule files are downloaded from this site, but your invoice is never sent anywhere. Open your browser’s network panel while validating and you will see requests only for those rule files.
What is the difference between schema and EN 16931 validation?
Schema validation checks structure: whether the elements exist, are in the right order and hold the right datatypes. EN 16931 validation checks meaning: whether the totals add up, whether required business terms are present for the VAT category used, whether codes come from the right lists. A document can be perfectly schema-valid and still fail a dozen business rules, which is why the two are reported separately.
Which rules does this run?
The OASIS UBL 2.1 XML Schema, and the ConnectingEurope EN 16931 validation artefacts version 1.3.16. Both are pinned in this repository with their checksums, so the same document always produces the same result. The exact versions are shown under Technical details with every report.
Is this an official validator?
No. This site is not an official EU service and is not affiliated with OASIS, CEN or ConnectingEurope. It executes the official, published validation artefacts unmodified, and names the version it used — but the result is not a certification.
Why does it not validate CII or Factur-X documents?
The EN 16931 1.3.16 CII rules are written for UN/CEFACT D16B, while the French Factur-X baseline is D22B. A CII document does not record which release it follows — every release uses the same namespace — so applying the D16B rules could produce confident but wrong results. Rather than guess, this validator reports CII as unsupported.
What happens if the document is not schema-valid?
The business rules are skipped rather than run, and the report says so. Those rules assume the structure the schema guarantees, so running them over a broken document would produce misleading noise. Fix the schema errors first, then revalidate.