Peppol is a decentralised four-corner network: sender and receiver each connect to one accredited access point, and the access points find each other through a public directory. The national systems differ in kind, not in degree. Poland's KSeF is a central state system that issues the invoice itself; France routes every domestic B2B invoice through registered private platforms that also report to the tax authority; Germany prescribes no network at all — an email suffices; Belgium made Peppol the default so that the network is the mandate. Which one you face depends on the issuer's country, and a business operating in several countries needs more than one.
How the Peppol four-corner model works
In Peppol the sender (corner 1) hands the document to its access point (corner 2), which looks up the receiver's identifier, finds the receiver's access point (corner 3) and delivers to it; the receiver (corner 4) collects it there. Neither party needs an account with the other's provider.
OpenPeppol describes the components plainly. Access points "are Peppol-certified Service Providers that connect to each other through an addressing and capability lookup process". The Service Metadata Locator (SML) "defines which SMP an AP needs to connect with to discover the addressing details of any trading partner", and the Service Metadata Publisher (SMP) is where a participant publishes "their receiving capabilities and supported message types" — "similar to an electronic address book or business registry". The Commission's overview counts "hundreds of access points" and "nearly fifty service metadata publishers". Governance sits with OpenPeppol as coordinating authority, which "may delegate authority over the implementation and use of the Peppol Network to a Peppol Authority within a defined geographical jurisdiction" — the Commission's country sheet for Germany, for example, refers businesses to providers accredited by the German Peppol Authority.
Three properties follow. The network is open: any accredited provider can join, and "each sender only has to connect to one service provider to reach every receiver". It is document-agnostic: Peppol BIS Billing 3.0 is the invoice profile, but orders, despatch advices and national CIUS such as XRechnung travel the same way. And it does not involve the state in the exchange: the tax authority is not a corner. The Peppol page and Peppol identifiers cover the identifiers and lookups.
Poland: KSeF, a central clearance system
KSeF is a state system through which every structured invoice must pass: the issuer submits the FA(3) XML, KSeF validates it against the schema, assigns a KSeF number, and only then does the invoice legally exist and become available to the buyer.
The Ministry of Finance defines KSeF as a system "służącym w szczególności do: wystawiania, przesyłania, otrzymywania, dostępu, przechowywania faktur ustrukturyzowanych" — issuing, sending, receiving, accessing and storing structured invoices — which "przydziela automatycznie unikatowy numer identyfikujący każdą wystawioną fakturę". Receiving through KSeF is mandatory for all taxpayers from 1 February 2026; issuing is phased (1 February 2026 above PLN 200 million 2024 sales, 1 April 2026 for the rest, relief to end of 2026 for issuers under PLN 10,000 monthly). A domestic buyer with a NIP receives inside the system — the Ministry's guidance says such an invoice should not be handed over outside KSeF. Buyers outside the system (consumers, foreign taxpayers, entities without a NIP) get the invoice "w sposób uzgodniony" with a QR code that links back to the stored original. Offline modes exist for outages, with later submission within seven working days.
The trade-offs are the mirror image of Peppol's. There is one counterparty for every issuer, so there is no addressing problem and no provider market for transport — but there is also a single point of failure, a national-only schema (FA(3) is not an EN 16931 syntax), and no delivery to anyone outside Poland. For B2G, the Peppol-based PEF platform continues and is integrated with KSeF, according to the Commission's country sheet. See KSeF and FA(3).
France: approved platforms and the public directory
France chose a "Y" model: every business uses a plateforme agréée (PA) of its choice; the platforms exchange invoices with each other, look up the recipient's platform in the state-run directory (annuaire), and extract invoice data for the tax authority.
The DGFiP defines a PA as "un opérateur de dématérialisation qui a fait l'objet d'une procédure d'immatriculation par l'administration, pour une durée de trois ans renouvelable" and lists its roles: issuing, transmitting and receiving the electronic invoice from supplier to customer — converting it "dans un format qui convienne au client" where needed; extracting and transmitting invoice data to the administration; transmitting transaction data for operations without an e-invoice (e-reporting); and transmitting payment data. A software product that is not registered "ne sera donc pas autorisé à transmettre les factures électroniques aux plateformes des clients" — it may prepare invoices but must hand them to a PA. The obligations started on 1 September 2026; the administration's start-up guide notes that during the launch phase no sanctions apply to businesses on a serious compliance trajectory, while "cette approche ne constitue ni un report ni une suspension de l'obligation". The public platform (PPF) keeps the directory and the concentrator role towards the DGFiP rather than serving businesses directly.
Structurally this is a many-to-many network of accredited providers, like Peppol, plus two things Peppol lacks: a mandatory data feed to the tax authority and a state directory instead of the SML/SMP lookup. Several PAs also operate as Peppol access points, and the socle formats (Factur-X, UBL, CII) are EN 16931 syntaxes, so the two worlds interoperate technically even though French law does not recognise Peppol as a channel in its own right. See French platforms and Factur-X.
Germany: a format mandate without a network
Germany prescribes the format — EN 16931, in practice XRechnung or ZUGFeRD — and prescribes no transport, no platform and no reporting; the BMF FAQ states that an email inbox suffices to meet the receiving obligation.
The FAQ lists transport options without ranking them: email, electronic interfaces, shared access to a central storage location within a group, download from an internet portal, even transfer on a USB stick. There is no state directory for B2B. The only structured routing in Germany belongs to the public sector: the Leitweg-ID, the ZRE and OZG-RE portals and — for federal authorities — Peppol, run under the German Peppol Authority. Businesses that want automated exchange therefore either use Peppol voluntarily or agree bilateral channels with each customer.
The consequence is flexibility with friction. A German SME needs nothing beyond mail to be compliant today, but there is no lookup that tells it whether a customer can process an XRechnung UBL file, a ZUGFeRD PDF or only a plain PDF. The hybrid ZUGFeRD format exists for exactly this reason: it is readable by both. See XRechnung versus ZUGFeRD and receiving e-invoices in Germany.
Belgium: Peppol as the mandate
Belgium did not build a national system; it wrote the Peppol network into the law. The Commission's country sheet puts it bluntly: "Peppol is the primary format and transmission method in Belgium: no entity can solely decide to derogate to it."
The Belgian authority explains the mechanism to businesses in network terms: invoices "are exchanged directly between the two enterprises' software systems", the software "will establish a secure connection with this Peppol network to which your customer or supplier is also connected", and "sending a PDF invoice by e-mail or via a platform will no longer be enough". Peppol BIS Billing 3.0 is the default format; another EN 16931 format may be used only when both parties agree. The public sector's Mercurius mailroom is itself a Peppol endpoint, so B2G and B2B share one channel. The authority states it deliberately chose not to build a centralised platform and instead publishes a list of compliant software. E-reporting to the tax authority is planned for 2028, which would add a reporting layer without replacing the network.
Comparison table
The table reduces the four models to the questions a business actually asks: who carries the invoice, who validates it, whether the state sees it, and whether it reaches abroad.
| Question | Peppol (Belgium; optional elsewhere) | KSeF (Poland) | Approved platforms (France) | No network (Germany B2B) |
|---|---|---|---|---|
| Topology | Four-corner, decentralised, accredited access points | Central state system, one endpoint | Many registered private platforms plus a state directory and concentrator | Bilateral; any electronic means |
| Who validates the invoice | Sending and receiving access points against Peppol BIS rules | KSeF against the FA(3) schema; rejection means no invoice | The PA against the socle format rules; recipient's PA may reject | The recipient — nobody else |
| Addressing | Participant identifier (e.g. enterprise number) looked up via SML/SMP | NIP; buyer fetches from KSeF | SIREN/SIRET plus routing data in the annuaire | Email address or agreed interface |
| Formats | Peppol BIS Billing 3.0 (UBL); other document types and CIUS possible | FA(3) XML only | Factur-X, UBL, CII | Any EN 16931 syntax or agreed interoperable format |
| Tax authority in the path | No | Yes — issuance happens in the state system | Yes — PA extracts data for the DGFiP; e-reporting for other operations | No |
| Legal moment of issuance | When sent and received as agreed | When KSeF assigns the number | When transmitted by the PA (start-up guide: other channels tolerated during launch, then regularise) | When transmitted to the recipient |
| Cross-border reach | Yes — any registered receiver in any country | No — foreign buyers receive outside KSeF with a QR code | Domestic only; international operations go to e-reporting | Whatever the counterparty accepts |
| Provider choice | Any accredited access point | None for transport (software vendors integrate the API) | Any registered PA; a non-registered tool must hand over to a PA | Not applicable |
How KRONENWERK handles this
KRONENWERK generates the invoice in the format each network expects and hands it to the channel that country uses; the Peppol channel runs through an accredited access point provider, the French and Polish channels are not yet production-ready.
- Peppol — KRONENWERK sends and receives over Peppol through an accredited access point provider (Storecove) once the company is connected in Settings → Delivery. KRONENWERK is not a Peppol access point. SUPPORTED WITH LIMITATIONS
- Germany — XRechnung and ZUGFeRD generated and validated at issuance, delivered by email or download; the same files can also go over Peppol to a registered receiver. SUPPORTED
- France — Factur-X generation SUPPORTED; transmission through an approved platform NOT YET READY. KRONENWERK is not a plateforme agréée; transmission is planned through Storecove's approved-platform capability.
- Poland — FA(3) generation SUPPORTED WITH LIMITATIONS; the KSeF 2.0 module (token authentication, session, submission, UPO retrieval, receiving) is built but has not been used against the production KSeF. NOT YET READY
- Receiving — incoming XRechnung, ZUGFeRD/Factur-X and UBL files are read into bills regardless of the channel they arrived on. SUPPORTED
Developers integrating a network directly will find the Peppol integration and KSeF integration pages useful. Back to the Europe hub.
Frequently asked questions
Is Peppol mandatory in the EU?
No. Belgium made it the default channel for domestic B2B; Germany, France and Poland use it for B2G to varying degrees; for B2B elsewhere it is voluntary.
Can a Peppol invoice be delivered into KSeF?
Not as such. A Polish issuer must submit FA(3) XML to KSeF; Peppol can carry a copy to a foreign buyer but does not replace the KSeF submission.
Is a French plateforme agréée the same as a Peppol access point?
No. A PA is registered by the DGFiP and reports to it; an access point is accredited by OpenPeppol and reports to nobody. Some providers are both.
Why does Germany have no e-invoicing network?
German law prescribes only the format. The BMF FAQ accepts email, interfaces, portals and physical media as transmission; there is no reporting layer to require a network.
Which model will ViDA use in 2030?
The directive fixes the reporting obligation and the structured-invoice basis; the Commission has not yet issued the implementing rules that decide the channel.
Sources
- OpenPeppol — Peppol Interoperability Framework — read on
- European Commission — Peppol (Digital Building Blocks) — read on
- European Commission — eInvoicing in Belgium — read on
- FPS BOSA / efactuur.belgium.be — Structured electronic invoices between companies are compulsory since 2026 — read on
- DGFiP — Facturation électronique et plateformes agréées — read on
- DGFiP — Guide pratique de démarrage au 1er septembre 2026 — read on
- Ministerstwo Finansów — Zakres obowiązkowego KSeF — read on
- Ministerstwo Finansów — Tryb offline i kody QR — read on
- European Commission — eInvoicing in Poland — read on
- Bundesfinanzministerium — Fragen und Antworten zur Einführung der obligatorischen E-Rechnung — read on
- European Commission — eInvoicing in Germany — read on