Peppol BIS Billing 3.0
explained

When people say the UK is "moving to Peppol", they usually mean two things at once: a network that carries invoices between businesses, and a format those invoices are written in. The government settled the first in June 2026, naming Peppol as the core interoperability network. The second, the format, is still open. On the Peppol network today, invoices are written in Peppol BIS Billing 3.0. This guide explains what that format is, how the UK's VAT invoice rules map onto it, and why the UK decision matters, without assuming you want to read XML.

Three layers: standard, specification, syntax

It helps to separate three things that are often blurred together:

EN 16931 is described in the UK consultation response as the semantic data model of the core elements of an electronic invoice. It says what an invoice must be able to say, not how to write it down. Peppol BIS Billing 3.0 is what OpenPeppol calls a Core Invoice Usage Specification (CIUS) of EN 16931: it narrows and clarifies the standard for use on the Peppol network, and OpenPeppol states that any document compliant with it is also compliant with EN 16931. UBL, the Universal Business Language, is the XML vocabulary it is written in.

The UK already uses the standard layer. All bodies covered by the Public Procurement Act 2023 must accept e-invoices that comply with BS EN 16931.

What a BIS Billing 3.0 invoice contains

An invoice in this format is a structured record with sections that will look familiar to anyone who has written an invoice:

Currency is expressed as an ISO 4217 code, such as GBP. The document type is coded too: 380 is a commercial invoice and 381 a credit note, with a set of other codes treated as invoices.

What it looks like underneath

You will never need to write this, but it demystifies the format to see that an e-invoice is just labelled data. A few lines of a UBL invoice look like this:

<cbc:ID>INV-0042</cbc:ID>
<cbc:IssueDate>2029-04-16</cbc:IssueDate>
<cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>
<cbc:DocumentCurrencyCode>GBP</cbc:DocumentCurrencyCode>

Every item on a paper invoice becomes an element like these, which is why the buyer's software can read it without anyone typing. The same invoice number, INV-0042, would appear on a PDF as text a person reads; here it is a value in a named field that a system reads, checks and posts to the right account, and the buyer's reference, due date and each line work the same way.

How UK VAT invoice rules map onto it

HMRC's VAT guide lists the information a full VAT invoice must show. Each item has a natural home in the format:

That is why a well-kept VAT invoice today converts cleanly tomorrow. The guide on what a UK invoice must include covers the current rules in full.

VAT categories

Each line and each VAT total carries a VAT category code from a UN/CEFACT list. The ones UK businesses would use most are:

Others in the list, such as K for intra-community supplies in the EEA and L and M for the Canary Islands, Ceuta and Melilla, exist because the specification is used across many countries.

The domestic reverse charge for construction is a good example of why the category matters: the invoice must show that the customer accounts for the VAT, and the AE category tells the buyer's software exactly that. The reverse charge checker helps you decide whether it applies.

Validation: why errors are caught early

A BIS Billing 3.0 invoice is checked against rules before it is delivered. There are two families: the business rules of EN 16931 itself, and additional Peppol rules. OpenPeppol publishes the validation artefacts, and access points use them to check invoices before sending. Typical checks are that required fields are present, that line totals add up to the invoice totals, that VAT is calculated consistently with each category, and that codes come from the permitted lists.

For a small business, the effect is simple: an invoice with a missing VAT number or totals that do not add up is rejected before it reaches your customer, with a message saying what to fix, instead of being queried weeks later.

Attachments and PDFs

The format allows supporting documents to be attached, such as a timesheet or a signed delivery note, and the specification says receivers must accept attachments of the permitted media types. You can therefore send a human-readable PDF alongside the invoice. But the attachment is supporting material: the invoice itself is the structured data. The guide on e-invoices versus PDF invoices explains why that distinction matters for the mandate.

Credit notes

The specification covers credit notes as well as invoices, with their own document type, 381. A credit note refers back to the invoice it corrects and carries the same structure: parties, lines, VAT breakdown and totals. That matters because corrections are common. If you overcharge a customer, agree a discount after invoicing, or a customer returns goods, you issue a credit note, and on the network it travels in the same way as the original invoice, so the customer's software adjusts their records automatically instead of someone matching a PDF by hand.

Who maintains it, and how it changes

OpenPeppol, the non-profit association that governs the network, maintains BIS Billing 3.0 and publishes updated releases, each with a date from which it becomes mandatory on the network. Releases typically update code lists and validation rules rather than changing the basic shape of an invoice. Access points and software providers apply the updates, so users rarely notice them. If the UK adopts a national version or extensions, those would be maintained alongside, and your software provider would handle them in the same way.

Why the UK decision matters

The government has said it will review adopting an existing standard or designing a UK-specific one, balancing interoperability with flexibility and simplicity, and that its technical work will look at extensions to the standardised invoice for sector-specific needs. Some respondents proposed modular formats: core fields every e-invoice must include, most likely those required on a VAT invoice today, plus optional fields for sectors that need more. Possible outcomes range from adopting BIS Billing 3.0 as it stands, to a UK usage specification built on EN 16931, to extensions for particular sectors. Each would be carried over the Peppol network.

For small businesses the difference is mostly invisible, because software handles the format. It matters more to software providers, which is why the government named the network first, so they can start building, and promised the standards in good time before April 2029.

What to do now

You do not need to learn BIS Billing 3.0. What helps is making sure your invoices already hold every piece of information cleanly: a proper invoice number sequence, correct VAT categories and rates (the VAT calculator helps), full customer details and purchase order references where customers use them. When the UK standards are published, ask your software provider to confirm it supports them. The Peppol in the UK guide covers the network side.