The thesis: a supplier record either carries a Peppol identifier or it does not, and that field increasingly decides how fast onboarding goes.
E-invoicing has looked, for years, like a patchwork of country-specific formats and mandates that finance teams tracked one jurisdiction at a time. Peppol changes the shape of that problem. It is not a format; it is a routing network with one directory and a standard discovery process, so once a trading partner is registered with a participant identifier and an access point, any buyer or seller on the network can find and reach them without a new point-to-point integration project.
That is why the identifier belongs in the trading-partner master record next to the VAT number and bank details, governed the same way, rather than living in a project team’s spreadsheet from whichever country’s mandate prompted the last onboarding push.
What moved across four countries in 2026, without a shared regulatory driver.
Belgium’s live B2B mandate is the clearest proof of scale. The Peppol directory tracked 940,354 Belgian registrations in December 2025, passed one million by January 30, 2026, and reached 2,072,529 by June 2026, roughly 45.8 percent of a global network of 4,523,020 participants across more than 100 countries. Banks and accounting platforms auto-registering their client base drove most of that growth.
Australia took a procurement-policy route rather than a tax mandate. Non-corporate Commonwealth entities must source at least 30 percent of received invoices through the Peppol network by July 1, 2026, reach fully automated sending and receiving by December 2026, and report progress quarterly to the Australian Peppol Authority. Australia already carries roughly 430,000 network participants, the third largest count.
The UAE opened a voluntary pilot on July 1, 2026, for a decentralized, Peppol-based model in the PINT AE format. Large taxpayers with annual revenue of AED 50 million or more must appoint an accredited service provider by July 31, 2026, ahead of a mandatory start on January 1, 2027, with smaller businesses following by July 1, 2027 and government entities by October 1, 2027.
France, already second on the network with roughly 890,000 participants, had its tax administration, the Direction Générale des Finances Publiques, designated as the country’s national Peppol Authority in July 2025, ahead of its own 2026 B2B e-invoicing mandate. Four countries, four different regulatory paths: a live domestic mandate, a public-procurement policy, a voluntary pilot, and an authority appointment. What they share is one network, one routing model, and one identifier pattern.
Why this belongs in master-data design, not a compliance checklist.
The four-corner model keeps the integration work at registration rather than at every new trading relationship. Corner 1, the sender, hands an invoice to corner 2, its own certified access point. That access point resolves the recipient’s participant identifier against the network’s single central directory, which points to the recipient’s access point, corner 3, along with the document types it accepts and the certificate needed to deliver securely. Corner 3 completes delivery to corner 4, the recipient.
Once a supplier’s participant identifier is published to the directory, any buyer’s access point can discover and route to them without a bespoke connection. The one-time cost sits in registration and master-data quality: getting the identifier and scheme right, keeping the access-point endpoint current, and confirming which document types the partner actually accepts. Get that record right once, and the marginal cost of the next country’s mandate looks like a data update rather than a new integration project.
The trading-partner record procurement and AP teams can build around.
A trading-partner record should carry the participant identifier and scheme, the access point currently serving it, the document types confirmed as accepted, and the onboarding verification method, alongside a defined fallback channel for partners the network cannot yet discover.
Example trading-partner record
{
"trading_partner_id": "tp_2026_07_00931",
"legal_name": "Example Supplier B.V.",
"peppol": {
"participant_id": "0106:987654321",
"scheme": "national business register",
"access_point": "certified-ap.example.com",
"document_types_accepted": ["Invoice-2.1", "CreditNote-2.1"],
"network_registered": true,
"last_verified_at": "2026-07-20T09:00:00Z"
},
"onboarding": {
"status": "VERIFIED",
"verification_method": "DIRECTORY_LOOKUP",
"verified_by": "ap_ops_412",
"fallback_channel": "EMAIL_PDF"
},
"evidence_ref": "s3://vendor-master-evidence/2026-07/tp_2026_07_00931/"
}The structure holds regardless of which country’s mandate prompted the onboarding. What changes over time is the partner’s access point, its accepted document types, and whether it needs re-verification, all of which belong on the record rather than in a separate compliance tracker.
Control design for Peppol-based supplier onboarding.
| Area | Design pattern | Evidence |
|---|---|---|
| Participant identifier capture | Capture the Peppol participant identifier, its scheme, and the register it derives from as a required field on the trading-partner record, not a note in an onboarding email. | Participant ID, scheme code, source register, capture date, capturing user. |
| Access point registration | Confirm which access point serves each participant identifier and store its endpoint, so a change in a supplier’s provider does not silently break delivery. | Access point endpoint, provider name, certificate reference, last confirmed date. |
| Document type capability | Record which document types, invoice, credit note, order response, the partner actually accepts, since network registration alone does not guarantee every message type is supported. | Document type list, confirmation source, confirmation date. |
| Discovery verification | Run a lookup against the network at onboarding and on a fixed cadence afterward, rather than trusting a one-time registration screenshot from the supplier. | Lookup timestamp, directory response, match result, owner. |
| Fallback channel | Define what happens when discovery fails: a PDF and email path with its own matching rules, not a silent queue nobody watches. | Fallback trigger, channel used, manual match log, resolution owner. |
| Cross-border scheme mapping | Map each country’s identifier scheme, VAT number, national business register, tax ID, to the participant ID a partner actually uses, since one legal entity can present different identifiers by jurisdiction. | Scheme code, mapped legal identifier, mapping source, reviewer. |
| Re-verification cadence | Re-check active trading-partner records against the network on a schedule, since access points and accepted document types can change without notice to the buyer. | Re-check date, prior state, current state, change owner. |
| Audit evidence | Keep the registration lookup, the access point confirmation, and any fallback decision attached to the trading-partner record, so an auditor can see why onboarding was accepted. | Lookup record, confirmation record, fallback log, retention period. |
The most important design choice is treating discovery as a recurring check, not a one-time gate. Access points and accepted document types can change on a partner’s side without any notice reaching the buyer, so a record verified at onboarding and never checked again will quietly drift out of date.
Implementation checklist for procurement and AP operators.
Inventory every trading partner already reachable on Peppol versus off-network, and note which ones your ERP still onboards through a manual PDF or portal process.
Add a Peppol participant identifier and scheme field to the trading-partner master record if it does not already exist, positioned next to the VAT number and bank details.
Confirm with your ERP or AP-automation vendor whether they operate their own access point or integrate with a certified provider through an API, since that answer sets your actual integration path.
Run a test lookup against a handful of real suppliers to see what document types and access point they are actually registered for today.
Build the fallback path deliberately: define what happens when a partner is not discoverable, rather than letting failed lookups default to email by accident.
Watch the Australian government threshold and the UAE pilot as leading indicators. Suppliers selling into either market will need a working participant identifier well before a broader domestic mandate reaches your own country.
Set a re-verification cadence for active trading partners, since a supplier can change access point providers without notifying every buyer on the network.
Confirm retention requirements with audit: the registration lookup, access point confirmation, and any fallback decision should be retrievable from the trading-partner record.
Sequence this by trading-partner concentration in countries already active on the network. Suppliers and customers touching Belgium, France, Australia, or the UAE are the fastest path to a working, tested identifier field before a domestic mandate makes it urgent everywhere else.
Audit evidence should live on the trading-partner record, not a project folder.
Good onboarding evidence lets an auditor start at a trading-partner record and see exactly why it was accepted: the directory lookup performed, the access point and document types confirmed, and, where discovery failed, the fallback decision and who made it. When onboarding stays in the deployment team’s project files instead of the master record, that chain disappears the moment the project closes.
Retention should sit close enough to the supplier or customer record that finance can answer a question about how a partner was onboarded without reopening a rollout project from a prior year.
Constructive failure modes to design around.
Treating the Peppol participant identifier as a one-time compliance checkbox instead of a master-data field that gets the same governance as a VAT number or bank account.
Assuming network registration guarantees a partner accepts every document type your ERP wants to send, when the accepted set can be narrower.
Building a single hardcoded integration with one access point provider instead of treating access-point choice as a routing decision that can change.
Letting a failed discovery lookup drop into a black hole instead of a defined fallback channel with its own matching and audit trail.
Waiting for a domestic mandate to arrive before building any of this, when trading partners in Belgium, France, Australia, or the UAE may already need it for outbound business.
Duplicating the same supplier under multiple identifiers because different business units captured different schemes for the same legal entity.
Each of these is a design prompt rather than a reason to wait. The network already reaches more than 4.5 million organizations; the work is capturing the identifier correctly and keeping the record current as partners and mandates evolve.
What procurement and AP teams should ask ERP vendors now.
Does the platform operate its own certified Peppol access point, or does it integrate with one through an API, and what does that mean for onboarding time?
Can it store the participant identifier, scheme, and accepted document types as structured fields on the trading-partner record?
Can it run a discovery lookup at onboarding and on a recurring schedule, and alert when a partner’s access point or accepted document types change?
What is the defined fallback path when a partner cannot be discovered on the network, and how does that fallback data get reconciled later?
Can it map multiple national identifier schemes, VAT number, business register number, tax ID, to the same legal entity without creating duplicate supplier records?
Can an auditor retrieve the registration lookup, access point confirmation, and any fallback decision directly from the trading-partner record?
A credible vendor answer should describe a structured trading-partner record, a recurring discovery check rather than a one-time lookup, and a fallback path with its own evidence trail, not a general claim about e-invoicing readiness.
Practical takeaway.
The Peppol network’s growth through Belgium’s live mandate, Australia’s government threshold, the UAE’s voluntary pilot, and France’s authority appointment does not point to any single country’s rule. It points to a routing pattern that already reaches more than 4.5 million organizations. Trading-partner records that carry a governed participant identifier and access-point field today will absorb the next country’s mandate as a data update, not a project.
Sources.
- Australian Taxation Office: eInvoicing for government
- Fiscal Solutions: Australia eInvoicing Mandate, A Concise Overview
- Fiscal Solutions: UAE to Launch E-Invoicing Pilot in July 2026
- Gulf News: UAE to launch pilot phase of electronic invoicing system in July 2026
- Comarch: France Designates DGFiP as Its National Peppol Authority Ahead of 2026 B2B E-Invoicing Mandate
- e-invoice.be: Peppol statistics, June 2026
- e-Rechnung Bund: Peppol technical solution, the four-corner model
- OpenPeppol: About Peppol
Targeted searches for public X and Twitter commentary on the 2026 Peppol network growth, the Australian government threshold, and the UAE pilot returned mostly vendor marketing posts rather than commentary from a regulator, network operator, or independent practitioner. That falls short of a credible set of two to four high-signal posts, so this article uses the primary and near-primary sources above instead of an embed.