# BR-CL-11: Use an ISO 6523 ICD code as the scheme of a legal registration identifier

The `schemeID` on `cac:PartyLegalEntity/cbc:CompanyID` must be an ISO 6523 ICD code, such as `0106` for the Dutch KVK register, not a register name.

- 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-11/
- Explanation last updated: 2026-09-28

## The short answer

`BR-CL-11` fails when `cbc:CompanyID` in a `cac:PartyLegalEntity` has a `schemeID` that is not an ISO 6523 ICD code. Write the four-digit code of the register that issued the number: the recorded Dutch seller wrote `KVK`, the abbreviation of the Dutch chamber of commerce register, whose ICD code is `0106`.

Seller, buyer and payee registrations are all checked. In the recorded example the same value also broke `NL-R-003`, because a seller in the Netherlands must register its legal identifier under `0106` or `0190`.

## What the rule checks

Every `cbc:CompanyID` under a `cac:PartyLegalEntity` that has a `schemeID` is tested. When tried, `GLN` on the registration of the buyer and on that of the payee was each reported by this rule at its own location.

The attribute is trimmed and then compared exactly with the ICD codes pinned for this release: `0002` to `0248`, without `0092`, `0103`, `0181` and `0182`. When tried, ` 0060 ` with spaces passed and `0092` failed.

The list is the one `BR-CL-10` uses for party identifiers, without its exception: `SEPA` is not accepted on a legal registration identifier.

A registration number without `schemeID` is not tested. The attribute is optional in EN 16931, although national rules such as `NL-R-003` can require a particular scheme.

| Term | Meaning | UBL element |
|---|---|---|
| BT-30-1 | Seller legal registration identifier identification scheme identifier | `cac:AccountingSupplierParty/cac:Party/cac:PartyLegalEntity/cbc:CompanyID/@schemeID` |
| BT-47-1 | Buyer legal registration identifier identification scheme identifier | `cac:AccountingCustomerParty/cac:Party/cac:PartyLegalEntity/cbc:CompanyID/@schemeID` |
| BT-61-1 | Payee legal registration identifier identification scheme identifier | `cac:PayeeParty/cac:PartyLegalEntity/cbc:CompanyID/@schemeID` |

## How an integration ends up here

Possible causes, from the shape of the rule rather than from measured usage:

- The name or abbreviation of the register, such as `KVK`, `CRN` or `SIREN`, is written in place of its ICD code.
- The code passes through a numeric field and loses its leading zero, so `0106` arrives as `106`.
- A code from the electronic address list, such as a `99xx` code, is copied from `cbc:EndpointID`, where the scheme list is a different one.

## How to fix it

1. Use the finding location to see whether the seller, buyer or payee registration is affected.
2. Identify the register that issued the number and look up its ICD code: `0106` for the Dutch KVK, `0190` for the Dutch OIN, `0007` for a Swedish organisation number, `0208` for a Belgian enterprise number.
3. Write it as four digits with leading zeros and no spaces.
4. If the register has no ICD code, send the number without `schemeID` rather than inventing one, unless a national rule for that country requires a scheme.

## 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 Dutch seller marks its registration number KVK

```xml
<cac:AccountingSupplierParty>
  <cac:Party>
    <!-- endpoint omitted from this fragment -->
    <cac:PostalAddress>
      <!-- street, city and postcode omitted from this fragment -->
      <cac:Country>
        <cbc:IdentificationCode>NL</cbc:IdentificationCode>
      </cac:Country>
    </cac:PostalAddress>
    <!-- tax scheme omitted from this fragment -->
    <cac:PartyLegalEntity>
      <cbc:RegistrationName>Example Supplier Ltd</cbc:RegistrationName>
      <cbc:CompanyID schemeID="KVK">12345678</cbc:CompanyID>
    </cac:PartyLegalEntity>
  </cac:Party>
</cac:AccountingSupplierParty>
```

Fragment of the corrected invoice: the same number under ICD code 0106

```xml
<cac:AccountingSupplierParty>
  <cac:Party>
    <!-- endpoint omitted from this fragment -->
    <cac:PostalAddress>
      <!-- street, city and postcode omitted from this fragment -->
      <cac:Country>
        <cbc:IdentificationCode>NL</cbc:IdentificationCode>
      </cac:Country>
    </cac:PostalAddress>
    <!-- tax scheme omitted from this fragment -->
    <cac:PartyLegalEntity>
      <cbc:RegistrationName>Example Supplier Ltd</cbc:RegistrationName>
      <cbc:CompanyID schemeID="0106">12345678</cbc:CompanyID>
    </cac:PartyLegalEntity>
  </cac:Party>
</cac:AccountingSupplierParty>
```

Only the `schemeID` of the seller registration differs: `KVK` in the failing invoice, `0106` in the corrected one, for the same number `12345678`. The failing document also reports `NL-R-003`, the Dutch rule that accepts only `0106` or `0190` from a seller in the Netherlands; correcting the scheme clears both.

### What the validator reported

- The failing invoice reports **BR-CL-11** and [NL-R-003](https://ironfang.com/docs/finance/rules/NL-R-003.md). The corrected document passes every layer with no findings.
  - [Download the failing XML](https://ironfang.com/finance/rule-examples/BR-CL-11-invalid.xml)
  - [Download the corrected XML](https://ironfang.com/finance/rule-examples/netherlands-supplier-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, `KVK` on the registration of a British seller in a credit note reported this rule alone.
- An EN 16931 rule. Country rules can add findings for the same value: `NL-R-003` here, and there are similar rules on the registration scheme of Danish and Icelandic sellers.
- Once the scheme is valid, the Peppol layer checks some numbers themselves, such as the GLN check digit under `0088`.

## Related rules

- [BR-CL-10 applies the same ICD list to party identifiers, where SEPA is also accepted](https://ironfang.com/docs/finance/rules/BR-CL-10.md)
- [NL-R-003 narrows the choice to 0106 or 0190 for sellers in the Netherlands](https://ironfang.com/docs/finance/rules/NL-R-003.md)
- [BR-CL-26 applies the same ICD list to a deliver-to location identifier](https://ironfang.com/docs/finance/rules/BR-CL-26.md)
- [BR-CL-07 checks object identifiers, which take UNTDID 1153 qualifiers rather than ICD codes](https://ironfang.com/docs/finance/rules/BR-CL-07.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-11](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-CL-11/) 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-11)
- [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