Peppol Is Not E-Invoicing: What Each Country Actually Mandates

Almost every vendor page treats "Peppol" and "e-invoicing" as synonyms. They are not, and the difference decides what you actually have to build. Teams have bought Peppol access points to satisfy German rules that never mentioned Peppol, and teams have joined Peppol expecting it to cover France, where it does not.

Here is the distinction, and then the country-by-country reality.

Four layers, and mandates pick from them

An e-invoicing regime is made of four separable parts.

Identity. Who you are on the network. In Peppol this is a participant ID plus a scheme code, such as a GLN or a VAT number.
Transport. How the document moves. Peppol uses AS4 over a four-corner model: you connect to one access point, your counterparty connects to theirs, and the two interoperate by rule.
Format. What the document is. EN 16931-1:2017+A1:2019 is the European semantic standard, expressed either as UBL 2.1 or UN/CEFACT CII D16B.
Rules. What counts as valid. Peppol BIS Billing 3.0, XRechnung, and Factur-X are all national or sectoral narrowings of EN 16931, formally called CIUS documents, each enforced by its own schematron ruleset.

A law can require any subset of those four. That is the whole source of the confusion.

What each country actually requires

Country	Format mandated	Transport mandated	In practice
Belgium	Peppol BIS Billing 3.0	Peppol network	Full Peppol stack
Slovakia	EN 16931	Peppol, five-corner	Full Peppol stack, from Jan 2027
Norway	EHF 3.0	Peppol network	EHF 3.0 is aligned to Peppol BIS Billing 3.0
Germany	EN 16931	None	Email a valid ZUGFeRD file and you are compliant
France	Factur-X, UBL, or CII	Approved platform	Not Peppol. See below
Poland	FA(3) XML	KSeF government portal	No private network involved
Italy	FatturaPA XML	SdI government portal	No private network involved

Germany mandates the format and not the transport

Germany's obligation comes from the Growth Opportunities Act, which amended Section 14 of the German VAT Act (UStG). It requires that an invoice conform to EN 16931. It says nothing about how the invoice travels.

That is why the dominant German pattern is a ZUGFeRD invoice, which is a PDF/A-3 file with the XML embedded as an attachment, sent as an ordinary email. The recipient's tax adviser imports it into DATEV in one step. No access point, no participant lookup, no network membership.

If you are selling into Germany and someone tells you that you need Peppol, ask them which provision requires it. There isn't one.

France mandates a transport model, but not Peppol

France runs its own scheme. Invoices must be exchanged through a certified provider, known as a Plateforme de Dématérialisation Partenaire (PDP) and since 2024 formally a Plateforme Agréée.

The original design also included a free public portal, the Portail Public de Facturation, through which businesses could issue and receive invoices directly. On 15 October 2024 the DGFiP announced that this function was being dropped to protect the deployment calendar. The PPF now does two things only: it maintains the central directory of VAT-registered businesses and their e-invoicing addresses, and it acts as the data concentrator that passes tax data to the DGFiP.

Many approved platforms also connect to Peppol. That is a commercial choice by the platform, not a legal route. Peppol membership alone does not make you compliant in France.

Belgium is the case where Peppol genuinely is the answer

From 1 January 2026 all Belgian taxable persons must issue and receive structured e-invoices, and the Peppol network is the designated channel. If you trade in Belgium, a Peppol access point is not optional and not a workaround. It is the mechanism the law names.

Slovakia has proposed the same shape from January 2027, using a decentralised five-corner Peppol model with certified service providers.

Poland and Italy bypass private networks entirely

Poland's KSeF and Italy's SdI are clearance systems. The invoice goes to the state, the state validates and stamps it, and the state passes it on. There is no access point to buy and no network to join. What you need is an integration with the government platform and its schema, which for Poland is FA(3).

Why this matters commercially

Three consequences follow directly.

You may need less than you were sold. If Germany is your only mandated market, you need an EN 16931 generator and an email server. The access point contract, the participant registry, and the AS4 stack are all solving a problem you do not have.

You may need more than one thing. A group trading in Belgium, France, Germany, and Poland needs a Peppol connection, a French approved platform, a ZUGFeRD generator, and a KSeF integration. There is no single switch. Vendors who claim otherwise are usually reselling four integrations behind one invoice.

Your ERP may already cover part of it. Odoo ships a built-in Peppol access point. NetSuite has an Electronic Invoicing SuiteApp. Business Central ships native Peppol format support, though only for a handful of countries and, as of this writing, not France. Check before buying anything. Our ERP Peppol support guide covers which systems ship what.

Three sentences worth remembering

Peppol is a network, EN 16931 is a format, and a mandate can require one, both, or neither.

Germany mandates the format and not the transport. France mandates the transport model and not Peppol.

And every one of these mandates covers invoices. None of them touches the purchase order, because a purchase order creates no VAT event and tax authorities regulate what they can audit. Peppol does define ordering profiles, covered in our Peppol ordering guide, but no government has ever required them.

Sources

Growth Opportunities Act and Section 14 UStG guidance, EDICOM
DGFiP announcement on the PPF refocus, KERHIS
Peppol BIS specifications, OpenPeppol