Can you derive a Dutch VAT number from a KVK number?

The pattern, and why it is only a pattern

A Dutch VAT number looks like NL followed by nine digits, then B, then two digits. The nine digit block is formally the RSIN, the tax identification number of the legal entity. The two digit suffix is a subnumber, usually 01.

Because both numbers are issued by the Chamber of Commerce and look similar in length, people assume the RSIN is just the KVK number with a leading zero. It is not, and building a VAT number that way produces a string the tax authority never issued:

KVK number   68750110        (8 digits)
RSIN         850123458       (9 digits)
VAT number   NL850123458B01

The KVK number identifies the registration. The RSIN identifies the legal entity for tax purposes. One entity has both, and there is no formula between them. The important framing for anyone integrating from abroad: the VAT number is not encoded in the company number the way it is in some other member states, so a lookup is the only route.

Once you do have the RSIN, NL{RSIN}B01 is a reasonable candidate for a BV or NV, and that is the point where verification starts rather than ends.

Where it breaks

The fiscal unity case is the one that generates support tickets, because the company is real, active, solvent and perfectly able to receive an invoice. It just does not answer on the number you calculated.

What the API does

Our lookup attempts the derivation only for the legal forms where it is worth attempting: codes 41 (BV), 42 (NV), 73 (BV in formation) and 74 (NV in formation). For every other legal form there is no vat block, because a guess would be worse than nothing.

When it does attempt it, it does not stop at the candidate. It sends the number to VIES, the European Commission’s VAT information exchange system, and reports what VIES said:

"vat": {
  "number": "NL850123458B01",
  "valid": true,
  "validatedAt": "2026-08-22T09:14:00Z"
}

valid: false means the derivation produced a number that VIES does not recognise. It does not mean the company has no VAT number. In practice that distinction matters: you should show the user “we could not confirm a VAT number, please enter it” rather than “this company is not VAT registered”.

If you already have a VAT number from the customer, skip the derivation entirely and validate what they gave you:

curl "https://api.kvkbase.nl/v1/validate/vat/NL850123458B01" \
  -H "Authorization: Bearer YOUR_API_KEY"

The mechanics of VIES, including its rate behaviour and what the response actually guarantees, are covered in the VAT number validation guide.

The production gotcha: caching a false

The failure mode we see most is caching the negative. A team derives a VAT number, VIES says invalid, and they persist vat_valid = false on the customer record forever. Three weeks later the customer registers for VAT, or leaves the fiscal unity, or the derivation was wrong all along, and the invoice still goes out with domestic VAT on a cross border sale.

Cache the positive result with its validatedAt timestamp and treat a negative as a prompt rather than a fact. If you invoice under the reverse charge, revalidate at invoice time, not at signup time. The number you are legally relying on is the one that was valid on the invoice date.

One last detail for non Dutch teams: VIES validates format and existence, not ownership. A syntactically valid, VIES confirmed VAT number tells you the number is live. It does not tell you it belongs to the company whose KVK number you started from. If that link matters for your risk model, compare the name VIES returns against statutoryName from the enriched lookup, and expect punctuation differences around “B.V.” to make exact string matching useless.