BR-CL-26: Use an ISO 6523 ICD code as the scheme of the deliver-to location identifier

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.

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.

Validate your corrected invoice

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

<cac:Delivery>
  <cbc:ActualDeliveryDate>2026-09-07</cbc:ActualDeliveryDate>
  <cac:DeliveryLocation>
    <cbc:ID schemeID="GLN">7300010000001</cbc:ID>
  </cac:DeliveryLocation>
</cac:Delivery>

Fragment of the corrected invoice: the same GLN under ICD code 0088

<cac:Delivery>
  <cbc:ActualDeliveryDate>2026-09-07</cbc:ActualDeliveryDate>
  <cac:DeliveryLocation>
    <cbc:ID schemeID="0088">7300010000001</cbc:ID>
  </cac:DeliveryLocation>
</cac:Delivery>

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.

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
• BR-CL-15 checks the item country of origin, which says where goods were made rather than where they go
• PEPPOL-COMMON-R040 checks GLN check digits on endpoints, party identifiers and registration numbers, but not here
• BR-CL-10 accepts the same ICD codes on party identifiers, plus SEPA for sellers and payees
• Browse every rule in the reference
• Background: Understanding EN 16931 validation errors

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