Peppol BIS Billing 3.0 vs EN 16931: what's the difference?
See how EN 16931, Peppol BIS Billing 3.0, and UBL 2.1 nest as three layers of one invoice rather than competing formats you have to choose between.
Read a few pages about e-invoicing and you collect three names that all seem to describe the same document: EN 16931, Peppol BIS Billing 3.0, and UBL 2.1. It is tempting to treat them as rival formats and worry about picking the right one. They are not rivals. They are three layers of a single invoice, each doing a different job, and once you see how they stack the confusion clears up for good.
EN 16931: the meaning
Start at the top. EN 16931 is a European standard that defines the semantic model of an electronic invoice — the list of things an invoice must be able to express and what each one means. Seller name, buyer VAT identifier, invoice date, line item quantity, VAT category and rate, the payable total: EN 16931 specifies these as a "core invoice model" with clear rules about which are mandatory and how they relate.
Crucially, EN 16931 says nothing about the file format. It defines meaning, not markup. Two invoices can both be fully EN 16931-compliant and yet be written in different file syntaxes. Think of it as the vocabulary and grammar of an invoice, independent of the language you write it down in.
This standard is the anchor of EU e-invoicing law. When a mandate says invoices must be "compliant with the European standard", EN 16931 is the standard it means.
UBL 2.1: the writing system
An invoice has to exist as an actual file, and that is where syntax comes in. EN 16931 can be expressed in more than one — UBL 2.1 and UN/CEFACT CII are the two recognised bindings. Peppol uses UBL 2.1: an OASIS standard that defines XML elements for business documents. It is the alphabet the semantic model is written in — the named tags and nesting that a machine can parse without a human reading the page.
So EN 16931 tells you an invoice must carry a seller VAT identifier; UBL 2.1 tells you which XML element holds it and how it is structured. One is meaning, the other is spelling. A valid Peppol invoice satisfies both at once.
BIS Billing 3.0: the house rules
EN 16931 is deliberately broad, because it has to cover invoicing across every EU member state, each with its own conventions. Left fully open, two compliant invoices could still be hard to exchange, because one might use an optional field the other never expects. Networks close that gap with a CIUS — a Core Invoice Usage Specification — which narrows the standard for a particular context without breaking compliance.
Peppol BIS Billing 3.0 is that specification for the Peppol network. It takes EN 16931, tightens it, and adds Peppol-specific business rules and identifier requirements so that any two participants can exchange invoices without prior bilateral agreement. It says which optional fields Peppol expects, which code lists to use, and how participants are addressed. It does not contradict EN 16931; it is a stricter, network-ready reading of it.
How they nest
Put the three together and the hierarchy is clean:
- EN 16931 defines what an invoice means (the semantic core).
- Peppol BIS Billing 3.0 constrains that meaning for the Peppol network (the CIUS and its rules).
- UBL 2.1 is the syntax the whole thing is written in (the XML file).
A single Peppol invoice is all three at once: a UBL 2.1 file, carrying the EN 16931 data model, tightened to the BIS Billing 3.0 profile. You do not choose between them. You produce one document that honours all three, and a validator checks it against each layer — malformed XML fails the syntax check, a missing mandatory field fails EN 16931, a Peppol-specific rule failure fails BIS Billing 3.0. Any of those gets the document rejected before it reaches your customer.
Why the layering is your problem, then isn't
This is precisely the work that sits between a Stripe invoice and a Peppol delivery. Stripe holds the data, but building the UBL, mapping it to EN 16931, and passing the BIS Billing 3.0 rules is not something Stripe does — does Stripe support Peppol covers that gap in full, and what is Peppol sets the wider context.
If you would rather not own three layers of validation, a delivery tool does it for you. Peppost reads your finalised Stripe invoices, generates BIS Billing 3.0 UBL, attaches the original PDF as the human-readable rendering, and dispatches through a certified access point — on prepaid credits, with free sends to test the output first. The sending guide shows the flow end to end, and the FAQ answers the format questions that tend to follow.