What Is the Peppol Network, and Why Does It Matter?

Peppol is an international e-invoice delivery network with a rulebook that governs it: not a file format, not a portal, and not a tax authority’s reporting environment. The network consists of hundreds of certified service providers plus one central addressing component, all following the same Peppol Interoperability Framework and exchanging documents in a four-corner model. The central components are owned by OpenPeppol. It matters for one very practical reason: one integration with one service provider gives you a route to every partner on the network, without negotiating a separate technical channel with each buyer. Under Estonia’s Accounting Act, the format and submission terms of a machine-processable source document are agreed between the transaction partners, unless a law or other legal act provides otherwise.

What Your Buyer Actually Means by “Send It Through Peppol”

That sentence usually lands in the sales inbox with no explanation attached. The invoice is ready, the PDF exists, and then the buyer says they won’t accept an email attachment. The first question people ask is technically wrong but entirely human: what format does a Peppol invoice have to be in?

The right question is a different one. Peppol answers “how does the invoice reach the buyer, and how is the buyer found?” The format, the data fields and the national add-on rules are answered by the EN 16931 standard and the Peppol document specifications. And the legal obligation comes from a third place entirely: accounting or tax law. When those three layers get mixed together, you get the familiar argument: “but we already have an e-invoice, we’ll send the PDF.”

Is Peppol a Law, or a Route?

Peppol is the name of an interoperability framework, meaning the legal agreements, policies and technical specifications applied by Peppol Authorities and certified service providers. A provider may only offer Peppol services once it has signed the service provider agreement and passed Peppol conformance testing. That contractual layer is what makes the network a trusted environment rather than just another protocol.

Two separate things get conflated with it. First, national e-invoicing obligations, which come from each country’s own legislation. Second, tax reporting, such as Latvia’s requirement to pass invoices to the tax authority, which is its own process even though it relies on the same structured invoice. The Peppol network can be the means of meeting either one. It is not the source of either.

How Four Corners Become One Connection

From C1 to C4

In the four-corner model, seller and buyer never connect directly. The seller (C1) sends the invoice from their ERP or accounting software to their own Access Point (C2). That Access Point is a certified service provider, and it must validate the outgoing message before sending it, ensuring conformance with the Peppol Business Interoperability Specifications (Peppol BIS). From there the invoice moves to the buyer’s Access Point (C3) and on into the buyer’s system (C4).

How the Network Finds Your Buyer

Finding the recipient takes two steps. The sender’s Access Point first queries the SML (Service Metadata Locator), the central address registry operated by OpenPeppol, which says which directory the buyer uses. It then asks that directory, the SMP (Service Metadata Publisher), which documents the buyer actually accepts and where to deliver them. You never see this step. You see its consequence: if the buyer’s capability isn’t registered in the SMP, the invoice doesn’t move, no matter how correct the file is. Message integrity and sender identity rest on the network’s Public Key Infrastructure: the certificate a provider receives along with its agreement, and which can be revoked if the rules are broken.

The mobile network comparison holds up well here. You have a contract with one operator, but you can call everyone. Peppol’s own phrasing is “connect once, reach all”.

Three Names That Keep Getting Mixed Up

EN 16931 is the European semantic standard for e-invoices, meaning the agreement on which data fields an invoice carries and what they mean. It says nothing about how the invoice gets delivered.

Peppol BIS Billing is an implementation specification: it takes the content of EN 16931 and says exactly how it must be expressed. Peppol BIS builds on UBL, the Universal Business Language, standardised as ISO/IEC 19845, and adds validation rules, including country-specific ones.

The Peppol network is transport and addressing, the part that actually delivers the invoice.

Which answers the PDF question. A PDF sent by email can be a perfectly valid invoice in accounting terms, but it is not a machine-readable structured invoice. Latvia has written that line into law: a structured e-invoice, as defined by the Latvian Ministry of Finance, is an invoice conforming to the LVS EN 16931-1:2017 standard and the LVS CEN/TS 16931-2:2017 technical specification. A human-readable file doesn’t fit that definition.

