Legal forms in the Dutch business register

The codes and what they mean

The Dutch register classifies every entry by legal form (rechtsvorm). These are the ones you will meet.

Rough equivalents if you already model other markets: BV is a GmbH or a UK Ltd, NV is an AG or a plc, VOF is an OHG or a general partnership, CV is a KG, maatschap is the form used by professional partnerships such as doctors and accountants, stichting is a foundation and is extremely common in Dutch healthcare, education and housing.

Why the code changes your integration

This is not taxonomy for its own sake. Four concrete behaviours depend on it.

Statutory name. Only entities incorporated by deed have one. For legal form 01 and the partnerships, statutoryName is absent. Code that assumes it is present will render empty invoice headers for freelancers.

VAT derivation. Our API builds a candidate only for a BV or NV, and only when the entity’s RSIN is available, as NL{RSIN}B01, then checks it against VIES. Note the numeric block is the RSIN and not the KVK number. For any other legal form there is no vat block, and the honest UX is to ask the user.

Liability and credit. With a sole trader or a partnership you are contracting with people, and their personal assets are in scope. With a BV you are contracting with a balance sheet you cannot see. Neither is automatically safer, but they call for different checks.

Signing authority. A stichting is run by a board with rules set in its own articles. A VOF partner can usually bind the partnership. If your process depends on knowing who may sign, the legal form tells you what question to ask, and the answer itself is not in the public dataset.

The forms that surprise people

Stichting (53). English speakers read “foundation” as charity. Dutch foundations run hospitals, universities, pension administrators and housing corporations with budgets in the hundreds of millions. Do not put them in a low value segment because of the word.

Maatschap (71). A professional partnership with no legal personality, common in medical and legal practices. Each partner is liable for their own share. It bills like a company and is not one.

BV in oprichting (73). The riskiest thing on the list and the easiest to miss, because the name in the register already reads like a normal BV. The deed has not been executed, so there is no legal entity yet, and if it is never incorporated the founders remain personally on the hook. A registration sitting in 73 for a long time is a signal worth surfacing in an onboarding review queue.

Code 81. A catch all. If your code has a switch on legal form, give it a default branch, because 81 exists precisely for the forms that do not fit.

Branching on it in practice

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

A shape that holds up well: map the code to three internal buckets rather than switching on fourteen values. Incorporated with limited liability (41, 42, 51, 52, 53, 54, 91), unincorporated with personal liability (01, 21, 22, 71), and needs review (73, 74, 81). Your invoicing, credit and KYC rules almost always differ per bucket rather than per code, and a new or rare code lands in “needs review” instead of falling through a switch statement into a wrong default.

Store the raw code as well as the bucket. When a rule turns out to need finer detail, you do not want to re-enrich your whole customer table to get it back.