PEPPOL-EN16931-R020: Add the seller electronic address

The short answer

PEPPOL-EN16931-R020 fails when cac:AccountingSupplierParty/cac:Party has no cbc:EndpointID child. Add the element as the first child of the seller cac:Party, holding the seller electronic address, with a schemeID attribute naming the scheme the address belongs to.

EN 16931 treats the seller electronic address as optional, so the EN 16931 layer passes without it. The requirement comes from Peppol, which is why the finding appears on the Peppol layer only.

What the rule checks

The rule runs once for the seller cac:Party and asks a single question: is there a cbc:EndpointID child element? It does not read the content or the schemeID attribute.

Because it is a presence check, an cbc:EndpointID that is present but empty satisfies it. The empty element is reported by PEPPOL-EN16931-R008 instead, and if it carries a scheme whose value format Peppol checks, by that format rule as well: an empty element with schemeID="0088" reports PEPPOL-EN16931-R008 and PEPPOL-COMMON-R040, not this rule.

An cbc:EndpointID elsewhere in the document does not count. The buyer address is checked separately by PEPPOL-EN16931-R010, and a document missing both reports both rules.

How an integration ends up here

Possible causes, from the shape of the rule rather than from measured usage:

• The mapping was written against EN 16931, where the seller electronic address is optional, and was never extended for Peppol.
• The seller endpoint is held in access-point or tenant configuration rather than in the invoice data, so the document builder has nothing to emit.
• The builder drops elements whose source value is null, and the seller record has no electronic address filled in.
• The address was written to cac:PartyIdentification/cbc:ID or to cac:Contact/cbc:ElectronicMail in the belief that either serves as the electronic address.

How to fix it

1. Find the seller electronic address and the scheme it is issued under, for example a GLN under 0088. Use the identifier the seller really holds; do not borrow one from another party or make one up to satisfy the rule.
2. Emit cbc:EndpointID as the first child of cac:AccountingSupplierParty/cac:Party, before cac:PartyIdentification, cac:PartyName and cac:PostalAddress. UBL fixes the child order of cac:Party: with the element placed after cac:PostalAddress, the XSD layer rejects the document and the EN 16931 and Peppol layers are skipped.
3. Set the schemeID attribute to the scheme code. BR-62 requires the attribute and BR-CL-25 checks the code.
4. Make the seller endpoint a required field where the seller is set up, so the gap is caught before a document is built.

Validate your corrected invoice

Before and after

These are fragments, not complete documents. The complete synthetic documents they come from are linked below.

Fragment of the failing invoice: the seller Party starts with its postal address and has no EndpointID

<cac:AccountingSupplierParty>
  <cac:Party>
    <cac:PostalAddress>
      <cbc:StreetName>1 Example Street</cbc:StreetName>
      <!-- rest of the address omitted from this fragment -->
    </cac:PostalAddress>
    <!-- tax scheme and legal entity omitted from this fragment -->
  </cac:Party>
</cac:AccountingSupplierParty>

Fragment of the corrected invoice: EndpointID is the first child of the seller Party

<cac:AccountingSupplierParty>
  <cac:Party>
    <cbc:EndpointID schemeID="0088">7300010000001</cbc:EndpointID>
    <cac:PostalAddress>
      <cbc:StreetName>1 Example Street</cbc:StreetName>
      <!-- rest of the address omitted from this fragment -->
    </cac:PostalAddress>
    <!-- tax scheme and legal entity omitted from this fragment -->
  </cac:Party>
</cac:AccountingSupplierParty>

The corrected document adds one line, the cbc:EndpointID with schemeID="0088" at the top of the seller cac:Party. Nothing else differs. The failing document reports only PEPPOL-EN16931-R020; its EN 16931 layer passes because BR-62 has nothing to examine when the element is absent. The identifier in the fixture is an example value, not a registered participant.

Where it applies

• Applies to UBL Invoice and CreditNote alike. A credit note without the seller cbc:EndpointID reports the same single finding.
• This is a Peppol BIS Billing 3.0 rule. It reports on the Peppol layer and has no EN 16931 counterpart.
• Passing this rule, and the scheme rules after it, shows the address is well formed. The validator does not look the participant up, so it says nothing about whether the seller is registered or reachable on the Peppol network.

Related rules

• PEPPOL-EN16931-R010 is the same presence check for the buyer electronic address
• BR-62 requires the schemeID attribute once the seller EndpointID is present
• BR-CL-25 checks that the scheme code is in the EAS code list
• PEPPOL-EN16931-R008 reports an EndpointID that is present but empty
• Browse every rule in the reference
• Background: How Peppol invoice validation actually works

Scope and source

Written for Peppol BIS Billing 3.0.21 (May 2026), EN 16931 1.3.16, as applied to UBL 2.1 Invoice and CreditNote documents. Other profiles, syntaxes and releases can define this identifier differently. Guidance version 2026-09-24.1: source checked 2026-09-24, explanation last updated 2026-09-20.

The official definition of PEPPOL-EN16931-R020 carries the normative wording and test. This page is our explanation of it, not a copy.

Guidance does not change the engine verdict. Fixing this finding does not mean the document passes every layer, and validation does not certify legal or tax compliance or transmit a document over Peppol.