Reference · Peppol BIS Billing 3.0
Why a valid EN 16931 invoice can still fail a Peppol check
Peppol BIS Billing 3.0 does not compete with EN 16931; it narrows it. An invoice that passes EN 16931's own rules in full can still be rejected by Peppol's, and every reason why is the same shape of change. A field EN 16931 leaves optional, Peppol makes mandatory.
Peppol BIS Billing 3.0 is formally a CIUS (a CEN-defined Core Invoice Usage Specification)
of EN 16931. The specification states that instance documents compliant with it will also be
compliant with EN 16931, and a conforming invoice asserts that relationship through its
specification identifier: the value urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0.
A CIUS may restrict. It may never relax.
A CIUS may narrow what EN 16931 allows. It may never permit something EN 16931 forbids, and it may never make optional something EN 16931 already requires. Every difference below is a narrowing in that sense (a field turned mandatory, an identifier pinned to one exact string, a cardinality forbidden, a cross-field check added), which is exactly why a document can satisfy EN 16931's Schematron in full and still be rejected by Peppol's.
Which version is in force right now
Two versions of Peppol BIS Billing 3.0 matter as of today. The November 2025 Release, version 3.0.20, received a hotfix on 27 January 2026 that became mandatory on 23 February 2026 — 3.0.20-hotfix is the version in force now. The May 2026 Release, version 3.0.21, becomes mandatory on 17 August 2026.
Where a valid EN 16931 invoice fails
The published Peppol Schematron carries 28 assertions in the PEPPOL-EN16931-R*
family alone, each testing something EN 16931 permits but Peppol does not. These are the ones
most likely to turn a document an EN 16931 check already accepted into one Peppol rejects.
| Rule | What Peppol requires | What EN 16931 allows |
|---|---|---|
R004 |
Specification identifier (cbc:CustomizationID) MUST equal
urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0
|
A plain EN 16931 invoice carries urn:cen.eu:en16931:2017 — a different string, so it fails immediately |
R001 |
“Business process MUST be provided” (cbc:ProfileID) |
BT-23 is optional |
R010 |
“Buyer electronic address MUST be provided” (cac:AccountingCustomerParty/cac:Party/cbc:EndpointID) |
BT-49 is optional |
R020 |
The same test, mirrored onto the seller electronic address | BT-34 is optional |
R003 |
A buyer reference or an order reference must be present | EN 16931 leaves both optional |
R002 |
“No more than one note is allowed on document level, unless both the buyer and seller are German organizations” | EN 16931 permits multiple BT-22 notes |
R051 |
Every currencyID attribute must equal the invoice currency code (BT-5), except the invoice total VAT amount in accounting currency (BT-111) |
Mixed-currency attributes elsewhere are legal UBL |
R053 |
Only one tax total carrying tax subtotals may be provided | EN 16931 does not forbid more than one |
R110 / R111 |
A line period's start and end dates must fall within the invoice's own period | EN 16931 imposes no such cross-field constraint |
R061 |
A mandate reference must be provided whenever the payment means is direct debit | EN 16931 does not tie the two together |
R120 |
A line's net amount must equal quantity × (net price ÷ price base quantity), plus line charges, minus line allowances, within a 0.02 tolerance | EN 16931 defines the same formula without enforcing it as a hard numeric check |
The single most common failure
R004 accounts for more Peppol rejections than any other rule in this list, because it is the
one every EN 16931-only invoice already fails without anything else being wrong. An invoice
built to plain EN 16931 carries the specification identifier
urn:cen.eu:en16931:2017; Peppol requires the longer, CIUS-specific string above,
and there is no partial match — the two values are either equal or the document is rejected
before any other rule runs.
The shape of the difference
Every row above falls into one of four moves, and all four are legal CIUS moves under the restrict-only rule above: R001, R003, R010 and R020 add fields EN 16931 leaves optional; R004 pins an identifier to one exact string; R002 and R053 forbid a cardinality EN 16931 allows; and R110, R111 and R120 add a cross-field or arithmetic check EN 16931 does not impose. None of it is Peppol disagreeing with EN 16931. It is Peppol narrowing it, which is what a CIUS is for. It is also why "EN 16931 compliant" and "Peppol-deliverable" are two different claims. The first can be true while the second is false.
The R-family above is not the whole of Peppol's ruleset. A companion
PEPPOL-COMMON-R* family validates national identifiers such as VAT and
legal-registration numbers, and country-specific assertions for Denmark, Norway, Italy and
France sit in the same Schematron.
What this does not cover
This article covers the Schematron differences between EN 16931 and Peppol BIS Billing 3.0. It does not cover how a document reaches its recipient. EUInvoice does not transmit invoices over the Peppol network and is not a Peppol access point. Peppol registration, access-point selection and the transport protocol used between access points are separate questions this article does not cover.
Sources
- OpenPeppol, Peppol BIS Billing 3.0, November 2025 Release, version 3.0.20, with the hotfix of 27 January 2026.
- OpenPeppol, Peppol BIS Billing 3.0, May 2026 Release, version 3.0.21, mandatory from 17 August 2026.
- Peppol validation artefacts (Schematron),
PEPPOL-EN16931-UBL.sch. - EN 16931-1:2017+A1:2019+A2:2020, CEN/TC 434, the European standard's semantic data model for the core elements of an electronic invoice.
- Directive 2014/55/EU on electronic invoicing in public procurement.
- Commission Implementing Decision (EU) 2017/1870.