What Changed in August 2026?

Peppol BIS Billing 3.0.21

The latest version of Peppol BIS Billing 3.0, version 3.0.21, was published on 20 May 2026 and became mandatory on 17 August 2026. Three changes land directly on whoever owns the invoicing process.

First, a new optional profile 02 (“billing with response”) was added for cases where a mandatory response to the invoice is required. That profile needs its own SMP registration, so if you want to receive invoice responses, your existing registration for receiving invoices is not enough. Second, rules PEPPOL-COMMON-R052 and R053 went from warnings to errors, because they now apply to all profiles. Third, the EAS code list was cleaned up and 14 unusable codes were removed: if your system fills the buyer’s electronic address scheme from a hand-configured value, that is worth a look.

Where ViDA Fits

Put ViDA next to it and the picture gets clearer. Council Directive (EU) 2025/516 was adopted on 11 March 2025 and allows Member States to impose mandatory domestic e-invoicing from 14 April 2025 onwards. From 1 July 2030, digital reporting requirements apply to cross-border B2B transactions and e-invoicing becomes the default method for them, with the invoice to be issued within 10 days. Countries that already run their own real-time transaction reporting must align it with the EU model by 1 January 2035. Nowhere in the directive is there a date that obliges every company to join Peppol.

Do Estonia, Latvia and Lithuania Move in Step?

Estonia: A Buyer’s Right

In Estonia, since 1 July 2025 an accounting entity registered in the business register as an e-invoice recipient may require the seller to issue an e-invoice. The invoice is deemed compliant if it conforms to EN 16931-1, unless the parties have agreed on another suitable standard. There is no blanket obligation forcing every seller to issue everything as an e-invoice. What counts is the buyer’s registration and what you agreed contractually.

Latvia: Dated, and Bundled with Tax Reporting

Latvia’s timeline is the most explicit. From 1 January 2025, invoices issued to budget institutions must be structured e-invoices (G2G, B2G, G2B). From 1 January 2026, those e-invoices must also be transmitted to the tax authority VID, and from 1 January 2028 the requirement extends to domestic B2B invoices. B2B e-invoices can already be issued today, and data can be passed to VID voluntarily from 2026.

Lithuania: SABIS and the Public Sector

Lithuania has used SABIS instead of the former E. sąskaita since 1 September 2024. According to the Ministry of Finance, the point of modernising it is to connect businesses to European e-invoicing infrastructure through the Peppol network and to support public sector invoices conforming to EN 16931.

So if you sell in all three countries, you don’t have one deadline. You have three different logics: a buyer’s right in Estonia, a dated obligation bundled with tax reporting in Latvia, and public sector infrastructure in Lithuania.

What to Check Before Your Next Invoice

• Buyer capability and identifier: ask for the Peppol ID and confirm the buyer is registered in the SMP as a recipient of exactly the document type you intend to send.
• Required profile and country rules: is the buyer expecting the standard billing profile, or the new profile 02 with responses? The latter needs a separate SMP registration on your side too.
• Your provider setup: make sure your Access Point is certified and its validation artefacts match version 3.0.21. Since 17 August 2026 the older version is no longer allowed.
• Data quality in your ERP: registry codes, VAT numbers, reference numbers, address schemes. Most validation failures come from missing codes or codes taken from the wrong list, not from the invoice content.
• Response workflow: if the buyer requires an invoice response, someone has to decide who issues it and what happens on a rejection.
• Archiving: the structured file is the original document. Agree whether your system keeps it, your provider keeps it, or both, and for how long.

The most expensive mistake on that list isn’t technical. It’s assuming that because one large buyer accepts your invoices, you’re set for everyone. Latvia’s 2028 date and ViDA’s 2030 cross-border reporting are close enough that sorting out both sending and receiving capability is better done before someone demands it.

Also available in: eesti keeles · latviski · lietuviškai

Last reviewed: 16 September 2026