PEPPOL-EN16931-R020: Seller Electronic Address Missing, the Peppol Rule Explained

What PEPPOL-EN16931-R020 checks

The rule requires a seller electronic address, BT-34: the sender's participant identifier on the Peppol network with its EAS scheme, in UBL the cbc:EndpointID inside cac:AccountingSupplierParty. The network's model is symmetric: both parties are addressable participants. The Peppol hub uses exactly this finding to demonstrate how an access-point rejection turns into an actionable message, because it is the rejection most first-time senders meet.

Layer and formats

Findings carry "layer": "cius". The rule fires when validating against the Peppol BIS profile, the default for documents declaring the Peppol CustomizationID. With options.profile set to en16931 the overlay is dropped, which is the correct treatment for documents that will never touch the network.

Why it fails in practice

The sender's own identity was never modelled. Buyer data is maintained per customer, but the seller master record predates Peppol and has no participant identifier.
Multi-entity confusion. A corporate group sends through one access point; invoices from subsidiaries go out without the per-entity endpoint that was registered.
Identifier present, scheme missing. The VAT number is in the element but the schemeID attribute is empty, so the address does not count.

How to fix it

Declare your registered participant identifier in the supplier party:

<cac:AccountingSupplierParty><cac:Party>
  <cbc:EndpointID schemeID="9930">DE123456789</cbc:EndpointID>
  ...
</cac:Party></cac:AccountingSupplierParty>

In an InvoiceXML create request the pair is invoice.seller.electronicAddress with identifier and schemeId. The API never invents a seller endpoint: a fabricated routing address would validate and still misroute, so this one value is always yours to supply.

The raw rejection vs the InvoiceXML finding

Raw Schematron output:

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

The InvoiceXML finding:

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

The message states the fix and the escape hatch in plain language, and fields names the input to highlight. No rule-code parsing on your side, and the stable rule key lets clients localize with their own copy.

Check or generate Peppol documents

Validate against the current network rules in the UBL validator, or generate ready-to-send BIS documents with POST /v1/create/ubl. Rule set updates, like each Peppol release, go live server-side on their effective dates, with nothing for you to monitor or redeploy. Start at the Peppol hub for the full network picture.

PEPPOL-EN16931-R010, the buyer-side twin for BT-49
PEPPOL-EN16931-CL008, invalid EAS scheme codes on either address
PEPPOL-EN16931-R001, the business process declaration
The Peppol BIS Billing 3.0 CustomizationID, the identifier that activates the overlay

Frequently asked questions

Why does the seller need an electronic address at all?

Responses travel back. Message level responses, invoice responses and future two-way processes address the sender by participant identifier, and receivers use BT-34 to identify the sending party on the network. A BIS document therefore declares both endpoints, not just the destination.

What if my company is not registered on Peppol yet?

Sending over the network happens through an access point, and your provider registers your participant identifier. If you are not sending over Peppol, validate under the plain en16931 profile instead; the overlay and this rule then no longer apply.

Which scheme code should the address use?

One from the EAS list matching the identifier type: 9930 for a German VAT number, 0088 for a GLN, 0204 for a Leitweg-ID, 0208 for a Belgian enterprise number, and so on. An invalid scheme fails the companion rule PEPPOL-EN16931-CL008.

In which layer does R020 appear?

The cius layer, as part of the Peppol BIS overlay. The European core keeps BT-34 optional, which is why generic EN 16931 documents pass everywhere else and fail exactly here.

PEPPOL-EN16931-R020