# BR-CL-10: Use an ISO 6523 ICD code as the scheme of a party identifier

The `schemeID` on a `cac:PartyIdentification/cbc:ID` must be an ISO 6523 ICD code, such as `0088` for a GLN. `SEPA` is allowed for seller and payee only.

- 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-10/
- Explanation last updated: 2026-09-24

## The short answer

`BR-CL-10` fails when a `cac:PartyIdentification/cbc:ID` has a `schemeID` that is not a code from the ISO 6523 ICD list. Replace the value with the four-digit ICD code of the scheme that issued the identifier: `0088` for a GLN, not `GLN`.

The finding location names the party. In the recorded example it is the seller, but buyer and payee identifiers are checked in the same way.

## What the rule checks

The rule runs on every `cbc:ID` inside a `cac:PartyIdentification` that carries a `schemeID` attribute. Without the attribute nothing is tested: when tried, the seller identifier with its `schemeID` removed passed every layer.

The value, with surrounding spaces removed, must equal one listed code exactly, and case matters. The ICD codes in this release run from `0002` to `0248`, with four numbers in that range absent. `88` fails because the leading zeros are part of the code.

One exception is written into the rule: `SEPA` is accepted on seller and payee identifiers, where it marks the SEPA creditor identifier used for direct debit. When tried, `SEPA` on the seller passed, `sepa` on the seller failed, and `SEPA` on the buyer failed.

The electronic address list is a different list. Its `99xx` codes are not ICD codes: when tried, `9930` on the seller identifier failed this rule.

The legal registration identifier in `cac:PartyLegalEntity/cbc:CompanyID` is checked against the same list by a separate rule, `BR-CL-11`. When tried, `schemeID="GLN"` there reported `BR-CL-11`, not this rule.

| Term | Meaning | UBL element |
|---|---|---|
| BT-29 | Seller identifier: its scheme identifier attribute | `cac:AccountingSupplierParty/cac:Party/cac:PartyIdentification/cbc:ID/@schemeID` |
| BT-46 | Buyer identifier: its scheme identifier attribute | `cac:AccountingCustomerParty/cac:Party/cac:PartyIdentification/cbc:ID/@schemeID` |
| BT-60 | Payee identifier: its scheme identifier attribute | `cac:PayeeParty/cac:PartyIdentification/cbc:ID/@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` or `DUNS` where the ICD code is expected.
- The code passes through a numeric field and loses its leading zeros.
- The scheme of the electronic address is reused for the party identifier, bringing a `99xx` code that only the electronic address list has.
- A SEPA creditor identifier is attached to the buyer, where the rule does not accept the `SEPA` scheme.
- An internal customer or supplier number is sent with a `schemeID` naming the source system.

## How to fix it

1. Use the finding location to see which party identifier is affected.
2. Establish which scheme issued the identifier, for example GS1 for a GLN or a national business register, and look up its ICD code.
3. Write that code to `schemeID` as text, with its leading zeros: `schemeID="0088"`.
4. If the identifier comes from no registered scheme, such as your own account number for the customer, send it without a `schemeID`. The attribute is optional on party identifiers, and a code that does not describe the identifier misleads the receiver.
5. Keep `SEPA` for the SEPA creditor identifier on the seller or payee.

## 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 identifier is marked with the scheme name GLN

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

Fragment of the corrected invoice: the seller identifier uses ICD code 0088

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

Only the `schemeID` on the seller identifier differs: `GLN` in the failing invoice, `0088` in the corrected one, with the same GLN in both. The failing document reports `BR-CL-10` and nothing else. The Peppol GLN check digit rule, `PEPPOL-COMMON-R040`, recognises a GLN only by `schemeID="0088"`, so it skipped the identifier in the failing file and found the check digit correct in the corrected one.

### What the validator reported

- The failing invoice reports **BR-CL-10**. The corrected document passes every layer with no findings.
  - [Download the failing XML](https://ironfang.uk/finance/rule-examples/BR-CL-10-invalid.xml)
  - [Download the corrected XML](https://ironfang.uk/finance/rule-examples/invoice-rich.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

- Credit notes are checked in the same way. When tried, `GLN` on the seller identifier of a credit note reported `BR-CL-10` alone.
- The electronic address in `cbc:EndpointID` is judged against the EAS list instead, by `BR-CL-25` and `PEPPOL-EN16931-CL008`. A GLN is `0088` in both lists.
- An EN 16931 code list rule. The list is the one pinned with this release of the artefacts; a code added to ISO 6523 later is accepted only once a new release includes it.
- Item identifiers are not covered. The scheme of a standard item identifier has its own rule, `BR-CL-21`.

## Related rules

- [BR-CL-25 checks the scheme of the electronic address, which uses the EAS list instead](https://ironfang.uk/docs/finance/rules/BR-CL-25.md)
- [PEPPOL-COMMON-R040 checks the GLN itself once an identifier is marked 0088](https://ironfang.uk/docs/finance/rules/PEPPOL-COMMON-R040.md)
- [BR-CO-26 needs some seller identifier, and does not count one with the SEPA scheme](https://ironfang.uk/docs/finance/rules/BR-CO-26.md)
- [BR-CL-21 checks the scheme of a standard item identifier against the same ICD list](https://ironfang.uk/docs/finance/rules/BR-CL-21.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 BR-CL-10](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-CL-10/) 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-10)
- [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