Peppol identifier verification

Before an account can send invoices in production, each Peppol identifier is verified against a public business registry. This page explains what that means, why we do it, and what to do if verification fails.

Why we verify

The Peppol network assumes senders are who they say they are. Our Integrator agreement with OpenPeppol requires us to make a reasonable effort to prevent invoices from being sent on behalf of entities unrelated to the sender. Verification is how we do that.

What we check

That your identifier (e.g. a French SIREN or a Belgian enterprise number) exists in the relevant public registry.
That the legal name you declared is a close match to the registered name.

We verify against VIES, INSEE (France), KBO/CBE (Belgium), Bolagsverket (Sweden), DanskCVRAPI (Denmark), and Overheid.io OpenKvK (the Netherlands). The United Kingdom is the exception: the only UK identifier the Peppol network routes is the VAT number, and we cannot currently verify it against HMRC automatically. Contact support to arrange identity verification before production sending. Companies House verifies a company registration number, which Peppol does not route.

What happens at registration

You add a production Peppol identifier in the dashboard, including the declared company name and the attestation checkbox.
If an automatic registry check is available, we begin it immediately. Most automatic checks complete in under a minute.
Until verification succeeds, invoice sending is paused for that identifier.
The dashboard shows the resulting state and next action. If automatic verification is unavailable, Contact support to arrange it.

Verification states

The API returns a verificationState field on every Peppol identifier. The dashboard surfaces a human-readable badge for each.

API value	Dashboard badge	Meaning
`sandbox_auto`	Sandbox auto-approved	Sandbox only — auto-approved without registry lookup.
`unverified`	Queued…	Waiting for verification to start.
`verifying`	Verifying…	Currently checking against the registry.
`verified`	✓ Verified	Matched. Invoice sending is unlocked for this identifier.
`mismatch`	⚠ Needs review	Identifier exists but the declared name doesn't match closely enough.
`not_found`	⚠ Not found	The identity could not be established. Either the registry has no entry for the identifier; or it has one but doesn't consider the entity active (struck off, in liquidation, or not yet active); or our team reviewed the identity and declined it.
`api_error`	Temporarily unavailable	Registry is down. The cron retries automatically every 5 minutes.
`unsupported_scheme`	Registry not covered	Automatic registry verification is unavailable. Contact support to arrange identity verification before production sending.
`manually_approved`	✓ Approved (reviewed)	Manually approved by our team after review.

If verification fails

Production sending remains unavailable until identity is verified. Contact support with proof of authorisation — for example, your Articles of Incorporation or an extract from the public registry showing your entity — to arrange verification.

Sandbox accounts

Standard sandbox onboarding auto-registers a Storecove test identifier and marks it sandbox_auto. Platform customer Legal Entities are different: their requested identifiers still go through the sub-tenant verification and network-registration flow, so fake or unsupported numbers can fail even in sandbox.

If you do not have real customer numbers yet, register your test customers under scheme 9915, which the published Peppol code list annotates with the usage note “No entity behind id”. No company stands behind such an identifier, so there is no registry to query, and none is consulted. The sub-tenant is still published on the Peppol test network and can send, so the whole platform flow stays exercisable without registering a number that belongs to somebody else.

Values follow the published format [A-Z][A-Z0-9]* — upper-case letters and digits, starting with a letter, for example 9915:ACMETEST01. The resulting status is no_registry, never verified: it says the identifier is registered and routable on the test network, and says nothing about a company existing or about your right to act for it. Registering this scheme with a production key is refused.

The Peppol test network has a public directory. Everything you register there — the identifier value, the company name and the address you declare — becomes visible to anyone, and the identifier namespace is shared with every other tester. So: use synthetic company details, never a real customer’s name or address, and pick a value that is distinctly yours (9915:ACMETEST01, not 9915:TEST) — a value somebody else already registered comes back as a registration failure.

Privacy and legal basis

We process verification data under UK GDPR Article 6(1)(b) (contract necessity — a verified identifier is a pre-condition for production sends) and Article 6(1)(f) (legitimate interest — fraud prevention). Our OpenPeppol Integrator obligations are contractual rather than statutory, so they are not a legal-obligation basis under Article 6(1)(c). Evidence is kept for six years from the verification date, then purged by a monthly job (so it may persist for up to a further month). See our Privacy Policy and Terms of Service §6 for full details.