# BR-CL-26: Use an ISO 6523 ICD code as the scheme of the deliver-to location identifier
The `schemeID` on `cac:DeliveryLocation/cbc:ID` must be an ISO 6523 ICD code. A delivery point identified by its GLN takes `0088`, not `GLN`.
- 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-26/
- Explanation last updated: 2026-09-28
## The short answer
`BR-CL-26` fails when the `schemeID` of `cac:Delivery/cac:DeliveryLocation/cbc:ID` is not an ISO 6523 ICD code. The recorded delivery point was identified by its GLN with the scheme written as `GLN`; the ICD code for a GLN is `0088`.
Only the scheme attribute is judged. Leave it out when the location identifier comes from no registered scheme, such as your own depot number.
## What the rule checks
The rule applies to the `cbc:ID` directly inside `cac:DeliveryLocation` whenever it has a `schemeID`. When tried, the same identifier with the attribute removed passed every layer.
The value is trimmed and must then be one of the 243 ICD codes pinned for this release. When tried, ` 0088 ` passed, while `88` and the electronic address code `9930` both failed.
There is no exception for `SEPA` here, unlike on seller and payee identifiers: `SEPA` on the delivery location failed when tried.
The identifier itself is not validated. When tried, a GLN with a wrong check digit under `0088` passed, because the Peppol GLN check does not cover delivery locations.
| Term | Meaning | UBL element |
|---|---|---|
| BT-71 | Deliver to location identifier | `cac:Delivery/cac:DeliveryLocation/cbc:ID` |
| BT-71-1 | Deliver to location identifier: its scheme identifier attribute | `cac:Delivery/cac:DeliveryLocation/cbc:ID/@schemeID` |
## How an integration ends up here
Possible causes, from the shape of the rule rather than from measured usage:
- The scheme is written as the name of the identifier type, such as `GLN`, as in the recorded example.
- The code is stored as a number and reaches the XML without its leading zeros.
- The scheme of the buyer electronic address is copied to the delivery location, bringing a code from the electronic address list, such as `9930`, that the ICD list does not contain.
## How to fix it
1. Find out which scheme issued the location identifier. A delivery point identified by a GS1 location number uses `0088`.
2. Write the four-digit ICD code, with its leading zeros and no spaces, in `schemeID`.
3. For an internal location code with no registered scheme, send `cbc:ID` without `schemeID`.
4. Check the GLN check digit in your own system before sending it; the validator does not do it for this element.
## 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 delivery location GLN is marked with the scheme GLN
```xml
2026-09-07
7300010000001
```
Fragment of the corrected invoice: the same GLN under ICD code 0088
```xml
2026-09-07
7300010000001
```
Only the scheme of the deliver-to location identifier differs: `GLN` in the failing invoice, `0088` in the corrected one, with the same GLN `7300010000001`. The failing document reports `BR-CL-26` alone, and the Peppol layer passed.
### What the validator reported
- The failing invoice reports **BR-CL-26**. The corrected document passes every layer with no findings.
- [Download the failing XML](https://ironfang.com/finance/rule-examples/BR-CL-26-invalid.xml)
- [Download the corrected XML](https://ironfang.com/finance/rule-examples/codelist-delivery-location-valid.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 `Invoice` and `CreditNote`; when tried, `GLN` on the delivery location of a credit note reported this rule alone.
- An EN 16931 rule. The same ICD list serves `BR-CL-10` for party identifiers and `BR-CL-11` for legal registration identifiers.
- The deliver-to address has checks of its own: `BR-57` requires its country code, and `BR-CL-14` checks that code.
## Related rules
- [BR-CL-11 applies the same ICD list to the legal registration identifiers of the parties](https://ironfang.com/docs/finance/rules/BR-CL-11.md)
- [BR-CL-15 checks the item country of origin, which says where goods were made rather than where they go](https://ironfang.com/docs/finance/rules/BR-CL-15.md)
- [PEPPOL-COMMON-R040 checks GLN check digits on endpoints, party identifiers and registration numbers, but not here](https://ironfang.com/docs/finance/rules/PEPPOL-COMMON-R040.md)
- [BR-CL-10 accepts the same ICD codes on party identifiers, plus SEPA for sellers and payees](https://ironfang.com/docs/finance/rules/BR-CL-10.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-28.1: source checked 2026-09-28, explanation last updated 2026-09-28.
[The official definition of BR-CL-26](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-CL-26/) 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.com/docs/finance/rules/BR-CL-26)
- [Free Peppol invoice validator](https://ironfang.com/tools/peppol-validator)
- [Rule index](https://ironfang.com/docs/finance/rules.md)
- [Ironfang Finance API docs](https://ironfang.com/docs/finance)
- The same rule is available to MCP clients as the tool `finance.rule.get` on https://mcp.ironfang.com/mcp