Technical explainer: what stops being retyped—and what people must still decide.
Electronic invoicing is sometimes presented as though business data first became machine-readable with the latest public programme. That misses the continuity with electronic data interchange, or EDI. I have previously implemented EDI, and that experience is one reason I support the direction of travel. The valuable idea is not new: exchange agreed data so that the receiving organisation does not have to reconstruct it manually.
What deserves attention is how a shared network and a governed set of specifications can make that idea easier to use across trading relationships. Peppol should be judged on that contribution, not on an imagined ability to make every accounting, tax and commercial problem disappear.
EDI was already about structured exchange
The United Nations Economic Commission for Europe describes UN/EDIFACT as internationally agreed standards, directories and guidelines for exchanging structured data between independent computerised information systems.6 That definition matters. EDI is not synonymous with scanned documents, and its history is not simply a history of proprietary formats.
A useful comparison therefore separates the document from the connection. Two organisations may understand an agreed message yet still need to arrange identification, transport, business rules, error handling and operational support. Standardising one part does not necessarily standardise the whole relationship.
Peppol’s framework explicitly combines governance and architecture: agreements, policies, requirements and technical specifications.3 Its contribution is broader than choosing a new syntax for an invoice. It creates a common setting within which different providers can deliver interoperable services to their own customers.
This is also why “EDI versus Peppol” can be an unhelpful opposition. A business may preserve mature EDI workflows for established relationships while adding Peppol reach for others. The practical question is which process should carry which document and how the organisation avoids duplicate or inconsistent records during coexistence.
Three kinds of agreement
First, systems need agreement about meaning. A due date is not a delivery date. An invoice reference is not necessarily an order reference. A quantity means little unless the unit is understood. Treating these as explicit business concepts is more important than making the file look familiar to a human reader.
Second, systems need agreement about representation and validation. The May 2026 release of Peppol’s Billing 3.0 documentation provides invoice and credit-note syntax, business rules, code lists, examples and validation resources.5 These are concrete implementation tools. They help a sender discover that a document does not conform before it becomes someone else’s unexplained processing failure.
Third, participants need agreement about delivery and trust. OpenPeppol describes Access Points, addressing and capability lookup, a Service Metadata Locator and public-key infrastructure as core elements of the network.3 Those elements answer different questions: where to send, what the recipient supports and which service providers participate in the trusted environment.
A reform that explains only XML tells businesses too little. XML is a way to represent data; it does not itself settle what the data means, who receives it or how a failed exchange is resolved.
Following a hypothetical invoice
Consider a hypothetical component distributor supplying a machine-repair company. The distributor’s sales system records an order for replacement bearings. Its invoice contains the buyer’s identifier, an order reference, the delivered quantity and the agreed price. No actual company or measured outcome is implied by this example.
The seller’s system creates a document compatible with the supported billing specification and passes it to its service provider. In Peppol’s four-corner model, the supplier and customer occupy the outer corners and their respective providers the middle corners; providers exchange the message through the network.3
The sending provider uses discovery information to locate the receiver’s capabilities and destination. OpenPeppol’s description distinguishes the central locator, which identifies the relevant metadata service, from the metadata lookup that provides receiving information.3 It is better to think of this as finding an address and supported service than as depositing every invoice in a single central mailbox.
On arrival, the buyer’s system can compare the invoice with its order and goods receipt. If the quantity is correct but the price differs, that becomes an exception for a person. If the order reference is missing, the invoice may need routing rather than automatic booking. Standardised exchange enables this workflow; it does not supply the missing commercial facts. Import and matching do not themselves determine the accounting period, asset treatment or entitlement to deduct VAT; those decisions depend on the transaction and applicable rules.
What “connect once” does and does not mean
OpenPeppol describes the network principle as connecting to one provider to reach senders and receivers across the network.3 That is a substantial advantage over a situation in which a buyer can demand that every supplier use the same isolated service.
But network reach is not identical to effortless integration. A business still needs to connect its own software, maintain identifiers, understand supported document types and decide how to handle exceptions. Changing an Access Point may be straightforward at the network layer while requiring work in the local application or contract.
For the hypothetical distributor, “connect once” should mean that a new network participant does not automatically require another bespoke transport relationship. It should not mean that every new customer accepts the distributor’s product codes, order conventions or accounting decisions without agreement.
The distinction prevents disappointment. It also gives procurement teams a better question than “Do you support Peppol?” Ask which documents and versions are supported, where validation occurs, what the integration exposes and how the system reports errors to ordinary users.
Automate exceptions, not just the happy path
A useful demonstration should begin with a normal invoice, then deliberately change the conditions. Send a duplicate. Supply an incorrect buyer reference. Correct a previously issued document. Make the receiving application unavailable and observe what happens when it returns.
These are proposed acceptance tests, not claims about tests I have performed. Their purpose is to reveal where the operational responsibility sits. Does a user receive an actionable explanation? Is a retry safe? Can the accountant see whether two messages represent one commercial invoice or two separate obligations?
Businesses should distinguish transport acknowledgement from commercial acceptance. The fact that a message reached a system does not establish that goods were delivered, that the customer agrees with the price or that payment has been authorised. A structured response process may improve communication, but its availability and meaning must be confirmed for the actual product and trading relationship.
Similarly, the possibility of machine processing is not a reason to delete human-readable access. A business must be able to inspect the document it issued or received, explain it to another party and preserve the relationship between the source record and later corrections.
The limits of standardisation
The strongest counterargument to enthusiastic Peppol adoption comes from organisations with functioning EDI arrangements. They may already have deep order, logistics and invoice integration. Replacing a stable process merely because another channel is fashionable could create cost without a matching business benefit.
That objection should be answered through migration design, not dismissed as resistance. Map existing message coverage. Identify trading partners reachable through each route. Prevent duplicate invoice creation and define a canonical business record. Preserve useful automation instead of narrowing a rich workflow to a single outgoing tax document.
There is also no universal saving that can be honestly promised to every business. A high-volume invoice receiver with repetitive data entry may gain differently from a small firm issuing a few complex service invoices. Integration cost, exception rates and existing software quality will affect the outcome. No percentage saving is asserted here.
Buy the outcome, preserve the option to leave
A sensible implementation brief should test the end-to-end process, with separately priced acceptance responsibilities: the delivery provider demonstrates transport and its observable confirmations; the integrator demonstrates import and error handling; the business and accountant demonstrate matching and approval. A transport-only provider is not responsible for another company’s accounting system or the truth of the sale. Require sample invoices and corrections to survive export and re-import. Specify how identifiers and historic records remain accessible if the provider relationship ends. Make responsibility for support visible across the accounting vendor and the network provider.
For a pilot, record the work before and after: manual fields entered, time spent resolving a rejected document, duplicate handling and the steps needed to onboard a new partner. These are proposed measurements, not published results. They can show whether interoperability reaches the employee’s desk or stops at the provider boundary.
The case for Peppol is strongest when it is precise. It builds on the longstanding logic of EDI with a governed interoperability framework and network reach.36 It can support better business processes, but it cannot replace commercial judgement or repair poor source data by itself. That realistic case is more persuasive than promising a frictionless digital future—and more useful to the businesses expected to implement it.
Sources
[3] OpenPeppol: Peppol Interoperability Framework