# PEPPOL-EN16931-R020: Add the seller electronic address

Peppol requires a cbc:EndpointID inside the seller Party. The rule checks only that the element is there, not its scheme or value.

- 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-R020/
- Explanation last updated: 2026-09-20

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

| Term | Meaning | UBL element |
|---|---|---|
| BT-34 | Seller electronic address | `cac:AccountingSupplierParty/cac:Party/cbc:EndpointID` |

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

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

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

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

### What the validator reported

- The failing invoice reports **PEPPOL-EN16931-R020**. The corrected document passes every layer with no findings.
  - [Download the failing XML](https://ironfang.uk/finance/rule-examples/PEPPOL-EN16931-R020-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` 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](https://ironfang.uk/docs/finance/rules/PEPPOL-EN16931-R010.md)
- [BR-62 requires the schemeID attribute once the seller EndpointID is present](https://ironfang.uk/docs/finance/rules/BR-62.md)
- [BR-CL-25 checks that the scheme code is in the EAS code list](https://ironfang.uk/docs/finance/rules/BR-CL-25.md)
- [PEPPOL-EN16931-R008 reports an EndpointID that is present but empty](https://ironfang.uk/docs/finance/rules/PEPPOL-EN16931-R008.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-R020](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-peppol/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.

## Links

- [This rule as a web page](https://ironfang.uk/docs/finance/rules/PEPPOL-EN16931-R020)
- [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