{"id":29106,"date":"2026-08-08T07:00:01","date_gmt":"2026-08-08T07:00:01","guid":{"rendered":"https:\/\/bilnex.io\/en\/peppol-bis-billing-version\/"},"modified":"2026-08-08T07:00:01","modified_gmt":"2026-08-08T07:00:01","slug":"peppol-bis-laskutusversio-2","status":"publish","type":"page","link":"https:\/\/bilnex.io\/fi\/peppol-bis-laskutusversio-2\/","title":{"rendered":"Peppol BIS Billing 3.0 -version opas elokuulle 2026"},"content":{"rendered":"
\n
\n
\n

The short answer for 7 August 2026<\/h2>\n

On 7 August 2026, the Peppol network (the shared system public bodies and a growing number of private companies across Europe use to exchange structured e-invoices) is still running on Peppol BIS Billing 3.0 version 3.0.20, paired with a mandatory 3.0.20 hotfix. Ten days later, on 17 August 2026, version 3.0.21, published on 20 May 2026, becomes mandatory for everyone on the network. All three dates are set out in openPeppol’s release notes<\/a>. This isn’t a new invoice format. It’s a validation and code-list update inside the same Peppol BIS Billing 3.0 family. Right now, the safest move is to get written confirmation from your e-invoice operator or accounting software provider on exactly when their system switches to the 3.0.21 rules, and whether it’s actually been tested against that deadline.<\/p>\n\n\n\n\n\n\n
Date<\/th>\nWhat applies<\/th>\n<\/tr>\n<\/thead>\n
7 August 2026<\/td>\n3.0.20 + mandatory hotfix<\/td>\n<\/tr>\n
17 August 2026<\/td>\n3.0.21 becomes mandatory for everyone<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Is Peppol BIS Billing 3.0 one frozen file, or an entire family of releases?<\/h2>\n

The specification versus the release number<\/h3>\n

Most of the confusion comes from the fact that “Peppol BIS Billing 3.0” and a version number like 3.0.20 or 3.0.21 sound like the same thing. They aren’t. BIS Billing 3.0, a Business Interoperability Specification, is the stable description of the business document itself: it sets out which data fields an invoice has to contain. It covers the ordinary invoice-and-credit-note process that openPeppol calls Profile 01, still listed in its official specification<\/a> as “Profile 01 \u2013 Billing.”<\/p>\n

How releases roll out<\/h3>\n

That general specification, though, gets refreshed regularly through smaller releases (3.0.19, 3.0.20, 3.0.21, and so on), each bringing updated code lists (the approved sets of values, such as country codes) and validation artefacts, the technical rule files that check whether a submitted XML invoice actually follows the rules. The current official guide still carries the version number 3.0.20, as the specification’s title page<\/a> shows. The number only flips to 3.0.21 once that release formally takes effect.<\/p>\n

What actually changes in version 3.0.21?<\/h2>\n

Code lists and validation artefacts<\/h3>\n

3.0.21 runs on code lists published on 6 March 2026 and on UBL\/CII validation artefacts version 1.3.16, published on 10 April 2026, both dates confirmed in openPeppol’s release notes<\/a>. UBL and CII are the two alternative XML syntaxes a Peppol invoice can be written in; most Baltic operators use UBL (Universal Business Language).<\/p>\n

Two rules move from warning to error<\/h3>\n

The change that matters most sits in two rules: PEPPOL-COMMON-R052 and PEPPOL-COMMON-R053. Until now they only triggered warnings. From 3.0.21 they become hard errors across every profile. In practice, that means your test runs need real buyer and seller master data (names, addresses, registration numbers) rather than a generic sample XML, because these two rules check exactly those fields.<\/p>\n

A new optional profile arrives<\/h3>\n

3.0.21 also introduces a new optional profile, Profile 02, for an invoice-and-response process, which we get to below. For an ordinary invoice sender running Profile 01 and simply exchanging invoices and credit notes, the business process itself doesn’t change at all. Only the checks running behind the scenes do.<\/p>\n

What should you check before 17 August?<\/h2>\n

The safest way to move is methodically, rather than assuming your operator “already has it handled”:<\/p>\n