# PEPPOL-EN16931-R010: Add the buyer electronic address

Peppol requires a cbc:EndpointID inside the buyer Party. Only the presence of the element is tested; scheme and value are left to other rules.

- Layer: Peppol BIS Billing
- Severity: fatal (the document is invalid)
- Topics: Parties and addresses
- Official definition: https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-peppol/PEPPOL-EN16931-R010/
- Explanation last updated: 2026-09-20

## 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.

| Term | Meaning | UBL element |
|---|---|---|
| BT-49 | Buyer electronic address | `cac:AccountingCustomerParty/cac:Party/cbc:EndpointID` |

## 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.

## 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

```xml
<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

```xml
<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.

### What the validator reported

- The failing invoice reports **PEPPOL-EN16931-R010**. The corrected document passes every layer with no findings.
  - [Download the failing XML](https://ironfang.uk/finance/rule-examples/PEPPOL-EN16931-R010-invalid.xml)
  - [Download the corrected XML](https://ironfang.uk/finance/rule-examples/invoice-minimal.xml)

Recorded on phive 12.1.0 / phive-rules-peppol 4.5.6 / Saxon-HE 12.10, the engine behind the free validator, using synthetic data. A recorded result is regression evidence for these documents; it is not a certification.

## 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](https://ironfang.uk/docs/finance/rules/PEPPOL-EN16931-R020.md)
- [BR-63 requires a schemeID attribute on the buyer EndpointID](https://ironfang.uk/docs/finance/rules/BR-63.md)
- [BR-CL-25 checks the scheme code against the EAS code list](https://ironfang.uk/docs/finance/rules/BR-CL-25.md)

## 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-R010](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-peppol/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.

## Links

- [This rule as a web page](https://ironfang.uk/docs/finance/rules/PEPPOL-EN16931-R010)
- [Free Peppol invoice validator](https://ironfang.uk/tools/peppol-validator)
- [Rule index](https://ironfang.uk/docs/finance/rules.md)
- [Ironfang Finance API docs](https://ironfang.uk/docs/finance)
- The same rule is available to MCP clients as the tool `finance.rule.get` on https://mcp.ironfang.uk/mcp