NL-R-003: Use scheme 0106 (KVK) or 0190 (OIN) for a Dutch seller legal identifier

The short answer

NL-R-003 fails when the seller is in the Netherlands and its cac:PartyLegalEntity/cbc:CompanyID has no schemeID of 0106 or 0190, or has no value. Send the Chamber of Commerce (KVK) number with schemeID="0106", or the organisation OIN with schemeID="0190".

In the recorded example the KVK number is there but the scheme attribute is not. Adding schemeID="0106" is the whole fix; the number stays the same.

What the rule checks

The rule applies when the seller postal address country code is NL, and it reads the seller cbc:CompanyID inside cac:PartyLegalEntity. It passes when schemeID is 0106 or 0190 and the element has a value; when tried, an OIN with 0190 passed.

Any other scheme fails, even one that is a valid ISO 6523 code: when tried, a GLN with scheme 0088 reported this rule. A missing schemeID fails, as the recorded example shows.

An empty identifier with the right scheme fails as well. When tried, schemeID="0106" with no number reported this rule, PEPPOL-EN16931-R008 and the KVK format warning PEPPOL-COMMON-R054.

The rule only judges an identifier that is sent. When tried, the Dutch example with no cbc:CompanyID in cac:PartyLegalEntity passed every layer, while a KVK number given only in cac:PartyIdentification did not help when the legal entity identifier lacked the scheme.

The number format is checked elsewhere and only as a warning: PEPPOL-COMMON-R054 expects eight digits for a KVK number and PEPPOL-COMMON-R055 twenty digits for an OIN. When tried, a seven-digit KVK number drew that warning and the document stayed valid.

How an integration ends up here

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

• The template writes cbc:CompanyID without schemeID, which the validator accepts for sellers outside the Netherlands.
• The legal entity identifier holds the VAT number or another registration, and the scheme follows that value.
• A GLN or another party identifier is copied into the legal entity identifier.

How to fix it

1. Find the seller KVK number (eight digits, from its Dutch Chamber of Commerce registration) or its OIN in the company master data.
2. Write it to cac:AccountingSupplierParty/cac:Party/cac:PartyLegalEntity/cbc:CompanyID with schemeID="0106" for a KVK number or schemeID="0190" for an OIN.
3. If the element currently holds a different identifier, such as the VAT number, move that value to where it belongs, cac:PartyTaxScheme/cbc:CompanyID for VAT, rather than relabelling it.
4. Store the scheme with the number in master data, so every document for the Dutch entity carries both.

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: a Dutch seller whose KVK number has no scheme

<cac:AccountingSupplierParty>
  <cac:Party>
    <!-- electronic address omitted from this fragment -->
    <cac:PostalAddress>
      <cbc:StreetName>Voorbeeldstraat 1</cbc:StreetName>
      <cbc:CityName>Amsterdam</cbc:CityName>
      <cbc:PostalZone>1011 AA</cbc:PostalZone>
      <cac:Country>
        <cbc:IdentificationCode>NL</cbc:IdentificationCode>
      </cac:Country>
    </cac:PostalAddress>
    <!-- VAT registration omitted from this fragment -->
    <cac:PartyLegalEntity>
      <cbc:RegistrationName>Example Supplier Ltd</cbc:RegistrationName>
      <cbc:CompanyID>12345678</cbc:CompanyID>
    </cac:PartyLegalEntity>
  </cac:Party>
</cac:AccountingSupplierParty>

Fragment of the corrected invoice: the KVK number carries scheme 0106

<cac:AccountingSupplierParty>
  <cac:Party>
    <!-- electronic address omitted from this fragment -->
    <cac:PostalAddress>
      <cbc:StreetName>Voorbeeldstraat 1</cbc:StreetName>
      <cbc:CityName>Amsterdam</cbc:CityName>
      <cbc:PostalZone>1011 AA</cbc:PostalZone>
      <cac:Country>
        <cbc:IdentificationCode>NL</cbc:IdentificationCode>
      </cac:Country>
    </cac:PostalAddress>
    <!-- VAT registration 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>

The only difference is schemeID="0106" on the seller legal entity cbc:CompanyID; the number 12345678 is the same in both. NL-R-003 is the only finding, because EN 16931 treats the scheme of a legal registration identifier as optional, so its layer passes.

Where it applies

• Applies to Invoice and CreditNote alike; when tried, the Dutch credit note with the scheme removed reported the same rule.
• A Dutch national rule in Peppol, reported in the Peppol layer. It depends on the seller postal address, not on the VAT number prefix: when tried, the same invoice with a GB VAT number still reported it.
• When the buyer is also in the Netherlands, NL-R-005 applies the same scheme requirement to the buyer legal identifier.
• The KVK number 12345678 and the VAT number NL123456789B01 in the recorded example are synthetic; use the registration numbers of the real seller.

Related rules

• BR-CO-26 needs at least one seller identifier, and the legal registration identifier this rule checks is one of the options
• NL-R-001 is the Dutch rule that makes a credit note reference the invoice it corrects
• NL-R-007 is the Dutch rule for payment means, evaluated on the same seller address
• Browse every rule in the reference
• Background: How Peppol invoice validation actually works

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 NL-R-003 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.