WE BUILD European Business Wallet pilot: from design decisions to implementation

The WE BUILD European Business Wallet pilot has left the stage where everything still lived on paper. On 10 and 11 June 2026 participants met at the Netherlands Chamber of Commerce in Amsterdam to settle the outstanding decisions before the thirteen use cases actually go into piloting. In early August the first two public pilot design deliverables appeared. For anyone who builds, sells or operates e-invoicing software, that is the point where this becomes worth watching, not because the regulation is finished, but precisely because it is not.

This article sets out what is happening inside the pilot, which of the thirteen use cases touch the e-invoicing chain, how the pilot relates to a legislative file that is still open, and what a service provider, software vendor or large sender can do about it right now.

Why a pilot carries more weight than a draft article

The proposal for a Regulation establishing European Business Wallets, COM(2025) 838 final, has been on the table since 19 November 2025. The Council adopted its negotiating mandate on 9 June 2026. The European Parliament has not adopted its position at the time of writing: the file sits with the ITRE committee, with Eero Heinäluoma (S&D) as rapporteur, and the IMCO and JURI opinions were adopted in early June 2026. Trilogues can only start once Parliament has its position.

So the legal text can still move. The technical substance moves far less. A large scale pilot forces real choices simply to get anything running: which attestation format, which company identifier, which protocol for issuance and presentation, who may verify and on what basis. Those choices land in architecture decision records, conformance specifications and rulebooks, and they are checked in an interoperability test bed. Whatever survives becomes the de facto reference model within two years, including for organisations that never took part.

The European Business Wallet (EBW) will be voluntary for companies, while public sector bodies must accept it within two years of entry into application. That asymmetry makes the reference model more consequential, not less: the public side will arrive with a fixed way of verifying, and your software either matches it or works around it.

What WE BUILD is and who takes part

WE BUILD is a large scale pilot selected by the European Commission on 10 February 2025 for the second round of pilots around the EU Digital Identity Wallet, co-funded under the Digital Europe Programme. The consortium formally launched at a General Assembly in Amsterdam on 3 and 4 September 2025 with more than 180 organisations from 26 countries, stating that it would focus its implementation effort on the chosen use cases over the following 24 months.

Coordination sits with the Netherlands Chamber of Commerce (KVK), the Dutch Ministry of Economic Affairs and Sweden’s Bolagsverket. The participants page currently lists 233 organisations; the consortium itself refers to more than 200 participating organisations across 28 countries. The Netherlands fields one of the largest delegations. Alongside KVK and the Dutch tax administration (Belastingdienst), the list includes the Ministry of Economic Affairs, Logius, ICTU, iSHARE, Portbase, Cleverbase, Digidentity and Unifiedpost, plus banks and payment players such as ABN AMRO, Rabobank and Adyen. OpenPeppol AISBL appears as a Belgian participant.

That composition is the striking part for anyone working in the invoicing chain. The business register and the tax administration sit in the same pilot as the suppliers of identity and signing services and as the standards body behind Peppol. How a company identity from the business register relates to a tax registration and to an address on the Peppol network is not being posed here in a working group note but in an implementation.

The thirteen use cases and which ones reach the e-invoicing chain

The use cases are public and carry codes. In the business domain: BU1 Know Your Business Partner, BU2 Create Company Branch, BU3 Foreign Tax Declaration, BU4 Company Representative acting on behalf of a Company, BU5 Issuing Micro-Credentials and Verified Skills, and BU6 Business Access to the Once-Only Technical System. In the supply chain domain: SC1 Authentication & Access for Transport, SC2 Trusted Data Sharing for Data Spaces, and SC5 eInvoicing. In payments: PA1 Consumer Banking, PA2 Consumer Payments, PA3 Corporate Banking and PA4 Corporate Payments. Thirteen in total.

The public page gives a description per use case but names no lead organisation. Which partner drives which use case cannot be derived from the public sources.

SC5 eInvoicing: attestations around the existing Peppol chain

SC5 is the use case that deals with e-invoicing directly, and its repository is public. The framing is notably conservative. The starting point is that the existing Peppol invoice format and transport mechanisms remain unchanged, and that instead attestations are exchanged and verified at relevant decision points in the invoicing process. The use case explicitly builds on the Peppol four-corner model.

Five scenarios are worked out:

• Supplier pre-approval. A buyer issues an Approved Supplier attestation to a supplier, allowing the supplier’s authorisation or contractual relationship to be verified before an invoice is processed.
• Service Provider authorisation. A business issues an Authorized Service Provider attestation proving that a service provider is permitted to send or receive electronic invoices on its behalf.
• Service Provider authorisation verifiable by a Tax Administration. That same authorisation can also be verified by a tax administration when invoices or transaction data are submitted.
• Direct eInvoicing between Business Wallets. An e-invoice is exchanged directly between business systems using an eInvoice Attestation that cryptographically binds the invoice content to the supplier’s verified business identity.
• Peppol trust enhancements. Additional trust services and attestations are combined with the Peppol infrastructure to improve the integrity, authenticity and traceability of e-invoicing exchanges.

