Which Peppol identifier should I check?

several numbers that look alike. Only one is the address.

You are sending an invoice through Peppol, the network many European buyers receive invoices on, and something has asked you for the buyer’s Peppol identifier. Perhaps a check reported the buyer’s electronic address as missing or ambiguous, or your access point wants to know where to deliver. Several identifiers on an invoice look alike, and it is easy to put the right value in the wrong field.

This is a common point of confusion and it is quick to settle. You need one answer from the buyer, their exact Peppol identifier and its scheme, and one lookup to confirm that it is registered. This guide shows which field each identifier belongs in, how to run the lookup, and what the result does and does not tell you.

The one idea: a scheme and a value

A Peppol identifier has two parts. The scheme says what kind of number this is, for example a German VAT number or a global location number. The value is the number itself. The network resolves a participant by both parts together, so a value without its scheme cannot be delivered to.

Every field in a European e-invoice has a number, written BT and a figure. The buyer’s electronic address is field 49, written BT-49, and that is the field Peppol delivers to. Two other fields carry identifiers for the same companies: BT-46 identifies the buyer as a business partner and BT-29 identifies the seller. They are not delivery addresses.

These identifiers are not interchangeable

A VAT number can be the value of a Peppol identifier when it is used with the matching scheme. That does not make every VAT number a registered Peppol endpoint. A company name alone is not enough for an exact participant lookup.

Check the exact scheme and value

Ask the buyer for both parts of their identifier. Attestwire expects them written together as scheme:value, which is the form the network uses. Registration under one scheme does not prove registration under another scheme, even when the values refer to the same organisation.

If you work with the XML file directly: UBL is one of the two XML formats an e-invoice can be written in, and in UBL the buyer’s electronic address is the cbc:EndpointID element inside the buyer party. Its schemeID attribute carries the scheme. Keep the scheme and value together when you compare that element with the identifier the buyer gave you.

<cac:AccountingCustomerParty>
  <cac:Party>
    <cbc:EndpointID schemeID="0208">0848934496</cbc:EndpointID>
    ...

UBL excerpt, not a complete invoice. The identifier is OpenPeppol’s public example, explained below.

Run the lookup

Open hosted invoice checks, select Peppol recipient, and replace the example with the buyer’s actual identifier. You need an API key, which is a credential you create on the pricing page. The identifier is sent to OpenPeppol’s public lookup service.

If you are integrating this into your own software, call POST /v1/peppol/lookup on the API, or the tool lookup_peppol_participant through MCP, the interface an AI assistant uses to call these tools. Set document_type to invoice or credit_note. If you also supply invoice_participant_id, Attestwire compares it with the identifier being queried. You supply that value, so the lookup is not reading your invoice file.

The workbench shows 0208:0848934496 as its example. It is OpenPeppol’s public sample identifier. It is not a placeholder buyer for your invoice, and this guide does not claim a live result for it.

Read the result

The lookup returns one of three statuses. Each one is a statement about what the network’s publication data said at that moment, and nothing more.

A registered result does not test endpoint certificates, the delivery itself, or whether the buyer will accept the invoice. Those belong to your access point, the service provider that connects you to the network. The lookup runs against the production network, not the test network.

Why a company can be missing from the Peppol Directory

The Peppol Directory is a searchable list of participants who chose to publish their details. The publication lookup is different: it asks the network whether a specific identifier is registered and what documents it accepts. OpenPeppol says Directory updates are not mandatory, so a registered recipient can be absent from a Directory search. Confirm the exact identifier and use the publication lookup or the buyer’s service provider to investigate.

Attestwire uses OpenPeppol’s public lookup, not a company-name Directory search. Its provider can still be unavailable or inconclusive. A provider answer of “not found” stays unavailable in Attestwire, because it is not proof that no registration exists.

Keep the evidence, then check the invoice

Every lookup returns a receipt, a dated record of what the service observed. Keep the complete receipt if you need it later; this service does not store it for you. Some receipts are signed and some are not, so read the evidence.signing_status field rather than assuming. A conclusive lookup uses one document from your plan, and an unavailable lookup is uncharged.

Then check the invoice’s contents in your browser. If the buyer reference is missing, the buyer-reference guide walks through that fix. Registration, invoice validity and successful delivery are three separate checks, and passing one does not cover the others.

Sources: BT-49, BT-46, BT-29 in the Peppol BIS Billing 3.0 syntax reference; the Peppol Directory and lookup service pages at OpenPeppol. Result statuses match the hosted API’s own definitions.

Request and evidence documentation