KVK extract (uittreksel) vs API data

Two different products from the same register

The Dutch word uittreksel means extract. A KVK uittreksel is a PDF the Chamber of Commerce issues on request, showing what the register says about a registration at that moment: the KVK number, the statutory name, the legal form, the registered address, the registration date, the activity codes and the establishments. There is a version for the entity and a version per establishment.

An API gives you the same facts, but the object you get back is data, not evidence. That distinction is the whole decision.

When you genuinely need the document

Ask for an uittreksel when a third party needs to be convinced, not when your code needs a value:

• Opening a bank account for a Dutch entity, in the Netherlands or abroad.
• Notarial deeds, share transfers, and anything a civil law notary touches.
• Court filings and enforcement, where you must show the counterparty exists and who may sign.
• Tenders and procurement, where the tender documents specify a maximum extract age.
• Foreign authorities who need a document to legalise or apostille. There is no way to apostille a JSON response.

For an international audience the last one comes up more than you would expect. If you are registering a Dutch subsidiary’s presence in another country, that country’s registry wants paper from the Dutch registry, and no amount of API access substitutes.

When the API is the right tool

Everything that happens inside your software: validating a KVK number at checkout, prefilling a company name and address, segmenting by SBI code, monitoring whether existing customers are still active, enriching a CRM. All of that is data work, and a PDF is a terrible input for it.

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

The enriched response is the closest analogue to what an extract shows on paper: statutoryName, tradingNames, legalForm, address, postalAddress, registrationDate, activities, totalBranches and isActive. What it deliberately does not carry is officers and signing authority, which is one of the main reasons an extract still exists.

The mistake worth avoiding: treating a customer supplied PDF as current

The pattern we see in onboarding flows is a form field that says “upload your KVK extract”. A customer uploads one. Somebody eyeballs it, the deal proceeds, and the PDF sits in a folder as the record of truth.

Two things are wrong with that. The PDF is a snapshot from the moment it was issued, which may be a year before the upload, and nothing in your system will ever notice that the company was dissolved in the meantime. And a PDF is not queryable, so when you later need to answer “which of our customers are foundations”, you cannot.

The workable pattern is both, with different jobs. Take the extract if your compliance process requires a document, but parse the KVK number out of it and use that number as your key. Then poll the register through the API on a schedule so the status stays fresh, and keep the PDF purely as the evidence artefact it is. There is a working approach to the polling side in KVK company status monitoring.

One practical detail if you do parse extracts: the statutory name on the document includes the legal form suffix, and Dutch punctuation of “B.V.” is inconsistent in the wild. Normalise before you compare it to anything.

If you need both and want to keep the process simple, order the extract once at onboarding for the compliance file, and let the API own everything that changes afterwards. That split keeps a document where a document is required, keeps your database queryable, and means nobody has to reopen a PDF to answer a question your own system can already answer.