PEPPOL-EN16931-R010: Buyer Electronic Address Missing, the Peppol Rule Explained

What PEPPOL-EN16931-R010 checks

The rule requires a buyer electronic address, BT-49: the buyer's endpoint identifier on the Peppol network, with its EAS scheme. In UBL it is the cbc:EndpointID inside cac:AccountingCustomerParty. Routing on Peppol is done by participant identifiers, so this field is not metadata, it is the delivery address; a BIS Billing document without it is undeliverable by construction, and the overlay fails it at validation time rather than at the access point.

Layer and formats

Findings carry "layer": "cius": the requirement is Peppol's tightening of the core, applied when validating against the Peppol BIS profile (the default for documents declaring the Peppol CustomizationID). Under options.profile en16931 the overlay is dropped and BT-49 becomes optional again, the right call for invoices delivered outside the network.

Why it fails in practice

The buyer master data has no participant ID. Postal addresses and VAT numbers are maintained; the Peppol endpoint never got a column.
An identifier without its scheme. The GLN or VAT number is emitted, but the schemeID attribute is missing or empty, which fails the address pair.
Reusing a non-Peppol pipeline. Documents built for email or portal upload are redirected through an access point, and the network requirements surface all at once.

How to fix it

Emit the buyer's registered participant identifier with its scheme:

<cac:AccountingCustomerParty><cac:Party>
  <cbc:EndpointID schemeID="0088">5798000000000</cbc:EndpointID>
  ...
</cac:Party></cac:AccountingCustomerParty>

In an InvoiceXML create request the pair is invoice.buyer.electronicAddress with identifier and schemeId properties. For XRechnung documents the API can even default the address from the Leitweg-ID; for Peppol you supply the buyer's real registration.

The raw rejection vs the InvoiceXML finding

The raw Schematron verdict is terse:

<svrl:failed-assert id="PEPPOL-EN16931-R010" flag="fatal"
    location="/*:Invoice[namespace-uri()='...']/cac:AccountingCustomerParty[1]/cac:Party[1]">
  <svrl:text>Buyer electronic address MUST be provided</svrl:text>
</svrl:failed-assert>

The InvoiceXML finding explains and maps it:

{
  "rule": "PEPPOL-EN16931-R010",
  "layer": "cius",
  "line": null,
  "message": "Peppol BIS requires a buyer electronic address (BT-49). Add the buyer's electronic address and its scheme, or use the plain en16931 profile if the invoice is not meant for Peppol.",
  "btCodes": ["BT-49"],
  "fields": ["buyer.electronicAddress.identifier"],
  "raw": "[PEPPOL-EN16931-R010] CIUS: Buyer electronic address MUST be provided"
}

Your UI highlights the buyer address input and shows the message as is; no rule-code lookup tables to maintain, and clients that want their own texts localize by the stable rule key.

Check or generate Peppol documents

Test a file against the network rules in the UBL validator, or generate with POST /v1/create/ubl on the Peppol profile, where a missing address is caught as a clean request error before any XML exists. The Peppol hub explains participants, access points and the rejection anatomy in full.

PEPPOL-EN16931-R020, the seller-side twin for BT-34
PEPPOL-EN16931-CL008, when the address is present but its scheme code is invalid
PEPPOL-EN16931-R001, the business process declaration
The Peppol BIS Billing 3.0 CustomizationID, the identifier that activates these rules

Frequently asked questions

What is a buyer electronic address exactly?

The buyer's Peppol participant identifier: an identifier value plus an EAS scheme code that says what kind of identifier it is, for example 0088 for a GLN, 9930 for a German VAT number, or 0204 for a Leitweg-ID. In UBL it is cbc:EndpointID with a schemeID attribute inside the buyer party.

Where do I find my buyer's Peppol address?

Ask the buyer or look them up in the Peppol directory. A registered participant has one or more identifiers under which they receive documents; you must use one they are actually registered under, not merely a syntactically valid one.

What if the buyer is not on Peppol at all?

Then the document should not be validated as Peppol BIS. Use the plain en16931 profile (or the CIUS that matches the real delivery channel), and the overlay rule disappears. The finding's own message points out this escape hatch.

Is the seller side checked too?

Yes, by the sibling rule PEPPOL-EN16931-R020 for BT-34. The pair usually fails together on documents produced by systems that never modelled network routing.

PEPPOL-EN16931-R010