# BR-CL-25: Use an EAS code as the schemeID of an electronic address

The schemeID on every cbc:EndpointID must be a code from the Electronic Address Scheme (EAS) list, such as 0088, matched exactly.

- Layer: EN 16931
- Severity: fatal (the document is invalid)
- Topics: Code lists, Parties and addresses
- Official definition: https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-CL-25/
- Explanation last updated: 2026-09-20

## The short answer

`BR-CL-25` fails when a `cbc:EndpointID` has a `schemeID` that is not in the EAS code list shipped with the validation artefacts. Replace it with the EAS code for the scheme the identifier was really issued under, for example `0088` for a GLN.

The message does not say which party is affected. Check the `schemeID` on both the seller and the buyer `cbc:EndpointID`.

## What the rule checks

The rule runs on every `cbc:EndpointID` in the document that has a `schemeID` attribute. Under Peppol that means the seller and buyer addresses; an `cbc:EndpointID` on any other party would be tested as well. An element without the attribute is skipped here and reported by `BR-62` or `BR-63`.

Leading and trailing white space is ignored, and what remains must be exactly one code from the list. The match is case-sensitive, so `em` fails where `EM` is a listed code. An empty attribute, `schemeID=""`, fails.

Only the scheme code is tested. Whether the identifier fits the scheme is a separate matter: Peppol checks the value format for some schemes, and a `0088` identifier with a wrong check digit reports `PEPPOL-COMMON-R040`.

Peppol tests the same attribute against its own list in `PEPPOL-EN16931-CL008`, and that check is the stricter of the two. `schemeID=" 0088 "` passes `BR-CL-25` and fails `PEPPOL-EN16931-CL008`; so does `EM`, which is on the EN 16931 list and not accepted by the Peppol rule in this release.

| 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 the name of the scheme, such as `GLN`, where the four-character code is expected.
- The code lost its leading zeros on the way through a numeric column or a spreadsheet, turning `0088` into `88`.
- An internal identifier type from the source system is passed through unchanged.
- The scheme column is empty and the serialiser still writes the attribute, producing `schemeID=""`.
- The value comes from another code list. ISO 6523 ICD codes used for `cac:PartyIdentification` and `cac:PartyLegalEntity` overlap with EAS only in part.

## How to fix it

1. Work out which party the finding belongs to by reading the `schemeID` on each `cbc:EndpointID`.
2. Identify the scheme of the stored identifier and look up its EAS code. If the identifier has no EAS scheme it cannot serve as the electronic address; obtain one that does from the party concerned.
3. Store the code as text, four characters with any leading zeros, and write it to `schemeID` without padding.
4. Do not swap in a listed code only because it passes. A code that does not describe the identifier produces an address that points nowhere, or at someone else.

## Before and after

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

Fragment of the failing invoice: XXXX is not an EAS code

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

Fragment of the corrected invoice: 0088 is the EAS code for a GLN

```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 `schemeID` on the seller `cbc:EndpointID` differs: `XXXX` in the failing file, `0088` in the corrected one. The failing document also reports `PEPPOL-EN16931-CL008`, because Peppol checks the same attribute against its own list of electronic address schemes and `XXXX` is on neither. Correcting the code clears both findings.

### What the validator reported

- The failing invoice reports **BR-CL-25** and [PEPPOL-EN16931-CL008](https://ironfang.uk/docs/finance/rules/PEPPOL-EN16931-CL008.md). The corrected document passes every layer with no findings.
  - [Download the failing XML](https://ironfang.uk/finance/rule-examples/invoice-unknown-endpoint-scheme.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`. A credit note with an unknown scheme on the buyer address reports the same pair of findings.
- The list is the one pinned in the EN 16931 1.3.16 artefacts. EAS is revised from time to time, so a code added or withdrawn upstream takes effect here only with a new artefact release.
- A listed scheme and a well-formed identifier describe an address; they do not show that anyone is registered at it. The validator does not query the Peppol network, so reachability has to be confirmed separately.

## Related rules

- [BR-62 reports a seller EndpointID that has no schemeID attribute](https://ironfang.uk/docs/finance/rules/BR-62.md)
- [BR-63 reports a buyer EndpointID that has no schemeID attribute](https://ironfang.uk/docs/finance/rules/BR-63.md)
- [PEPPOL-EN16931-R020 requires the seller EndpointID to be present](https://ironfang.uk/docs/finance/rules/PEPPOL-EN16931-R020.md)
- [PEPPOL-EN16931-R010 requires the buyer EndpointID to be present](https://ironfang.uk/docs/finance/rules/PEPPOL-EN16931-R010.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 BR-CL-25](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-CL-25/) 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/BR-CL-25)
- [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