Short answer by August 7, 2026

On August 7, 2026, Peppol BIS Billing 3.0 will still be running version 3.0.20 with the mandatory 3.0.20 hotfix. Ten days later, on August 17, 2026, version 3.0.21, which was released on May 20, 2026, will become mandatory. All three deadlines are listed in openPeppoli in the release notes. This is not a new invoice format, but an update of the validation and code lists made in the same Peppol BIS Billing 3.0 family. The most sensible thing to do now is to ask your e-invoice operator or accounting software manufacturer for written confirmation: when will their system transition to the 3.0.21 rules and whether it has been tested by that deadline.

Date What applies
August 7, 2026 3.0.20 + mandatory hotfix
August 17, 2026 3.0.21 becomes mandatory for everyone

Is Peppol BIS Billing 3.0 one frozen file or a whole family?

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 similar, but they are not the same thing. BIS Billing 3.0 is a stable business document description that says which data fields an invoice must contain. It describes the common invoice-and-credit-note process, which openPeppol calls profile 01 and which is its in the official specification still listed as “Profile 01 – Billing”. But this general specification is updated regularly in minor releases, such as 3.0.19, 3.0.20, 3.0.21 and so on, which bring updated code lists, or lists of allowed values (such as country codes), and validation artifacts that check whether the submitted XML file complies with the rules. The current official guide still carries the version number 3.0.20, as specification title page shows. The number will only change to 3.0.21 when this release officially goes into effect.

What changes in version 3.0.21?

3.0.21 uses code listings published on March 6, 2026, and UBL/CII validation artifacts in version 1.3.16, published on April 10, 2026. Both dates are openPeppoli in the release notes in the letter. UBL and CII are two alternative XML syntaxes in which a Peppol invoice can be written; most Baltic operators use UBL. The more significant change concerns the rules PEPPOL-COMMON-R052 and PEPPOL-COMMON-R053, which were previously warnings and will become errors for all profiles in 3.0.21. In practice, this means that real customer and supplier master data must be used in tests, not just sample XML, because these rules check these fields. A new optional profile 02 for the invoice-and-reply process is also added. I will write more about it below. For a regular invoice sender who uses profile 01 and simply exchanges invoices and credit notes, the business process itself does not change a single step. Only the checks running in the background change.

What to check before August 17?

The safest way is to move systematically, not hoping that the operator will “already deal with it”:

  • Confirmation from supplier: ask the operator in writing when their production environment will be transferred 3.0.21 for validation artifacts.
  • Validators update: If you validate invoices yourself, use the latest UBL/CII 1.3.16 rules, not the old 3.0.20 set.
  • Test with real data: send a test invoice and credit note through the system with the real customer and supplier names, addresses, and registry codes, because R052 and R053 become errors in these fields.
  • Check buyer identifiers: The hotfix added the Slovak tax code 0245 on January 27, 2026, and 3.0.21 adds new ICD codes 0246–0248. If you sell cross-border, make sure you have these codes in your system.
  • Keep the evidence: Keep shipping and delivery confirmations from the transition period to prove under which set of rules the invoice was issued.

What is the difference between profile 01 and profile 02?

Profile 01 is a normal process: the seller sends an invoice or credit note, the buyer receives it and it's done. Its technical identifiers are defined: the CustomizationID or invoice declaration of conformity identifier is `urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0` and the ProfileID or business process identifier is `urn:fdc:peppol.eu:2017:poacc:billing:01:1.0`, as current guide will write them down. These values will not need to be changed in your existing XML after 3.0.21. This release does not introduce a new CustomizationID or ProfileID for the regular invoicing process.

Only the optional profile 02 is new, which is added to the process with 3.0.21, where the buyer must send feedback on the invoice, i.e. confirm that the invoice has been approved or rejected. This profile requires separate registration in the SMP, or Service Metadata Publisher, where the Peppol network keeps track of which documents your company can accept, such as release notes explain. If your buyers do not require or support profile 02, there is no point in registering it. Stick with profile 01 and only add profile 02 if a specific business partner specifically asks for it.

What does this mean in Estonia, Latvia and Lithuania?

Valid in Estonia from From July 1, 2025 an amendment to the Accounting Act, according to which an accounting entity registered in the Commercial Register as the recipient of an e-invoice may require the seller to submit an e-invoice to it, and the invoice will be considered to be properly drawn up if it complies with the European standard EN 16931-1, unless the parties have agreed on another standard.

In Latvia, the requirement is more clearly Peppol-based: Valsts ieņēmumu dienests describes a structured e-invoice as an XML file, the structure of which must comply with Peppol BIS Billing 3.0 specification. In G2G, B2G and G2B transactions, structured e-invoices are mandatory from 1 January 2025, the transmission of e-invoice data to the Tax Board is mandatory for the same segments from 1 January 2026, and the B2B requirement with simultaneous submission will enter into force from 1 January 2028.

In Lithuania, e-invoices are processed through the national platform SABIS, which is managed by the Ministry of Finance. connected to the Peppol network. In essence, this means that Lithuanian buyers and sellers using SABIS will also actually interact with the same Peppol BIS Billing documents and profiles that this article describes.

Why are invoices actually rejected?

A large part of the “invoice not going through” cases comes down to five confused concepts. EN 16931 is a European standard that describes the semantic data model of an invoice in general. Peppol BIS Billing 3.0 is the CIUS or Core Invoice Usage Specification, a narrowed user guide for this standard, which makes the requirements of EN 16931 more specific In the context of the Peppol network. A release number, such as 3.0.20 or 3.0.21, is not a new standard or a new invoice format. It is a version of the validation and code lists made in BIS Billing 3.0. The SMP registration, which determines which profiles your company can accept, is a separate technical setting that does not automatically change with a release change. And a PDF invoice, no matter how correct it looks, is not a Peppol invoice. It is an attachment that is not machine-readable or validated according to Peppol rules. If an invoice is rejected, first check which of the five is actually missing before you start suspecting that “Peppol is broken”.

FAQ

What changes in version 3.0.21?

3.0.21 uses the code lists published on March 6, 2026 and the UBL/CII validation artifacts in version 1.3.16. The most significant change concerns the rules PEPPOL-COMMON-R052 and PEPPOL-COMMON-R053, which become errors. Optional profile 02 is added.

What is the difference between profile 01 and profile 02?

Profile 01 is a standard invoice sending without a response. Profile 02 adds an invoice response process where the buyer must send feedback. Profile 02 requires a separate SMP registration.

What to check before August 17, 2026?

Ask the operator for written confirmation of the transition, update the validators, test with real data (R052 and R053), check the buyer identifiers (ICD codes 0246–0248) and keep the evidence.