Peppol Invoice Recipients: Which Electronic Address Does Your Customer Actually Use?

A customer record can contain a company name, postal address, tax identifier and accounts contact without telling your invoicing integration which electronic address to use. If your project includes Peppol BIS Billing, agree how the receiving address and its identification scheme are obtained, checked and preserved for each issued document. Do not let a developer choose an identifier merely because it is already available in the customer database.

This guide concerns recipient data for the UBL invoice in Peppol BIS Billing 3.0. It is not an explanation of national invoicing deadlines, a recommendation that every business use Peppol, or a complete network-onboarding procedure. Confirm the applicable document profile and receiving arrangement with your accounting-system implementer and service provider.

Separate the recipient's roles

OpenPeppol's buyer-address reference defines cbc:EndpointID, business term BT-49, as the buyer's electronic address to which the invoice is delivered. It requires the address and an associated schemeID; the listed rules require the scheme to belong to the relevant electronic-address code list.

The broader specification's buyer example separately represents the electronic address, party identification, postal address, tax information, legal registration and contact email. Those are different fields with different roles. A familiar number appearing in one role does not, by itself, establish the value to put in another.

For your brief, ask for an explicitly named invoice-receiving address and scheme, not a generic field called Company ID. Keep the accounts contact available for questions without silently substituting that person's email for the agreed network recipient. This is a proposed data-entry safeguard, not a claim that email-based identifiers are universally forbidden.

Collect the scheme together with the identifier

An address without its scheme leaves the implementer missing part of the required representation. The official reference identifies schemeID as the buyer electronic-address identification scheme identifier and marks its use as mandatory.

Have the responsible customer contact or approved onboarding process provide both parts of the receiving instruction. Record how the instruction was obtained and who checked it. The software should show staff what each field means rather than ask them to guess from a number's appearance.

The specific scheme and identifier must be appropriate for the actual receiver and integration. Do not copy the documentation's example value into production, select a scheme just because its label contains your customer's country, or assume that an existing tax identifier has already been confirmed as the electronic receiving address.

These are practical commissioning controls. This article does not verify a particular customer's registration or specify every identifier's format and validation algorithm.

Validate the document without overstating the result

The cited address reference lists missing buyer address, missing scheme and code-list requirements as fatal validation rules. Ask the implementer to demonstrate the applicable checks against the actual profile and release used by your system. A populated text box is not the same as a checked output document.

Keep the conclusion precise. A document passing the relevant address checks does not, on that evidence alone, prove that the intended customer received, accepted, booked or paid the invoice. Define separate labels for prepared output, validation result, sending result and any subsequent business response your integration actually provides.

If the sending outcome is uncertain, retain the document and provider reference for reconciliation. Do not invite staff to issue a new invoice number simply because a response has not appeared. That recovery requirement is proposed workflow guidance, not a network retry protocol established by the cited field definition.

Preserve the address used, not only today's customer profile

Decide what happens when the customer changes its receiving instruction. A later correction to master data should not make an earlier invoice appear to have been addressed using the new values.

Require the issued document or its retained output to preserve the actual address and scheme used. Keep the new instruction, review and effective use visible separately. Where an invoice has already been sent to an incorrect recipient, route the case to the approved accounting and provider procedure rather than treating a profile edit as a completed recall.

Also clarify the selection level. Does the instruction apply to the contracting customer, one branch or a specific billing arrangement? That is a question for the real receiving setup, not something to infer from similar names in a dropdown.

Demonstrate one recipient change before acceptance

For a business invoicing integration discussion, bring blank sample documents and a fictional recipient arrangement rather than confidential customer records. Ask for these demonstrations:

• An absent receiving instruction prevents a falsely ready-to-send state.
• An address without a scheme and a scheme outside the applicable list are detected by the appropriate checks.
• The emitted buyer address and scheme match the reviewed instruction, not another identifier field.
• Updating the customer profile leaves the previously issued output explainable.
• A successful validation is not displayed as customer acceptance or payment.
• An uncertain send remains traceable while the responsible person reconciles it.

Accept a clear recipient-data handover, not merely an XML file that opens. Record the profile, release and provider scope tested so a later maintainer knows what was actually checked.

Sources and boundary

OpenPeppol's buyer electronic address reference and BIS Billing specification, buyer section, reviewed 26 October 2026, support the field meanings, mandatory scheme and separate buyer-information roles. The fetched address reference identifies the May 2026 release. Evidence collection, change ownership and acceptance exercises above are project recommendations, not legal advice, live recipient verification or end-to-end Peppol certification.