# NL-R-003: Use scheme 0106 (KVK) or 0190 (OIN) for a Dutch seller legal identifier
When the seller address is in the Netherlands, `cac:PartyLegalEntity/cbc:CompanyID` needs a value and `schemeID` `0106` (KVK) or `0190` (OIN).
- Layer: Peppol BIS Billing
- Severity: fatal (the document is invalid)
- Topics: Parties and addresses
- Official definition: https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-peppol/NL-R-003/
- Explanation last updated: 2026-09-24
## 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.
| Term | Meaning | UBL element |
|---|---|---|
| BT-30 | Seller legal registration identifier | `cac:AccountingSupplierParty/cac:Party/cac:PartyLegalEntity/cbc:CompanyID` |
| BT-30-1 | Seller legal registration identifier identification scheme identifier | `cac:AccountingSupplierParty/cac:Party/cac:PartyLegalEntity/cbc:CompanyID/@schemeID` |
| BT-40 | Seller country code | `cac:AccountingSupplierParty/cac:Party/cac:PostalAddress/cac:Country/cbc:IdentificationCode` |
## 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.
## 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
```xml
Voorbeeldstraat 1
Amsterdam
1011 AA
NL
Example Supplier Ltd
12345678
```
Fragment of the corrected invoice: the KVK number carries scheme 0106
```xml
Voorbeeldstraat 1
Amsterdam
1011 AA
NL
Example Supplier Ltd
12345678
```
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.
### What the validator reported
- The failing invoice reports **NL-R-003**. The corrected document passes every layer with no findings.
- [Download the failing XML](https://ironfang.uk/finance/rule-examples/NL-R-003-invalid.xml)
- [Download the corrected XML](https://ironfang.uk/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` 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](https://ironfang.uk/docs/finance/rules/BR-CO-26.md)
- [NL-R-001 is the Dutch rule that makes a credit note reference the invoice it corrects](https://ironfang.uk/docs/finance/rules/NL-R-001.md)
- [NL-R-007 is the Dutch rule for payment means, evaluated on the same seller address](https://ironfang.uk/docs/finance/rules/NL-R-007.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-24.1: source checked 2026-09-24, explanation last updated 2026-09-24.
[The official definition of NL-R-003](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-peppol/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.
## Links
- [This rule as a web page](https://ironfang.uk/docs/finance/rules/NL-R-003)
- [Free Peppol invoice validator](https://ironfang.uk/tools/peppol-validator)
- [Rule index](https://ironfang.uk/docs/finance/rules.md)
- [Ironfang Finance API docs](https://ironfang.uk/docs/finance)
- The same rule is available to MCP clients as the tool `finance.rule.get` on https://mcp.ironfang.uk/mcp