European Business Wallet Peppol integration: what changes in your implementation

Anyone who builds or maintains Peppol connections has been fielding the same boardroom question since November 2025: do we need to do something about this European Business Wallet? The honest answer is that European Business Wallet Peppol integration forces no line of code today, while bearing on design decisions you are making now and would have to buy back expensively later. This article covers the four places in an existing Peppol implementation where the wallet actually lands, and what you can and cannot reasonably anticipate.

Two topics are deliberately left aside because they have been covered elsewhere. The architectural core, meaning how the wallet could in principle solve the addressing problem in cross-border e-invoicing, is set out in the analysis of the three-layer problem. How Peppol transport relates to qualified electronic registered delivery is covered in the article on QERDS and the European Business Wallet. What follows is the integration layer above both.

Why this belongs on the roadmap now rather than later

The position on 5 September 2026 is sober. The Council adopted its negotiating mandate on 9 June 2026. The European Parliament has not yet fixed its own position: procedure file 2025/0358(COD) sits at “awaiting committee decision”, with a draft report dated 1 April 2026, amendments tabled on 23 April 2026, and opinions from IMCO and JURI in early June 2026. Trilogues have therefore not begun. Formal adoption is expected in early 2027 at the earliest, after which public sector bodies get two years to accept the wallet’s core functions. In practice: an acceptance obligation that only bites around 2029, and technical detail that will mostly live in implementing acts that do not yet exist.

None of that is an argument for waiting. It is an argument for not building a wallet connector while getting your data model straight. The design decisions that will hurt are not about protocols but about assumptions: that a company has one identifier, that the right to use that address is a contractual arrangement, and that a received invoice may be discarded once mapped. Those three sit inside almost every ERP connection built in the last decade, and the wallet puts pressure on all three.

One further structural factor matters. Use of the wallet remains voluntary for businesses, while public authorities must accept it. That asymmetry means you can never assume every counterparty holds a wallet, so every integration has to support two paths permanently. That is not a transitional state but the end state.

Identity and identification: a new identifier, not a new address

Peppol identifies participants through a Participant Identifier in the form scheme::value, where the scheme comes from the code list maintained by OpenPeppol. In the Netherlands that means 0106 for the Chamber of Commerce number, 0190 for the government OIN and 9944 for the VAT number. The Netherlands Peppol Authority (NPA) requires Dutch entities to hold an SMP registration for SI-UBL 2.0 and Peppol BIS Billing 3. The code list itself is a living document: version 9.7 is dated 2 July 2026 and holds 105 schemes, and OpenPeppol states explicitly that it is a dynamic list.

The proposal for the European Business Wallet anchors identification of the wallet holder on the European Unique Identifier, the EUID from the interconnected business registers system. That is an existing identifier grounded in EU law and issued per country by the national business register. The EUID does not currently appear in the Peppol participant identifier scheme list.

Two outcomes are plausible. In the first, a scheme for the EUID is added to the Peppol code list, after which a participant can register an EUID address alongside its existing one. In the second, the wallet presents an identifier that already exists, such as the Chamber of Commerce or VAT number, as a verified attribute. Then nothing changes at identifier level, but the provenance does: where a customer types a number into a form today, a verifiable claim from an authentic source arrives instead.

What changes in your implementation. In both scenarios the critical assumption is the same: one company does not equal one Peppol address. If your data model holds the Peppol identifier as a field on the customer record rather than as a separate table with scheme, value, provenance, evidence and validity dates, that is the first refactor worth doing. The distinction between the routing address in cbc:EndpointID and the legal identification in cac:PartyLegalEntity also sharpens once multiple verified numbers circulate. Code lists belong in your system as data, not as enumerations in source code: every hard-coded 0106 or 9944 is a release you will have to schedule later.

What is settled: the EUID exists and is the anchor for identification in the proposal. What is likely: the Peppol code list gets extended, because that is precisely what the list is for. What remains open: whether a wallet will ever carry an e-invoicing endpoint as an attribute. That is a policy choice for the implementing acts, and it has not been made.

Attestations and mandates: evidence where an arrangement stands today

