EN 16931, UBL and PINT: how the layers actually fit together

Ask five people on an e-invoicing project what "the standard" is and you will get five answers: EN 16931, UBL, PINT, Peppol BIS, or whatever the tax authority published last month. All five are real, and all five are different kinds of thing. Nearly every stalled integration we are called into traces back to two of these layers being treated as one.

Here is the stack we draw on the whiteboard in the first hour of every engagement, and what each layer does — and does not — decide for you.

The four layers

An electronic invoice has to answer four separate questions before anyone can process it. Each layer answers exactly one of them:

Layer 1 — the semantic model

EN 16931 is the European standard that defines the meaning of an invoice: a list of business terms (BT-1 invoice number, BT-2 issue date, BT-31 seller VAT identifier) grouped into business groups (BG-4 seller, BG-25 invoice line), with cardinalities and a set of business rules — the familiar BR-, BR-CO- and BR-*-* VAT rules.

Crucially, the semantic model contains no XML. It never tells you where the seller VAT number goes in a file; it tells you that an invoice must carry one, under what conditions, and how it relates to the VAT breakdown. That separation is deliberate, and it is why the same semantic model can be expressed in more than one syntax.

Layer 2 — the syntax

A syntax is a concrete XML vocabulary that carries the semantic model. EN 16931 recognises two: UBL (OASIS Universal Business Language) and UN/CEFACT CII (Cross Industry Invoice). Each has a published syntax binding — the mapping table saying which XPath expresses which business term.

Two syntaxes carrying one model is the source of a lot of avoidable pain, because the mapping is not one-to-one in either direction:

• Some business terms land in structurally different places — CII's nesting of document-level allowances and charges does not mirror UBL's flat repetition.
• Some syntax elements have no business term at all. They are legal in the schema, invisible to the semantic model, and therefore silently dropped by any converter that is written strictly to the binding.
• Hybrid formats such as Factur-X / ZUGFeRD embed a CII file inside a PDF/A-3 container, which adds a third artefact — the human-readable rendering — that must agree with the XML.

A conversion is only "lossless" with respect to a stated model. Ask which model, and the argument usually resolves itself.

Layer 3 — CIUS and extension

A CIUS (Core Invoice Usage Specification) narrows the core: it can make optional things mandatory, restrict code lists, and add rules — but it must not permit anything the core forbids. An extension goes further and adds structure beyond the core, which is why extensions are rarer and treated more carefully.

PINT — Peppol International Invoice — sits at this layer. It is the model Peppol uses to take the invoice beyond Europe: a common billing base plus country-specific PINT specifications (Japan, Malaysia, Singapore, Australia/New Zealand and others) that pin down local requirements such as tax categories, identifiers and rounding. National CIUSes like XRechnung in Germany or the various country BIS documents do the same job for their own jurisdiction.

This is the layer that changes most often, and it is the one most likely to be out of date in your build. A CIUS release usually means new or amended Schematron, sometimes a new code list version, and occasionally a change of customization identifier — the string that tells the receiver which ruleset to validate against.

Layer 4 — the network profile

Finally, the invoice has to reach someone. In the four-corner Peppol model, the sender's access point delivers to the receiver's access point, addressed via participant identifiers looked up in the SMP. Peppol BIS Billing profiles bundle the document types, the transport and the customization identifiers into something two access points can agree on.

Many mandates now add a fifth corner: the tax authority receives the invoice, or clears it before it may be delivered. That changes the shape of the flow, not the shape of the document — but it introduces things the other three layers never had to model: clearance responses, reference numbers to be printed on the invoice, and a hard dependency on an external service being available.

Where projects actually break

In our experience the failures cluster in the same four places, and every one of them is a layer confusion:

1. Mapping to a syntax instead of to the model. The mapping is built by staring at sample XML files. It works for those samples and quietly breaks on the first invoice that uses a structure the samples did not contain.
2. Treating a CIUS as a format. Teams build "an XRechnung integration" and "a PINT integration" as separate pipelines, then maintain the same core logic three times.
3. Version drift between layers. A current syntax, last year's CIUS Schematron and a code list from the release before that. Each is individually defensible; together they produce rejections nobody can reproduce locally.
4. Assuming the network is the specification. Passing Peppol transport validation says the document is well-formed and routable. It does not say the receiver's ERP can post it, or that the tax authority will accept it.

The fix is structural rather than clever: build to the semantic model, treat syntax as a serialisation concern, keep CIUS rules as versioned data rather than code, and hold the network profile at the edge. Do that and a new country becomes a configuration exercise instead of a project.