Searching Belgian companies in natural language: the complete /recherche guide

Why natural-language search?

The BCE/KBO holds 1.9 million active companies, indexed by 700+ NACE codes and around 2,800 municipalities. Asking a user to memorize 6920 for accountants or 5610 for restaurants is unrealistic. A modern search bar must accept what people actually type: "lawyers Brussels", "carpentry 7000", "bakeries Ghent".

That is exactly what Company Belgium's /recherche page does. Under the hood, three layers cooperate to understand the query, never imposing technical vocabulary on the end user.

The three layers of understanding

1. The static dictionary (free, instant)

200+ FR/NL/EN aliases are mapped to their NACE code. "accountant", "fiduciaire", "boekhouder", "comptable" all point to 692001. Same for cities: "Brussels", "Bruxelles", "Brussel" are normalized to the same municipality, and a lone postcode (1000, 2000, 9000) triggers an area search.

No network call, no latency: the mapping sits in memory and resolves in a few milliseconds.

2. The contextual AI engine (safety net)

When the dictionary recognizes nothing — original phrasings, typos, mixed languages, implicit intent — the query is passed to an AI engine that extracts:

• a possible NACE code

• a municipality or postcode

• a name when the user is looking for a specific company

The result is cached: the same phrasing never pays the AI twice. A confidence threshold (≥ 30%) avoids risky interpretations.

3. The name fallback

If nothing comes out of the two previous layers, the entire query is treated as a name search: PostgreSQL trigram search, tolerant to accents, spaces and casing variants. Type "Espero" and you will find "Espero-Soft Informatiques SRL" without specifying it's a name.

Concrete use cases

The results page: more than a list

Once the query is interpreted, /recherche doesn't just render a flat table. It composes a contextual page:

• SEO-friendly breadcrumbs — sector → city → results, every link is indexable.

• Interpretation banner — when the AI intervened, the page shows "*your query 'X' was understood as Y*", reassuring users and allowing correction.

• Active filter chips — each filter is a removable chip: drop the city with one click without retyping the query.

• Aggregated statistics — distribution by legal form, top municipalities, age profile of the portfolio. Ideal to evaluate a market before prospecting.

• Deep pagination — every page is indexable, with a canonical URL.

• Follow button — for authenticated users, each company can be added to a BCE watchlist that triggers alerts on changes (see BCE monitoring: arrival and departure alerts).

URLs: shortcuts and bookmarkable

Any combination of filters is expressible in the URL — handy to share a precise view via email or Slack:

1
2
3
4

/en/recherche?naceCode=6920&city=Brussels
/en/recherche?naceCode=5610&zipCode=2000
/en/recherche?name=Espero
/en/recherche?q=lawyers+brussels

The q parameter is "raw natural language" and triggers the three interpretation layers. Typed parameters (naceCode, city, zipCode, name) take priority and bypass the AI.

Three tips to make /recherche part of your routine

Accepted limits

• Natural-language search is intentionally conservative: when the AI is unsure, it lets the query fall back to the name layer rather than guess.

• Four-digit postcodes are never confused with a BCE number (8+3 digits) — the routing distinguishes both.

• Very generic queries ("company", "business") do not return the whole register: the page requires at least one filter to activate the search engine.

Wrap-up