This is where the wallet adds most, and also where most implementations are weakest. Today the question of whether a customer may use a given Peppol address rests on the Peppol Service Provider agreement. The Policy for use of Identifiers obliges the service provider to maintain suitable governance of identification schemes when entering, updating and deleting SMP information, but prescribes no verification procedure. In practice that means a register extract, a signed form, or an email from a known domain: contractual evidence that varies per provider and is not machine readable.

The wallet brings two things here. First, electronic attestations of attributes, the instrument introduced by eIDAS 2.0 through Regulation (EU) 2024/1183, including qualified attestations and attestations issued by or on behalf of a public sector body responsible for an authentic source. Second, digital management of representation rights and mandates, which the proposal lists as an explicit function. The Council added in its mandate that the authorisation system leaves existing mandate law untouched and that national procedural requirements continue to apply, which deliberately limits the legal effect.

What changes in your implementation. Onboarding becomes verifiable instead of asserted. That is only cheap if the evidence already has a home in your system. Concretely: record per identifier which source supplied the evidence, which document it was, on what date, who accepted it and how long it is valid. Anyone handling that today as a free-text field plus a PDF in a ticketing system will have to rebuild onboarding when attestations arrive. Anyone who models it as a typed evidence object simply adds one more evidence type.

The same applies to representation. An accounting firm sending on behalf of two hundred clients is, in most systems, a user account with permissions. That is not a mandate. Model explicitly that entity X may send documents of type Z on behalf of entity Y until date D, independently of which user signs in. Once that exists as data, a verifiable mandate from a wallet populates the record rather than replacing it. Within WE BUILD, “Company Representative acting on behalf of a Company” is one of the thirteen use cases.

What remains open is substantial: whether OpenPeppol will accept wallet attestations as valid evidence for SMP registration, whether that arrives as policy or as an option, and how revocation is handled. Assume a refresh model will exist and give your evidence object an expiry date.

Signing and sealing: where that fits the existing flow

In today’s Peppol chain, documents are not signed at document level. Trust comes from transport: AS4 messages are signed with certificates from the Peppol PKI, and the receiver trusts its accesspoint. UBL has a slot for a signature, but Peppol BIS Billing 3.0 does not use it. That is defensible in tax terms, because Article 233 of the VAT Directive lets each taxable person decide how to ensure authenticity of origin and integrity of content, and names business controls creating a reliable audit trail as a route in its own right. Advanced electronic signatures and EDI are examples there, not requirements.

The wallet adds digital signing, timestamping and sealing as a core function. Under eIDAS, a qualified electronic seal enjoys the presumption of integrity of the data and of correctness of the origin of that data. Transport security proves a message arrived through a trusted channel; a seal proves something about the document itself, including after it has left the network.

What changes in your implementation. Two things, and the second is the expensive one. First, a validation step appears: someone has to check the seal, consult the trust list, establish revocation status at the moment of receipt and retain the validation report. Long-term validation is a genuine cost line, because a seal that cannot be validated seven years from now proves nothing in a dispute.

Second, and this is the cheapest measure in the whole article: keep the original received payload, not only the mapped fields. Many ERP connections normalise incoming UBL into internal records and discard the bytes. A normalised invoice can no longer be verified against a signature or seal, because every byte counts. Store the original payload with a hash and the transport metadata. That costs storage today and cannot be repaired retroactively.

What remains open: whether sealed documents will travel over Peppol at all or over the wallet’s own secure channel, and whether OpenPeppol would permit or require an embedded signature in BIS. Nothing has been decided. The secure channel question leads directly into the QERDS discussion covered in the companion article referenced above.

What the wallet expressly does not replace

It is tempting to read the wallet as a new network. It is not.

• The Peppol transport model stays. The proposal concerns identity, attestations, signing, representation and a secure channel. It defines no routing network with SMP and SML lookup, capability discovery and document type negotiation. Peppol answers whether a receiver can process a BIS Billing 3.0 invoice, at which endpoint and with which certificate. A wallet answers who someone is and what they can prove. Only at the lookup layer do those questions genuinely meet.
• The document standards stay. EN 16931 remains the semantic model, Peppol BIS Billing 3.0 remains its implementation, and the European VAT reform anchors that direction further. A wallet has no opinion about invoice lines, VAT categories or allowances.
• The role of the Peppol Serviceprovider stays. Validation, mapping, error handling, monitoring, processing of message level responses, maintaining code lists, meeting Peppol Authority requirements and archiving do not disappear. A wallet adds an identity source, not middleware.

