# PEPPOL-EN16931-CL008: Use a Peppol electronic address scheme code in EndpointID

The `schemeID` on each `cbc:EndpointID` must exactly match a code on the Peppol list of electronic address schemes, such as `0088` for a GLN.

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

## The short answer

`PEPPOL-EN16931-CL008` fails when the `schemeID` of a `cbc:EndpointID` is not, character for character, one of the scheme codes Peppol accepts for electronic addresses. In the recorded example the seller address is marked `GLN`; the code for a GLN is `0088`.

The EN 16931 rule `BR-CL-25` tests the same attribute against the EAS list. A value that neither list contains, like `GLN`, is reported by both rules. Every code on the Peppol list is also on the EAS list, so a code Peppol accepts satisfies both.

## What the rule checks

The rule runs on every `cbc:EndpointID` that has a `schemeID` attribute, and the finding points at that element. An `cbc:EndpointID` without the attribute is left to `BR-62` and `BR-63`.

The attribute must equal a listed code exactly. Nothing is trimmed and case is not folded: when tried, `schemeID=" 0088 "` failed this rule while the EN 16931 layer passed.

The Peppol list is narrower than the EAS list pinned for `BR-CL-25`. Codes such as `0037`, `0147` and `0212`, and the letter codes `AN`, `AQ`, `AS`, `AU` and `EM`, are on the EAS list and not on the Peppol one. When tried, `schemeID="0037"` passed the EN 16931 layer and failed this rule alone.

The identifier value is not read here. Format checks for particular schemes are separate rules, such as `PEPPOL-COMMON-R040` for the GLN check digit under `0088`.

| Term | Meaning | UBL element |
|---|---|---|
| BT-34 | Seller electronic address: its scheme identifier attribute | `cac:AccountingSupplierParty/cac:Party/cbc:EndpointID/@schemeID` |
| BT-49 | Buyer electronic address: its scheme identifier attribute | `cac:AccountingCustomerParty/cac:Party/cbc:EndpointID/@schemeID` |

## How an integration ends up here

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

- The mapping writes a scheme name, such as `GLN`, where the numeric code is expected.
- A code taken from the EAS list is valid for EN 16931 but not among the schemes Peppol accepts.
- A fixed-width export pads the attribute with spaces.
- The code was stored as a number and lost its leading zeros, giving `88`.
- The ISO 6523 code of a party identifier was copied to the electronic address, and not every such code is an electronic address scheme.

## How to fix it

1. Use the finding location to see whether the seller or the buyer `cbc:EndpointID` is affected.
2. Take the scheme from the Peppol registration of that participant. A Peppol participant identifier is a scheme code and an identifier together, and `schemeID` must be that scheme code.
3. Write the code exactly as listed, four digits with leading zeros for the numeric codes, and no spaces.
4. Correct the scheme in the stored party data rather than only in the XML, so the EN 16931 and the Peppol checks see the same value.

## 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 electronic address is marked GLN

```xml
<cac:AccountingSupplierParty>
  <cac:Party>
    <cbc:EndpointID schemeID="GLN">7300010000001</cbc:EndpointID>
    <!-- postal address, tax scheme and legal entity omitted from this fragment -->
  </cac:Party>
</cac:AccountingSupplierParty>
```

Fragment of the corrected invoice: the seller electronic address uses scheme 0088

```xml
<cac:AccountingSupplierParty>
  <cac:Party>
    <cbc:EndpointID schemeID="0088">7300010000001</cbc:EndpointID>
    <!-- postal address, tax scheme and legal entity omitted from this fragment -->
  </cac:Party>
</cac:AccountingSupplierParty>
```

Only the scheme of the seller `cbc:EndpointID` differs: `GLN` in the failing invoice, `0088` in the corrected one, with the identifier `7300010000001` unchanged. The failing document also reports `BR-CL-25` on the EN 16931 layer, the EAS list check on the same attribute, because `GLN` is on neither list. One correction clears both findings.

### What the validator reported

- The failing invoice reports [BR-CL-25](https://ironfang.uk/docs/finance/rules/BR-CL-25.md) and **PEPPOL-EN16931-CL008**. The corrected document passes every layer with no findings.
  - [Download the failing XML](https://ironfang.uk/finance/rule-examples/PEPPOL-EN16931-CL008-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

- Invoice or credit note makes no difference. When tried, a credit note with `GLN` as the seller scheme reported the same pair of findings, and so did an invoice with `GLN` on the buyer address.
- A Peppol BIS Billing 3.0 rule, reported on the Peppol layer. The code list is the one in the pinned May 2026 release.
- A listed scheme shows the address is expressed in a form Peppol recognises. The validator does not look the participant up, so it cannot confirm that the address is registered or reachable.

## Related rules

- [BR-CL-25 checks the same attribute against the wider EAS list on the EN 16931 layer](https://ironfang.uk/docs/finance/rules/BR-CL-25.md)
- [BR-62 reports a seller EndpointID that has no schemeID attribute to check](https://ironfang.uk/docs/finance/rules/BR-62.md)
- [PEPPOL-COMMON-R040 checks the identifier itself when the scheme is 0088](https://ironfang.uk/docs/finance/rules/PEPPOL-COMMON-R040.md)
- [PEPPOL-EN16931-R020 requires the seller EndpointID in the first place](https://ironfang.uk/docs/finance/rules/PEPPOL-EN16931-R020.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-24.

[The official definition of PEPPOL-EN16931-CL008](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-peppol/PEPPOL-EN16931-CL008/) 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-CL008)
- [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