Trade name vs statutory name in Dutch company data

Two kinds of name, two jobs

Dutch company data carries names that mean different things, and the Dutch words are worth learning because they appear untranslated in every register export.

• Statutaire naam, the statutory name. Fixed in the notarial deed of incorporation and changeable only by a new deed. It ends in the legal form suffix: B.V., N.V., and so on. This is the legal person.
• Handelsnaam, the trade name. The name the business presents to the market. Registering one is cheap, a company can hold many, and they can be added or dropped without touching the deed.

Closest equivalents elsewhere: the UK distinction between a registered name and “trading as”, or the German Firma versus Geschäftsbezeichnung. The Dutch case differs in that trade names are actually recorded in the register rather than left informal, so you can retrieve them.

A concrete shape of the problem: a holding company called Van Dijk Beheer B.V. runs two web shops, Fietsen Direct and Bikes.nl. Your customer knows the shop. Your finance system needs the holding. Both facts are in the register, attached to one KVK number.

What the API returns

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

Note that name is not a synonym for either of the other two. For a BV it usually matches the statutory name. For a sole trader there is no statutory name at all, so name is the trade name and statutoryName will be absent. Code that reads statutoryName without a fallback will produce blank invoice headers for every freelancer you onboard, and freelancers are a large share of Dutch registrations.

The safe accessor is: statutory name if present, otherwise name, and never the first element of tradingNames.

Matching user input against names

If you have a company search box, users type trade names. They type bikes.nl, not Van Dijk Beheer B.V.. That means your matching has to look at tradingNames, and it means exact matching is hopeless. The variations that show up in real input:

• legal form suffix present or absent, with or without dots (B.V., BV, bv)
• Dutch articles and prepositions ordered differently (Bakker, De versus De Bakker)
• diacritics, which users omit and the register does not
• ampersands, hyphens and dots inside names

Normalise both sides before comparing: lowercase, strip the legal form suffix, fold diacritics, collapse whitespace and punctuation. Then compare. Even after that, expect a shortlist rather than a single hit and put the address next to each candidate so the user can pick, since the address is what they will recognise.

For a typeahead field, /v1/autocomplete and /v1/suggest do this work for you and are the right call for interactive input. Reserve /v1/search for background matching where you can afford to review results.

The gotcha: a name change does not change anything you keyed on

Rebrands happen. Fietsen Direct becomes Cycle Point, the trade name changes in the register, and the next enrichment run overwrites the name on your customer record. If any part of your system used the name as an identifier, and something always does, it breaks: saved search filters, report groupings, a matching rule in an ETL job, a Slack alert that looks for a string.

Two habits prevent it. Key everything on kvkNumber, which survives every rename, merger and legal form conversion. And when you refresh names, keep the previous value with a timestamp rather than overwriting, so an invoice raised in March can still show the name the company had in March. Dutch invoicing rules care about the party, not the label, but your customer support team will care very much about the label when a client says they never did business with a company by that name.

For display, the pragmatic rule is to show the name the user recognises and record the name the law recognises. Put the trade name in the interface, the statutory name on the document, and the KVK number in the database. Those three answer different questions and trying to make one field serve all three is what produces the mismatch a customer eventually reports.