— May 2, 2026 · 11 min read

PEPPOL BIS Billing 3.0: decoding EN 16931 painlessly

EN 16931 is not a format. It is a semantic model — the list of facts an electronic European invoice must carry. PEPPOL BIS Billing 3.0 is one of its syntactic bindings, in UBL. Understanding this two-tier stack is the first step into the e-invoicing dossier.

A teaching misunderstanding that lingers

Readers who open the European e-invoicing documentation for the first time usually note the same thing: the terminology circulates confusingly. EN 16931, PEPPOL BIS, UBL, CII, Factur-X, XRechnung, ZUGFeRD — the list grows, and every name seems to describe "roughly the same thing." The reflex is to talk about "the European format" without being more precise, and the consequence is RFPs in which the vendor cannot answer the otherwise simple question: "which file are we supposed to produce?"

The misunderstanding comes from conflating two layers. EN 16931 is a semantic model — a structured list of business fields an invoice must carry to be valid in Europe. The model says nothing about how the fields are serialised. PEPPOL BIS Billing 3.0 and UBL 2.1 are syntactic choices: they decide how the model's fields are written in an XML file. The full genealogy is documented on the ediverse PEPPOL page, but the summary fits in three lines.

EN 16931, the semantic model

Published by CEN (the European Committee for Standardization), EN 16931 was issued in response to Directive 2014/55/EU on electronic invoicing in public procurement. The normative text defines two artefacts. First, a list of business terms — often abbreviated "BT-", numbered from BT-1 up past BT-200 — that describe every useful field: invoice number (BT-1), invoice date (BT-2), invoice type code (BT-3), currency code (BT-5), total VAT (BT-110), payable amount (BT-112), and so on down to finer notions like the reference order identifier (BT-13) or the line-level allowance reason (BT-139).

Second, a list of business rules — the "BR-" rules — that constrain the business terms: BR-01 requires the presence of an invoice identifier, BR-02 requires a date, BR-CO-10 checks the arithmetic consistency of VAT amounts against line totals, and so on across roughly one hundred and fifty rules. The point of these rules is to ensure a document declared compliant is not just well-filled, but arithmetically coherent. A total that does not add up, a currency that contradicts the issuer's country, a line with no unit price — each fails a rule, and the invoice is rejected at the network's edge.

EN 16931 stays, by design, syntax-agnostic. The text does not say how to write BT-1 in a file. It simply says: BT-1 must be present, it is a string, it is the invoice's unique identifier. The decision to write it as <cbc:ID>FA-2026-0001</cbc:ID> or as BGM+380+FA-2026-0001 is delegated to the layer underneath.

UBL 2.1, the syntax

UBL — Universal Business Language — is a family of XML schemas published by OASIS and ratified as an OASIS Open standard in 2013. Version 2.1 covers 65 business documents (order, acknowledgement, despatch advice, invoice, credit note, payment instruction, and so on). The document that matters for European e-invoicing is, of course, Invoice, and its cousin CreditNote for credit memos.

The UBL binding of EN 16931 maps each business term to a UBL XML path. BT-1 becomes /Invoice/cbc:ID, BT-2 becomes /Invoice/cbc:IssueDate, BT-5 becomes /Invoice/cbc:DocumentCurrencyCode, and so on. The EN 16931 Mapping UBL document, published by CEN/TC 434, gives the complete correspondence table. The subtlety lies in cardinalities: some BTs are mandatory, some are only allowed if another BT is filled, others admit multiple occurrences.

A developer already comfortable with ORDERS in EDIFACT (see the ORDERS D.96A reference) will find a striking conceptual continuity: the qualifier notions (party qualifier, date qualifier, identifier qualifier) return, simply renamed in UBL. The identifier of the buyer party, for example, carries a schemeID instead of a qualifier in the C082 composite, but the idea is identical: telling the machine what the given string represents.

PEPPOL BIS Billing 3.0, the business rules

PEPPOL — Pan-European Public Procurement Online — is an exchange network operated by OpenPeppol AISBL. The network defines Business Interoperability Specifications, or BIS, which are usage profiles: a BIS says "this is how, on the PEPPOL network, this type of message is sent." BIS Billing 3.0 is the invoicing profile, and its content sits in four layers:

• it mandates UBL 2.1 syntax (no CII in BIS Billing 3.0; CII has its own BIS in other contexts);
• it restricts the EN 16931 model — some BTs optional at European level become mandatory in the profile;
• it adds business rules specific to the PEPPOL network, prefixed BR-NN- in the Schematron: BR-NN-001, for example, requires the presence of a PEPPOL endpoint on the invoice;
• it publishes validation artefacts — a Schematron for PEPPOL rules, another for TC434 rules (the pure European rules), example XML files, an XSLT stylesheet for human rendering.

The whole specification is documented at docs.peppol.eu/poacc/billing/3.0/ and archived in ediverse as primary source. The spec landing page lists fifteen code sub-lists explicitly: ISO 6523 ICD, Electronic Address Scheme, ISO 3166-1 country codes, ISO 4217 currency codes, Rec 20 (units of measure) with Rec 21 (packaging) prefixed with X, tax category codes extracted from UNCL5305, invoice type codes UNCL1001, payment means codes UNCL4461, allowance reason codes UNCL5189, charge reason codes UNCL7161, MIME codes, the SEPA indicator, and the VATEX code list. This code-list ecosystem is what turns a generic UBL document into a recognisable European invoice.