For a Peppol Serviceprovider the sharp edges sit in scenarios two and three. There the mandate between a sender and its service provider becomes a verifiable object rather than a contractual arrangement between two parties. Anyone sending on behalf of clients today on the strength of onboarding records is looking at a model in which a third party, including a tax administration, can check that mandate cryptographically. Scenario four is the most far-reaching: an exchange path that bypasses the four-corner model. That is the kind of design question worth tracking now rather than at final report stage.

BU3 and the tax hooks: e-reporting is not a separate use case

WE BUILD is silent on e-reporting. No use case carries that name, and the public descriptions do not mention ViDA or periodic transaction reporting. What does exist sits in BU3 Foreign Tax Declaration. The public BU3 repository holds a worked-out VAT-ID attestation with an SD-JWT schema, plus material around an electronic tax residence certificate rulebook. The VAT-ID attestation is described as an official document issued by a recognised authority such as the tax administration, confirming the validity of a VAT identification number, with attributes covering validity period, registered address, economic activity and eligibility for intra-EU transactions.

The practical meaning is immediate: a qualified alternative to a VIES lookup, issued by the national tax administration and supporting selective disclosure of attributes. If you validate VAT numbers inside an invoicing product today, this is what replaces that call. Together with scenario three of SC5 it forms the tax axis of the pilot: identity and mandate become verifiable at source, and the tax administration becomes a verifier rather than only a recipient.

The surrounding use cases that still reach your chain

BU4, representation on behalf of a company, matters at least as much for e-invoicing as SC5: almost every invoicing process contains an act that only an authorised representative may perform. SC2, trusted data sharing for data spaces, affects parties that surface invoice data in wider chain processes. BU1, Know Your Business Partner, supplies the onboarding pattern for a new trading relationship, the step that most often causes delay when connecting a new sender today.

How the pilot and the legislative file interact

The two timelines are out of step. The pilot started in September 2025 with a twenty-four month implementation horizon, so the bulk of the work falls in 2026 and 2027. The regulation is still in first reading. If Parliament fixes its position in the second half of 2026, trilogues can open, with political agreement targeted before the end of 2026 and formal adoption expected in early 2027. Implementation deadlines follow, including the two years public sector bodies get to accept the wallet.

The pilot therefore runs ahead of the law. That is the intent, and also the risk: technical choices locked into conformance specifications during 2026 are hard to unwind if the legislator moves differently in 2027. The Council mandate already signals movement on the political side, with higher authorisation thresholds for wallet providers, sixty rather than thirty days for national supervisory authorities to assess applications, and national administrative and procedural requirements left intact. The Council frames the wallet as complementing existing national B2B and B2G systems rather than replacing them. Peppol is one of the systems that framing covers.

The next visible milestone inside the pilot is the General Assembly in Bucharest on 3 and 4 November 2026, hosted by Visa and Banca Transilvania, bringing together 450 representatives from more than 200 participating organisations across 28 countries to review progress on the thirteen use cases and prepare the next implementation phase. From 1 to 3 September 2026 WE BUILD co-organised fifteen sessions at the Global Digital Collaboration Conference in Geneva, covering among other things the EBW as corporate-to-corporate trust infrastructure and credentialing for trade and transport.

What you can do now to plug into the WE BUILD European Business Wallet pilot

Full membership is closed. WE BUILD states on its registration page that the consortium has reached its intended capacity and that the window for new organisations to join as a member has closed after completion of the second amendment. It also announces that organisations will be able to engage in other ways in the near future, such as becoming a relying party or joining an interest group. For now, reading along and testing along are the realistic routes. Concretely:

1. Read the public deliverables. The downloads page carries D4.1 Architecture & Integration Blueprint Reference Document (27 March 2026), D4.2 on the source code repository setup and contribution guidelines (30 December 2025), and the two pilot design deliverables D2.1 and D3.1, both published on 1 August 2026. D4.1 is the one to take first. It sets out the attestation types (PID, EAA and QEAA, the Wallet Unit Attestation and the EBW Owner Identification Data), the formats (SD-JWT VC, W3C Verifiable Credentials Data Model 2.0, ISO 18013-5), the protocols (OID4VCI, OID4VP and the OpenID High Assurance Interoperability Profile), the signing and sealing models based on CSC API v2, and the QERDS design with a four-corner model between wallets via their QERDS providers and a WE BUILD Digital Directory.
2. Follow the specifications on GitHub rather than the press releases. The consortium publishes under the webuild-consortium organisation. The relevant repositories are wp4-architecture with the architecture decision records, conformance specifications and blueprint, SC5 with the e-invoicing scenarios, attestations and rulebooks, BU3 with the VAT-ID attestation, the attestation rulebooks catalogue holding the human-readable rulebooks and machine-readable schemas, and wp4-interop-test-bed. The architecture repository runs on issues labelled adr, cs, blueprint and discussion. That is where you can put a question about the invoicing chain without being a member.
3. Look at the interoperability test bed through the role you will actually play. The test bed checks base protocols, domain-specific functions and end-to-end scenarios against the WE BUILD Conformance Specifications. Participating organisations register their role as issuer, verifier or holder and receive tenant access and reference test suites. Even if you are not testing now, decide which of those three roles your platform will occupy. A service provider sending invoices on behalf of clients is, in the SC5 model, at minimum a verifier of mandate attestations and possibly a holder as well.
4. Take a seat in the interest groups and the newsletter. The Payments Interest Group is explicitly open to everyone subject to registration and runs periodic digital sessions sharing pilot findings. On the payments side that is currently the one open door. For the rest of the consortium the newsletter is the route to take, and it is where the announcement on wider relying party access will land.
5. Map internally where you rely on trust without evidence. Three inventories are worth completing before the pilot results arrive. First: how do you currently record that you are mandated to send on a client’s behalf, and could you demonstrate that mandate to a third party within a week? Second: where in your stack does VAT number validation sit, and how hard-wired is it to VIES? Third: how much of your onboarding consists of manually checking company data that will shortly be available as an attestation? Those three points are precisely where SC5, BU3 and BU1 will meet your process.
6. Put your own roadmap next to the pilot calendar. Bucharest on 3 and 4 November 2026 produces the next public progress position on the thirteen use cases. Schedule an internal review shortly afterwards to judge whether the outcomes affect your 2027 release planning. That is cheaper than discovering later that a conformance specification has knocked out an assumption in your architecture.

What this means for parties in the Dutch and wider European chain

Because KVK leads the project and the Dutch Ministry of Economic Affairs chairs the General Assembly and the Management Board, a substantial share of the reference choices is being made in the Netherlands. The public repositories make that decision-making readable without membership. Anyone who does not read along still gets the model, only filled in by someone else.

The participation of the tax administration deserves separate attention. Once a tax administration acts in the pilot as a verifier of service provider mandates, the burden of demonstrating that mandate shifts into the chain. That is an operational question rather than a legal one. It touches onboarding, record keeping, and whether your system treats a mandate as a distinct, issuable object at all.

For more background on how the wallet meets the e-invoicing addressing problem, see our article on the architectural solution the European Business Wallet offers for e-invoicing, and on how QERDS relates to Peppol transport, see QERDS and the European Business Wallet. The wider file is collected on our European Business Wallet hub page and in the timeline of the legislative process.

Closing

The WE BUILD European Business Wallet pilot is currently the most concrete source available on how the wallet will land in the e-invoicing chain, more concrete than the draft regulation and more concrete than the position papers circling it. The use cases are named, the SC5 scenarios sit openly on GitHub, the architecture blueprint is downloadable, and the test bed has a documented access route. Organisations that follow the repositories now, and map internally where mandate, VAT validation and onboarding run on undocumented trust, will be connecting rather than catching up. If your first question is which Peppol Serviceprovider fits your environment and volume today, compare providers independently through the comparison tool on Peppol.now.

Sources

1. WE BUILD Consortium, consortium and use case overview
2. WE BUILD Consortium, Use Cases (BU1 to PA4)
3. WE BUILD Consortium, participating organisations
4. WE BUILD Consortium, Project update: getting ready for the implementation phase, 1 July 2026
5. WE BUILD Consortium, 2026 General Assembly in Bucharest, 22 July 2026
6. WE BUILD Consortium, sessions at Global Digital Collaboration 2026, 5 August 2026
7. WE BUILD Consortium, official launch at the General Assembly in Amsterdam, 3 September 2025
8. WE BUILD Consortium, public deliverables and publications
9. WE BUILD Consortium, Partner Portal and membership status
10. WE BUILD Consortium, Payments Interest Group
11. GitHub, webuild-consortium/SC5, eInvoicing use case
12. GitHub, webuild-consortium/BU3, Foreign Tax Declaration use case
13. GitHub, webuild-consortium/wp4-architecture, ADRs and conformance specifications
14. GitHub, webuild-consortium/wp4-interop-test-bed
15. European Commission, What are the Large Scale Pilot Projects
16. European Commission, European Business Wallets policy page
17. EUR-Lex, COM(2025) 838 final, proposal for a Regulation establishing European Business Wallets
18. Council of the European Union, European business wallets: Council adopts negotiating position, 9 June 2026
19. European Parliament, procedure file 2025/0358(COD)