The only layer the wallet could genuinely displace is addressing and lookup, and that is exactly the subject of the three-layer article referenced earlier. Anyone promising more than that is anticipating decisions that have not been taken.

European Business Wallet Peppol integration: what you can do now

Everything below is useful regardless of what happens in the trilogues. That was the selection criterion.

1. Decouple business identity from Peppol address. One party record with multiple identifiers, each carrying scheme, value, source, evidence, start date and expiry date.
2. Treat the Peppol code lists as data. Version 9.7 of 2 July 2026 is not the last one. No enumerations in source code, and a documented update cadence.
3. Make onboarding evidence machine readable and typed: which source, which document, which date, who accepted it, valid until when.
4. Model representation as a first-class record, separate from user accounts and roles.
5. Retain the original received and sent payload with a hash and transport metadata, alongside the mapped data.
6. Isolate validation behind a single interface, so schema, Schematron and any future seal validation are steps in one chain rather than separate constructions.
7. Support multiple identifiers per receiver in your lookup logic, with an explicit cache TTL and a defined fallback.
8. Assign one person to follow OpenPeppol code list releases, the WE BUILD eInvoicing use case and the Parliament file. One person, not a working group.
9. Ask your Peppol Authority for its position before forming your own.

What you should not commit to yet. Do not build a wallet connector: the architecture framework profiles and implementing acts are not there. Do not assume an e-invoicing endpoint will be a wallet attribute, because that is still an open policy choice. Do not choose between “the wallet replaces the SMP” and “the wallet feeds the SMP”, because both variants are live. Do not design archiving that presupposes mandatory seals. And make no contractual commitment to customers about wallet compatibility while the regulation has not been adopted.

Questions to put to your supplier as a business

You do not need the technical detail above to test whether your supplier is preparing. These eight questions are enough, and the quality of the answer tells you more than the answer itself.

• Can you hold multiple Peppol identifiers per entity, and what happens in your system if we acquire an extra one?
• Do you retain the original received invoice files or only the processed data, and can I export those originals?
• How do you record that we are entitled to use our Peppol address, and how would you handle a digital attestation from a business register?
• How is it arranged that our accounting firm sends on our behalf: as a recorded mandate with an end date, or as an account permission?
• How frequently do you adopt new versions of the Peppol code lists, and how do we notice?
• Who at your organisation follows the wallet file, and what is your position on European Business Wallet Peppol integration?
• What costs would a wallet connection be expected to carry, and does that fall within our current contract?
• What happens in your solution if a counterparty works with a wallet and we do not, or the other way round?

More on the political timeline is set out in the article on the trilogue on the European Business Wallet, and for broader context there is the European Business Wallet hub page.

Sources

1. Proposal for a Regulation on the establishment of European Business Wallets, COM(2025) 838 final, EUR-Lex
2. Procedure file 2025/0358(COD), European Parliament Legislative Observatory
3. Council of the European Union, European business wallets: Council adopts negotiating position, 9 June 2026
4. European Commission, European Business Wallets policy page
5. Regulation (EU) 2024/1183 amending Regulation (EU) No 910/2014 as regards establishing the European Digital Identity Framework
6. OpenPeppol eDEC Code Lists, version 9.7 of 2 July 2026
7. Peppol EDN Policy for use of Identifiers, version 4.4.0
8. Netherlands Peppol Authority, Use of Peppol in the Netherlands
9. Council Directive 2006/112/EC on the common system of value added tax, Article 233
10. WE BUILD Consortium, overview of the thirteen use cases

European Business Wallet Peppol integration is not yet an implementation assignment, but it is already a selection criterion. A supplier that handles multiple identifiers per entity, retains original documents and records mandates explicitly will be cheap to connect later. A supplier that does not will be rebuilding its onboarding. On the independent Peppol Serviceprovider comparison on Peppol.now you can filter by software environment, invoice volume, target countries and company size, so you put these questions to the right parties.