Peppol identifier verification

Before an account can send invoices in production, its Peppol identity must pass the applicable automatic or manual verification path. This page explains what that means and how to resolve failures.

Why we verify

The Peppol network assumes senders are who they say they are. Our Integrator agreement with our Peppol access point, Storecove, passes OpenPeppol's obligation on to 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 is valid through the relevant verification source, where an automatic source is available.
That the legal name you declared is a close match when that source returns a name.

Supported countries and whether onboarding is self-serve or assisted are maintained on the country coverage page. Common identifier-scheme formats are documented in the onboarding guide. If automatic verification is unavailable, contact support before production sending.

What happens at registration

You add a production Peppol identifier in the dashboard and tick the attestation checkbox. The company name is taken from your Legal Entity (read-only) — fix the Legal Entity first if it is wrong.
If an automatic registry check is available, we begin it immediately; a sweep every five minutes picks up anything that did not start.
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 states below are what the dashboard shows, as a badge on each Peppol identifier. The public API never exposes them raw: GET /v1/identity and GET /v1/legal-entities/:id both answer with a derived status, documented in Sub-tenant Lifecycle.

Internal state	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 through the relevant automatic verification source.
`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	The automatic verification source is unavailable. Retried every 5 minutes, up to 3 attempts, then reviewed manually by our team.
`duplicate_claim`	⚠ Already claimed	Another account already holds the verified production claim on this identifier. Sending is blocked until the conflict is resolved with our team.
`no_registry`	No registry	Sandbox only — the scheme has no registry behind it (`9915`), so nothing was checked and nothing failed. Production refuses such identifiers.
`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 builds a placeholder routing identifier, registers it with our provider 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.