The European Business Wallet: Company Identity as Infrastructure

The EU Digital Identity Wallet gets the attention because it is about people. The European Business Wallet is the more immediately useful one for anyone building B2B software, because it attacks a problem every business system has and none has solved: proving that a company is what it says it is, and that the person acting for it is authorised to do so.

The Council adopted its negotiating position on 9 June 2026 and the stated ambition is political agreement by the end of 2026. Member states would be expected to accept business wallets for administrative procedures within 24 months of entry into force, with an extra year for more complex functionality.

The problem it solves

Every B2B onboarding flow contains the same archaeology. A company registration number typed by hand. A PDF of an extract from a commercial register, possibly months out of date, possibly in a language nobody in the reviewing team reads. A signature from someone whose authority to sign is asserted rather than proven. A VAT number checked against one system, a bank account checked against another, a beneficial ownership declaration checked against nothing.

Multiply that by 27 member states with 27 register formats and you have the actual reason cross-border B2B commerce in Europe is slower than it should be.

The business wallet is a company-level credential container built on the same eIDAS 2 framework as the personal wallet. Instead of holding a person's driving licence and diploma, it holds a company's registration data, its mandates, its representation rights, its certificates and licences, and the ability to exchange signed documents across borders in a way the receiving party can verify cryptographically.

What it holds

The credential types under discussion cover the things that currently arrive as PDFs:

Company identity and registration data, sourced from the authoritative national register rather than transcribed.

Representation and mandate credentials. This is the important one. Not just that a company exists, but that this specific person may act for it, within these limits. The mandate problem is what makes automated B2B onboarding hard, and it is what most systems currently handle by taking someone's word for it.

Licences, permits and certifications. Professional qualifications, sector authorisations, accreditations.

Attestations from public bodies. Tax status, social security compliance, and the various clearance certificates that procurement processes demand.

Signed documents and seals. Electronic seals under eIDAS, which are the corporate equivalent of a signature and already have legal status.

Why this is different from what exists

Several things already partly address this. Company registers are online in most member states. The Business Registers Interconnection System links them. eIDAS already provides for electronic seals. Qualified certificates exist.

What does not exist is a single, verifiable, machine-readable, cross-border way to present a bundle of company facts to a counterparty who can check them without trusting you.

Three properties make the wallet different:

Cryptographic verification rather than document inspection. The receiving party verifies a signature and an issuer trust chain. There is no human reading a PDF and deciding whether it looks genuine.

Selective disclosure. The same primitive that lets a person prove they are over eighteen without revealing a birth date lets a company prove it holds a specific licence without disclosing its entire registration record.

Cross-border acceptance is mandatory. A wallet issued in one member state must be recognised in the others. This is the property that the current patchwork lacks and the reason it is worth building against.

What this means if you build B2B software

The wallet turns a verification problem into an integration problem, which is the direction you want.

Supplier and customer onboarding

The obvious case. Instead of collecting documents and reviewing them, you request the credentials you need, the counterparty presents them from their wallet, and you verify. Onboarding that currently takes days of back-and-forth becomes a flow.

The design work is deciding which credentials you actually need, which is harder than it sounds because most onboarding processes accumulated their document lists without anyone auditing them. Selective disclosure only helps if you ask for the minimum.

Procurement and tendering

Public procurement in the EU already requires a pile of attestations: tax clearance, social security compliance, absence of exclusion grounds, financial standing, technical capacity. Most of this is currently self-declaration followed by document collection from the winner.

A verifiable credential model changes that from a paperwork exercise to a check. If you build procurement software, this is the file to watch.

E-invoicing and payment counterparty verification

Mandatory e-invoicing is arriving across member states on different timetables, and it creates a counterparty verification problem at scale. Combined with Verification of Payee on the payments side, the pieces for a system where you can actually verify who you are invoicing and paying are falling into place.

Regulated business processes

Any process where you currently need to establish that a company holds a licence, that a person may bind it, or that a certificate is current. Financial services onboarding, insurance, healthcare supply, construction, transport, anything with a professional register behind it.

The engineering work, honestly

If you have read our EU Digital Identity Wallet guide, the shape will be familiar, because it is the same technical stack: verifiable credentials, selective disclosure, presentation protocols, issuer trust chains.

The differences that matter:

Company entities are messier than people. A person has one identity. A company has a legal entity, possibly subsidiaries, possibly branches in other member states, a registration in one place and operations in several. Your data model has to represent that, and most B2B systems flatten it into a single customer record.

Mandates have scope and expiry. A person is authorised to act for a company for certain purposes, up to certain limits, until a certain date, and that can be revoked. This is genuinely more complex than an identity assertion and it is where most of the implementation effort will go.

Revocation matters more. A verified personal attribute is fairly stable. A company mandate can be revoked the day after it was presented. Any system that caches a verification result needs a revocation strategy and a decision about how stale is too stale.

You will need a fallback for years. Adoption will be uneven across member states and company sizes. The wallet is an additional path, not a replacement, and anything built on the assumption that counterparties have one will break.

What is worth doing now

Separate legal entity from customer record. Most B2B systems conflate the company you contract with, the company you invoice, and the company in the register. They are frequently not the same entity. Untangling this is the prerequisite for everything else and it is worth doing regardless.

Model authority explicitly. Who may act for this customer, for what, within what limits. Most systems store a contact list and infer authority from job titles. If you have never modelled this properly, the business wallet is a good forcing function.

Make credential provenance a field. For every fact you hold about a company, know whether it was self-declared, transcribed from a document, or verified against a source. Retrofitting this is painful and it is the same requirement the personal wallet creates.

Audit your document collection list. Which documents do you actually need, for what legal or commercial reason. You will find items nobody can justify. Removing them is free and it makes the eventual credential request minimal.

Watch the implementing acts. As with the personal wallet, the technical specifications are where the actual integration requirements live, and they are still forming.

A realistic view of timing

Two years is a short runway for large organisations and a long time for a proposal that has not been agreed yet.

The Council has a position. Parliament's position and the trilogue outcome are still ahead. The 24 month acceptance obligation runs from entry into force, not from political agreement, so the real dates are later than the headlines suggest.

Adoption is also genuinely uncertain in a way the personal wallet's is not. Member states are obliged to accept business wallets for administrative procedures, which guarantees a public sector floor. Whether private B2B commerce adopts it depends on whether the credential set is useful enough to be worth the integration, and that will vary a lot by sector.

The sectors where verification is currently expensive and painful, which is regulated industries and public procurement, will move first. Ordinary B2B SaaS onboarding will move much later, if at all.

What that argues for: do the underlying data model work, because it pays off independently. Do not build a wallet integration until there is a specification and a counterparty who will use it.

Where this fits

The business wallet is part of the One Europe One Market roadmap alongside the Digital Networks Act and a cybersecurity package. The full legislative queue is in our EU digital law pipeline, and the personal wallet it builds on is covered in our EU Digital Identity Wallet guide.

Getting help

We build B2B platforms, onboarding systems and identity integrations for companies operating across Europe, including the tedious and valuable work of separating legal entity from customer record in a system that has conflated them for a decade.

If the business wallet is on your roadmap, or your B2B onboarding needs the data model work that has to come first, write to office@c9group.dev. More about our European work on the EU market entry page.

We are engineers rather than lawyers. Whether a specific credential satisfies a specific legal requirement is a question for your counsel.