Peppol e-invoicing for B2B platforms: the architecture
A B2B customer in a Nordic or EU market asks for invoices over Peppol, and the engineering team’s first instinct is to format a nicer PDF. Peppol e-invoicing works through a network rather than an attachment, so that instinct quietly points in the wrong direction. The real task is integration: producing a structured document, reaching the network through an access point, and fitting an invoice-based flow into an order lifecycle that may only ever have handled card payments.
Peppol is an international network for exchanging structured business documents, including electronic invoices, between separate organizations and their software. A sender hands an invoice to an access point, which delivers it to the recipient’s access point on the network, so no two parties have to build a direct connection. For a B2B platform, supporting it is less about how the invoice looks and more about where each piece sits in the system.
This is an integration walkthrough, vendor-neutral by design, written for teams that need to understand how Peppol fits their platform without becoming Peppol specialists. The reference points come from a Norwegian marketplace whose chain customers are invoiced over EHF, the local Peppol format, with each invoice handed off to downstream accounting. By the end you should know what a Peppol-ready invoice flow involves and which decisions are yours to make.
What Peppol is, in system terms
Peppol is two things working together: a delivery network and a set of standard document formats. The network lets separate organizations exchange structured business documents — invoices, credit notes, orders — without each pair building a custom connection. The formats make sure a document produced by one system can be read by another, regardless of the software on either end.
The network runs on a four-corner model. The sender (corner one) connects to an access point (corner two); that access point looks up the recipient through the network’s discovery services and delivers the document to the recipient’s access point (corner three), which passes it to the recipient (corner four). OpenPeppol describes this in its Peppol interoperability framework, including the SML and SMP discovery layer that lets any participant find any other.
peppol-four-corner-invoice-flow
In the Peppol four-corner model, a B2B platform sends a structured invoice through an access point rather than connecting directly to the buyer.
The format that matters for invoicing is Peppol BIS Billing 3.0, a UBL-based XML document that is a constrained version of the European standard EN 16931. In Norway the local profile is EHF, which layers national rules on top of BIS Billing 3.0 — the same standard underneath, with country-specific requirements added.
Where the access point sits in your architecture
Your platform does not connect to Peppol directly; it connects to an access point that connects to the network on its behalf. An access point is a certified provider that handles the transport, the addressing, and the delivery, so your system’s job narrows to producing a valid document and exchanging it with the access point in both directions.
Building your own access point is possible but rarely worth it, because it means operating certified network infrastructure that a provider already runs. Most platforms integrate with one. What stays firmly on your side is the document: the access point validates what you send, and an invalid invoice is rejected before it reaches the recipient, so producing correct output is your responsibility. It helps to be explicit about which side owns what:
Generating a valid structured invoice
The platform’s real work in a Peppol integration is producing an invoice that passes validation, because the network enforces the standard strictly. A Peppol BIS Billing 3.0 document is structured XML with mandatory fields and rules drawn from EN 16931, and the access point rejects anything that does not conform. A valid invoice needs several things in place:
- correct participant identifiers for sender and recipient, so the network can route it
- the mandatory semantic fields defined by EN 16931 — parties, line items, tax, and totals
- valid UBL syntax, the XML structure Peppol expects
- conformance to any national rules layered on top of the base standard
In Norway those national rules are EHF, the local profile maintained by the public-sector authorities and documented in the EHF Billing 3.0 specification. The practical implication is that generating the document is not a templating step; it needs validation against the rules before it is sent, ideally in your own pipeline so you catch errors before the access point does.
If you are scoping Peppol support and unsure where document generation ends and the access point begins, that boundary is worth drawing early. Our integration engineers have built EHF invoice flows that pass validation and hand off cleanly to accounting, and can map the same for your stack.
How invoicing reshapes the order lifecycle
Choosing invoice-based billing changes the order lifecycle, not just the document at the end of it. A card-at-checkout flow collects payment up front and then fulfils. An invoice flow runs in a different order: the order is placed, the goods are fulfilled, an invoice is generated and sent over Peppol, and the customer pays afterward against agreed terms. Delivery before payment is a direct consequence of the invoicing model rather than a feature bolted on afterward.
That sequence forces the order lifecycle to treat several stages as distinct:
- the order is placed and accepted
- it is fulfilled and delivered
- an invoice is generated, validated, and sent over Peppol
- the downstream accounting system books it as a receivable
- the customer pays later, and payment is reconciled against the invoice
This is the same structural shift any B2B channel imposes, which is why Peppol support and a B2B model tend to arrive together. The broader decisions around running B2B and B2C on one platform — negotiated pricing, chain hierarchies, invoice lifecycles — set the context that Peppol then plugs into.
Handing the invoice off to accounting
The invoice does not end when it reaches the recipient; on your side it has to reach the systems that record and reconcile it. Once an invoice is generated, its data flows to the accounting system that books the receivable, tracks its status, and later matches it against payment. On the Kortreistved chain-customer invoice flow, invoices generated for chain customers are exported to the downstream accounting system, which then carries the receivable and the reconciliation.
PowerOffice is one example of such an accounting system, and the pattern holds regardless of which one you use: the platform generates and sends the structured invoice, and a separate system owns the books. Keeping that boundary clean matters, because status has to flow back — whether an invoice was sent, accepted, or paid, plus any credit notes — so the platform and the accounting system stay in agreement about where each order stands.
Why this is a global concern now, not only a Norwegian one
Peppol started as a European public-procurement project, but it has become a global B2B standard, which changes the economics of building for it. A platform that can produce and send Peppol documents for one market can usually extend to the next with a different local profile rather than a rebuild.
Norway and the wider EU sit on EN 16931. Australia adopted Peppol in 2019, with the Australian Taxation Office acting as the national Peppol authority. Japan built its qualified-invoice e-invoicing on Peppol as well, through the Digital Agency’s JP PINT specification, the Japanese profile of the international Peppol billing standard. Each market adds local rules on top of the same foundation, so most B2B e-commerce platforms that invest in Peppol once can reuse the core across regions.
Key takeaways
- Peppol e-invoicing is a delivery network plus a set of document standards, so supporting it is an integration task rather than a change to how invoices look.
- Your platform connects to an access point, not to Peppol directly; the access point handles transport and delivery while you generate valid documents.
- A valid invoice means Peppol BIS Billing 3.0 (EHF in Norway) conforming to EN 16931, validated before it is sent.
- Invoice-based billing reshapes the order lifecycle, separating fulfillment, invoicing, and payment, with delivery happening before payment.
- Peppol is now used across the EU, Australia, Japan, and beyond, so building for it once lets a platform extend to new markets with local profiles.
Building Peppol in once, and reusing it across markets
Peppol e-invoicing rewards teams that treat it as architecture from the start. The document standard is the visible part, but the decisions that matter are where the access point sits, how the order lifecycle separates invoicing from payment, and how invoices hand off to accounting.
Get those boundaries right for one market, and the same structure extends to the next as Peppol spreads across the EU, the Asia-Pacific, and beyond. The teams that struggle are usually the ones that treated it as a formatting change and then found the order flow had to move underneath them.
If you are adding Peppol support to a B2B platform and want the boundaries drawn before the build, a short review will save a round of rework. Map your Peppol integration.
FAQ
Interesting For You
Code freeze: release management for seasonal peaks
Two things tend to surprise teams new to this. First, for a seasonal business the freeze rarely fits in a long weekend around Black Friday; it can run for months, as long as the peak itself. Second, the freeze reshapes the roadmap, because anything large has to land before it starts. The examples here come from a seasonal firewood marketplace whose peak runs through autumn and winter, with the rest of the year reserved for the bigger work.
Read article
Dynamic route optimization when indexes aren't enough
This is an engineering case rather than a tutorial. It draws on a Norwegian firewood-delivery marketplace where route recalculation dropped from five-to-seven seconds to under one, and a multi-condition availability query fell from three-to-five seconds to about one. The numbers matter less than the reasoning behind them: how to tell when the answer is a better algorithm, when it is caching, and when it is simplifying the work itself.
Read article
B2B B2C hybrid commerce without breaking B2C flows
The build that follows draws on a Norwegian firewood marketplace that runs a consumer webshop and a chain-customer webshop on the same platform. By the end, you should be able to decide where chain hierarchies, per-account pricing, and invoice-based order lifecycles belong in your own system, and where bolting them onto consumer flows will cost you later.
Read article