What is a KVK number?

What the number actually identifies

If you are integrating Dutch company data from outside the Netherlands, the first thing to get straight is that a KVK number identifies an inschrijving, a registration in the trade register, and nothing more. It does not tell you that a company exists as a legal person, that it is trading, or that it can issue a valid VAT invoice.

Three consequences follow from that, and all three bite in production:

• A sole trader has a KVK number but no legal personality and no statutory name.
• A company that has been dissolved keeps its KVK number. The number resolves fine, the registration is just marked inactive.
• A company with fifteen locations has one KVK number covering all of them. Locations are identified separately by a twelve digit vestigingsnummer.

Here is roughly how it lines up against registers you may already integrate with.

The French SIREN is the closest analogue, because it also covers self employed people and also has a separate establishment level identifier (SIRET in France, vestigingsnummer in the Netherlands).

Format, validation and the leading zero problem

A KVK number is exactly eight digits and may start with a zero. There is a checksum, and validating it locally before you spend an API call is worth doing. The rules are written up in full in KVK number validation rules and checksum, so they are not repeated here.

The failure that actually costs people a day of debugging is not the checksum. It is type coercion. A customer sends a spreadsheet, the CSV importer parses 01234567 as a number, and you end up looking up 1234567, which is seven digits and rejected with INVALID_KVK_NUMBER. The same thing happens when a JSON payload declares the field as an integer, and again when a database column is INT.

Treat the KVK number as a string everywhere: in your schema, in your API contract, in your CSV import, and in the form field. Strip spaces and dots on input, then left pad to eight characters.

Looking one up

A lookup takes the number and returns the registration.

curl "https://api.kvkbase.nl/v1/lookup/68750110" \
  -H "Authorization: Bearer YOUR_API_KEY"

The base response gives you kvkNumber, name, legalForm, address, isActive, registrationDate, activities and insolvency. Adding ?enrich=true adds the fields that need extra work to assemble: statutoryName, tradingNames, postalAddress, employees, websites and totalBranches.

If all you need is a yes or no on whether a number is real, there is a cheaper call that does not return a profile:

curl "https://api.kvkbase.nl/v1/verify/68750110" \
  -H "Authorization: Bearer YOUR_API_KEY"

Use that one behind a signup form where you are validating input, and save the full lookup for the moment you actually need the data. A full walkthrough of the lookup flow lives in the KVK number lookup guide.

When a KVK number is the wrong key

There is one case where keying on the KVK number is not enough: multi location businesses. A logistics customer with a head office in Rotterdam and three depots elsewhere sends you one KVK number and four delivery addresses. If your model has a single address per company, you have already lost information that the register was happy to give you.

If your product cares about where the counterparty is, key on the KVK number for the legal relationship and store vestigingsnummers for the locations. Fetching them is one extra call to /v1/lookup/{kvkNumber}/branches.

The other case is tax. If you are issuing cross border invoices, the number that matters for the reverse charge is the VAT number validated against VIES, not the KVK number. A valid KVK number proves the company is registered. It proves nothing at all about its VAT position.