PEPPOL-EN16931-R010Add the buyer electronic address

The short answer

PEPPOL-EN16931-R010 fails when the buyer party, cac:AccountingCustomerParty/cac:Party, contains no cbc:EndpointID. Add the buyer electronic address there, as the first child of cac:Party, with a schemeID attribute for the scheme it is issued under.

The value has to come from the buyer. It is their address, so it belongs in the customer master data alongside their name and VAT identifier, not in a default applied by the sender.

What the rule checks

The test is the existence of a cbc:EndpointID child on the buyer cac:Party. Nothing about the element is inspected: not its text, not its schemeID.

An empty cbc:EndpointID therefore clears this rule and fails elsewhere. With schemeID="0088" and no content the document reports PEPPOL-EN16931-R008 for the empty element and PEPPOL-COMMON-R040 for the GLN format, and PEPPOL-EN16931-R010 stays silent.

The seller side is a separate rule, PEPPOL-EN16931-R020. Removing both addresses produces both findings; having one never satisfies the other.

How an integration ends up here

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

• Customer records were created before Peppol delivery was introduced and have no field, or no value, for an electronic address.
• The address is known to the access point and used for routing, but is never passed to the component that builds the XML.
• The buyer is identified only by cac:PartyIdentification/cbc:ID or a legal registration number, which the mapping assumed would be enough.
• A template shared with an EN 16931-only output leaves the element out because the core model does not require it.

How to fix it

1. Obtain the buyer electronic address and its scheme from the buyer, or from whatever onboarding step records how they receive documents.
2. Store both parts, scheme code and identifier, on the customer record. A free-text field that mixes them, such as 0088:7300010000001, has to be split before it can be mapped.
3. Emit cbc:EndpointID as the first child of cac:AccountingCustomerParty/cac:Party with the identifier as content and the scheme code in schemeID. Placed after cac:PostalAddress, the element breaks the UBL child order and the XSD layer rejects the document before this rule runs.
4. Refuse to build the document when the buyer has no electronic address, instead of emitting an empty element or a placeholder.

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 buyer Party has no EndpointID

<cac:AccountingCustomerParty>
  <cac:Party>
    <cac:PostalAddress>
      <cbc:StreetName>2 Example Street</cbc:StreetName>
      <!-- rest of the address omitted from this fragment -->
    </cac:PostalAddress>
    <!-- legal entity omitted from this fragment -->
  </cac:Party>
</cac:AccountingCustomerParty>

Fragment of the corrected invoice: the buyer Party opens with its EndpointID

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

The only difference is the cbc:EndpointID line in the buyer cac:Party, present in the corrected file and absent from the failing one. The failing document reports only PEPPOL-EN16931-R010, and only on the Peppol layer: the EN 16931 rule about the buyer address, BR-63, tests the schemeID of an element that exists and has nothing to test here. The fixture value is an example GLN.

Where it applies

• Applies to UBL Invoice and CreditNote. The buyer party has the same path in both, and a credit note without the element reports the same single finding.
• The requirement is Peppol-specific. EN 16931 leaves the buyer electronic address optional, so the EN 16931 layer passes.
• A well-formed address that passes this rule, BR-63 and BR-CL-25 is still only a string in a document. The validator does not query the Peppol directory or an SMP, so it cannot tell you whether the buyer is registered or able to receive the document.

Related rules

• PEPPOL-EN16931-R020 requires the seller electronic address in the same way
• BR-63 requires a schemeID attribute on the buyer EndpointID
• BR-CL-25 checks the scheme code against the EAS code list
• Browse every rule in the reference

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-20.1: source checked 2026-09-20, explanation last updated 2026-09-20.

The official definition of PEPPOL-EN16931-R010 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.