National sub-rules (BR-FR, BR-DE, BR-IT)

On top of the three layers above (UBL, EN 16931, PEPPOL BIS Billing) each country may, and often must, add a fourth tier of rules. CIUS — Core Invoice Usage Specifications — are profile restrictions: Italy, for example, requires additional tax identification for the SdI, and Germany, through XRechnung, requires a Leitweg-ID in federal public procurement.

The BR-FR-, BR-DE-, BR-IT- notations encountered in national Schematron files denote these added rules. They never contradict the European rules: they tighten them, or constrain a detail EN 16931 left open. A vendor aiming at multi-country compliance must therefore stack Schematron files — PEPPOL BIS Billing 3.0 plus the national profile, the latter often identical to a CIUS published by the local body (AGID in Italy, AIFE in France, KoSIT in Germany).

The practical pitfall is well-known: an invoice valid in generic PEPPOL BIS can be rejected by the Italian SdI because it lacks the proper Codice Destinatario. A French developer cannot therefore stop at the OpenPeppol Schematron. They must embed the Schematron of every target country.

An example read business term by business term

For grounding, here is what a minimal invoice looks like, read vertically. A French issuer invoicing a Belgian customer for two items at 250 € net each, 20% VAT, writes in BIS Billing 3.0 an XML tree whose key elements carry these business terms:

• BT-1 — the identifier FA-2026-0142, in cbc:ID at the root;
• BT-2 — the issue date 2026-05-02, in cbc:IssueDate;
• BT-3 — the type code 380 (commercial invoice, drawn from UNCL1001), in cbc:InvoiceTypeCode;
• BT-5 — the currency EUR, in cbc:DocumentCurrencyCode;
• BT-27, BT-44 — the seller and buyer commercial names;
• BT-31, BT-48 — the intra-community VAT numbers (with schemeID="VAT");
• two cac:InvoiceLine entries each bearing BT-126 (line identifier), BT-129 (quantity 1), BT-131 (line net amount 250.00), BT-146 (net unit price);
• one cac:TaxTotal bearing BT-110 (VAT amount 100.00) and a cac:TaxSubtotal with BT-117 (VAT category S, rate 20);
• one cac:LegalMonetaryTotal bearing BT-106 (sum of line nets 500.00), BT-109 (amount before tax 500.00), BT-112 (amount payable 600.00).

BR-CO-10 then verifies, on this invoice, that BT-112 equals BT-109 + BT-110. If the author has computed a total of 601 €, the Schematron raises an error and the PEPPOL access point refuses the invoice. This verifiable arithmetic, sometimes painful at integration time, is the chief difference with the EDIFACT world: where ORDERS and INVOIC content themselves with a CNT line count, EN 16931 enforces total coherence between the declared totals.

The PEPPOL network, transport, signature

Once an invoice complies with BIS Billing 3.0, it travels: PEPPOL defines a four-corner model. On the sender side, an Access Point Provider (Corner 2) receives the invoice from the business application (Corner C1). Corner 2 deposits the message on the network via the PEPPOL AS4 eDelivery protocol (based on OASIS ebMS 3.0). The message is routed to the recipient's access point (Corner 3) which delivers it to the recipient's business application (Corner C4). The Service Metadata Locator (SML) and the Service Metadata Publisher (SMP) resolve the destination identifier (often a VAT number, sometimes a GLN ICD 0088) to the access point URL.

In practice, the sender going through PEPPOL does not deal with transport: it submits to its access point — Stedi, Pagero, Ibanity, B2Brouter and roughly a hundred others are certified — and the network handles routing. Signature and encryption are managed at AS4 tunnel level by the PEPPOL certificates, not at XML level. This is an important difference from the historic XAdES ecosystem, where the invoice carried its own detached signature.

What to code, practically

For a vendor preparing its invoicing module, the technical plan reduces to four bricks. A serialisation brick producing UBL XML from the internal business model — usually a hand-written mapping, because generic UBL libraries map EN 16931 cardinalities poorly. A validation brick running XSD + Schematron in two passes before sending: better to refuse an invalid invoice locally than to wait for the network's rejection. A transport brick AS4, typically delegated to the access point — few vendors operate their own PEPPOL AS4 tunnel because certification and certificate maintenance carry significant recurring cost. And finally a legal archive brick: the invoice must be retrievable in its original XML for the legal retention period — ten years in France for commercial documents.

To validate a first invoice, readers may use any online PEPPOL validator — OpenPeppol publishes an official validator — or self-host the Schematron via Saxon. The ediverse EDIFACT validator covers the EDIFACT family; an equivalent UBL/PEPPOL validator is being scoped on the ediverse roadmap for V1.5.

The tier that did not exist ten years ago

The subtlest leap in the entire EN 16931 / PEPPOL BIS edifice is the very existence of a semantic layer separated from format. Where EDIFACT had, since 1986, conflated the business model and the line-level format, EN 16931 splits them cleanly. This makes possible something that did not exist before: changing the syntax — moving from UBL to CII in a Factur-X, for example — without changing the invoice, the rules, or the checks. The invoice becomes a conceptual object, independent from the file that carries it.

For anyone shipping a European invoicing module in 2026, that is good news: the implementation work shifts from serialisation to validation. And validation, in turn, is contract-testable — Schematron is explicit, versioned, public. Conversely, surprises will come less from XML than from local sub-rules (BR-FR, BR-DE…) that change with each decree. That is where the devil hides, not in the UBL grammar itself.