Validation

The best thing about this standard is that “is this invoice correct?” has an answer, and the answer is not a person’s opinion. The rules are published, executable, and the same ones everybody else runs.

Validation happens in three passes, always in the same order.

The three layers

The UBL 2.1 schema comes first. It checks shape: are the elements present, in the right order, with values of the right type. It knows nothing about business meaning. An invoice claiming to be for minus four thousand widgets passes the schema happily.

EN 16931 comes second. These are the European semantic rules: the totals reconcile, the VAT breakdown matches the lines, the terms a document cannot go without are there.

Peppol BIS Billing 3.0 comes last, adding what the profile requires on top, including the national rules that apply once a buyer or seller is in a particular country.

The order is not presentation. A document that fails the schema has not been meaningfully checked against the business rules at all, because the rules are assertions about a document that parsed. A validator that runs every layer regardless and hands you two hundred findings has told you almost nothing. A layer that could not run should say skipped, never passed, and if a tool blurs that distinction, it is a tool that will eventually tell you a broken document is fine.

What eleven hundred rules actually are

Release 3.0.21 carries 1,103 rules. The number sounds alarming until you look at the shape of it: 954 belong to the EN 16931 layer and 149 to the Peppol layer.

Of those, 678 are UBL-CR rules, which are restrictions. They say a given UBL element must not be used in this profile. If you generate your XML from the profile rather than from the whole of UBL, you will never trip one. Another 54 are BR rules, the content requirements, 23 are BR-CL code list checks, 22 are BR-CO calculations and 21 are BR-DEC rounding checks. Those four groups are where real invoices actually fail.

Then there is severity. 382 rules are fatal and 721 are warnings. A warning does not make the document invalid and the network will carry it regardless, but a receiver may still reject it for their own reasons, and warnings are frequently the first sign that a mapping is not quite right. Treat them as you would a compiler warning: not a build failure, not something to ignore for a year.

National rules, and the UK’s absence

The Peppol layer includes rules that apply based on where the parties are. Release 3.0.21 has 29 German rules, and others for Denmark, Greece, Iceland, Italy, the Netherlands, Norway and Sweden. Send a German buyer an invoice and you inherit the German set, which wants things like a contact email and a structured payment-terms note.

There are no UK rules. Not one.

That is worth sitting with, because it is the single biggest open question for anyone building here. When the roadmap arrives at the Budget on 28 October 2026, one of the things it should settle is whether the UK publishes its own profile, a set of national rules inside Peppol, or adopts what already exists. Until then, a UK invoice is validated against the common rules and nothing more, and any tool promising “UK compliance” today is promising something nobody has specified.

What a finding should tell you

A validator’s output is where this either becomes useful or stays frustrating. The minimum worth accepting:

• The rule id, so it can be looked up, quoted and searched.
• The official rule text, verbatim. Somebody in finance will eventually ask where a requirement comes from, and the answer needs to be the published text rather than a paraphrase.
• Where it failed, as a location in the document.
• The business terms involved, so it maps back to your own model rather than to XPath.

What the published rules do not give you is what to do about it. The text of BR-CO-15 tells you the totals must reconcile; it does not tell you that you are probably rounding per line where the standard rounds per VAT category. That gap is why every rule on this site has its own page, and why the API returns a plain-English explanation and a fix alongside the official text.

Releases, and testing the next one

OpenPeppol publishes a release each May and each November. Each becomes mandatory roughly three months later, which gives you a window to find out what changed before it starts rejecting documents. Release 3.0.21 has been mandatory since 17 August 2026.

Two consequences for your code.

The first is that “valid” has a date attached. A document that passed in April can fail in September without anyone touching your code, because the rule set moved underneath it. Pin the ruleset in your tests so that a change in the rules shows up as a deliberate upgrade rather than a mysterious failure.

The second is that you can test the future. While an upcoming release is published but not yet mandatory, you can validate against it and see what breaks, which turns a compliance deadline into a normal piece of maintenance. GET /v1/rulesets lists which releases are available and which is current, and the ruleset parameter pins a validation to one of them.

Put it in the build

The practical shape is unglamorous. Keep a fixture per awkward case: zero rated, reverse charge, a credit note, a line with a discount, a foreign buyer. Validate each one in your test suite. Fail the build when a document that used to pass stops passing.

That is worth more than any amount of reading about the standard, because it turns the rules into something your code has an opinion about. It also means that when the UK publishes its own rules, finding out what they cost you is one changed parameter and one test run.

The mechanics of calling a validator are in the developer docs. What comes next in the guide is the part this whole chapter has been assuming: that a document which passes still has to get to somebody, which is sending and receiving.