Skip to content

Ironfang Finance - Rule reference

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.

EN 16931Fatal: the document is invalidCode listsParties and addresses

On this page

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.

TermMeaningUBL element
BT-30-1Seller legal registration identifier identification scheme identifiercac:AccountingSupplierParty/cac:Party/cac:PartyLegalEntity/cbc:CompanyID/@schemeID
BT-47-1Buyer legal registration identifier identification scheme identifiercac:AccountingCustomerParty/cac:Party/cac:PartyLegalEntity/cbc:CompanyID/@schemeID
BT-61-1Payee legal registration identifier identification scheme identifiercac: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.

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

<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

<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

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.

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