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

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.

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.

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

<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

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

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
• PEPPOL-COMMON-R040 checks the GLN itself once an identifier is marked 0088
• BR-CO-26 needs some seller identifier, and does not count one with the SEPA scheme
• BR-CL-21 checks the scheme of a standard item identifier against the same ICD list
• 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-24.1: source checked 2026-09-24, explanation last updated 2026-09-24.

The official definition of 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.