Data Standardization

Every country has its own way of describing companies. A “limited liability company” is a “GmbH” in Germany, an “SARL” in France, and an “S.r.l.” in Italy. Standard activity codes vary, from NACE (EU) to SIC (UK) to ISIC (Global). Topograph standardizes this kind of datapoints so you can build one integration that works everywhere. This standardization is crucial because it enables you to:

Build consistent logic across countries without country-specific conditionals
Compare companies from different jurisdictions using the same classification systems
Integrate with downstream systems that expect standardized formats
Reduce complexity in your codebase by handling variations at the API level

Prefill mode varies by country: with POST /v2/company and mode: "prefill", the depth of standardization depends on the country. Some countries return the same standardized legal forms, roles and statuses as verification mode. Others return only the register’s local values for some of these fields, for example a legal form without its ISO 20275 code or a role without its ISO 5009 code. Activity codes are usually standardized in both modes. Use default verification mode (omit mode or use mode: "verification") when you need fully standardized data.

1. Legal Forms

Understanding a company’s legal structure is fundamental to risk assessment, compliance, and business relationships. Different legal forms carry different liability implications, regulatory requirements, and governance structures. However, each country uses its own terminology and classification system, making cross-border comparisons difficult. We map thousands of local legal forms to both a standardized English translation and an ISO 20275 code. The ISO 20275 standard (Entity Legal Forms) provides a globally recognized classification system maintained by GLEIF (Global Legal Entity Identifier Foundation). This enables precise identification and comparison of legal entity types across jurisdictions. How we do it: We use AI-powered translation and semantic matching against the official ISO 20275 code list. We are on version 1.6, published 19 February 2026, which contains 3,599 entity legal forms across 200 jurisdictions in 130 countries. When available, we also perform vector similarity search against the GLEIF-maintained database to find the most accurate ISO code match. Example: Germany

Local: “Gesellschaft mit beschränkter Haftung”
ISO 20275: 2HBR
Standardized: Limited Liability Company

The ISO 20275 standard is maintained by GLEIF and provides a comprehensive, internationally recognized classification system. Learn more about ISO 20275 Entity Legal Forms Code List.

2. Roles

Identifying who has legal authority to represent a company is critical for due diligence, contract execution, and compliance checks. However, role titles vary dramatically across languages and legal systems. What’s called a “Manager” in one country might be a “Gérant” in France or a “Geschäftsführer” in Germany, each with subtly different legal powers. We map these diverse role titles to a standardized English classification and, for legal representatives, assign an ISO 5009 code. ISO 5009 (Official Organizational Roles) provides a standardized way to identify organizational roles within legal entities, enabling consistent role-based analysis across jurisdictions. How we do it: We use AI to translate role titles to English and classify them into standardized categories. For legal representatives, we perform semantic matching against the ISO 5009 code list, which is contextually aware of both the role title and the company’s legal form (ISO 20275 code), ensuring accurate role classification. We are on ISO 5009 version 1.0.0, published June 2023 — the only edition GLEIF has released. An ISO 5009 code identifies a role within a specific legal form, so the same job title carries a different code depending on the company it is held in. The examples below are each scoped to that country’s private limited company:

Local Title	Country	Legal form (ISO 20275)	Standardized Role	ISO 5009 Code
Gérant	France	SARL (`V9QP`)	Manager	`4BIJAS`
Geschäftsführer	Germany	GmbH (`2HBR`)	Managing Director	`O3E52H`
Amministratore Unico	Italy	S.r.l. (`OV32`)	Sole Director	`IGKI9C`

Because coverage is scoped this way, a legal form GLEIF has no role rows for returns a role with no iso5009Code. That is an honest gap rather than a near-miss from a neighbouring legal form.

ISO 5009 codes provide standardized role identification within legal entities. The standard is maintained by GLEIF and enables consistent role-based analysis. Learn more about ISO 5009 Official Organizational Roles Code List.

3. Activity Codes (Activity Mapping)

Economic activity classification is essential for industry analysis, market research, regulatory compliance, and risk assessment. However, countries use different classification systems: Italy uses ATECO, the UK uses SIC, Germany uses WZ codes, and France uses NAF/APE codes. Even within the EU, while NACE is the standard, local implementations vary. We map these diverse local activity codes to international standards: ISIC Rev.5 (the global standard) and NACE Rev.2.1 (the European standard). This enables you to compare companies across borders, perform industry-level analysis, and integrate with systems that expect standardized activity codes.

Mapping Process

Topograph uses AI to standardize the activity sector of companies through a two-step process, prioritizing precision over recall.

Step 1: Local Classifications → ISIC Rev.5

We use AI to map local activity codes to ISIC Rev.5. Priority order:

Local Classification Codes (Primary source)
- Country-specific codes (e.g., ATECO for Italy)
- Sector-specific codes (e.g., SIC, RAE, SAE)
- Official business register classifications
Activity Descriptions (Fallback source)
- Free-text activity descriptions when no local codes are available

Process: AI analyzes the activity code and description together to find the most semantically similar ISIC code. We favour accurate matches over complete coverage.

Step 2: ISIC Rev.5 → NACE Rev.2.1

Formal mapping from ISIC to NACE. NACE Rev.2.1 is the European implementation of ISIC Rev.5, so the two share the same structure and the correspondence is deterministic.

100% coverage of ISIC Rev.5 classes
Deterministic correspondence, derived from the official UNSD and Eurostat structures
Register-native NACE codes are upconverted to NACE Rev.2.1 from the official Eurostat transition table

Both standards, always together

When an activity can be placed in the current standardized classifications, the response carries ISIC and NACE, using the official ISIC Rev. 5 to NACE Rev. 2.1 correspondence where available. The register’s own code is retained under its national key. An unknown revision or an unsupported correspondence can leave only the native code; no standardized class is invented. These are absent only when the source register exposes no activity data at all for the company, or when none of the codes it holds can be placed honestly in the standards:

a NACE Rev. 2 class whose Rev. 2.1 successors scatter across unrelated divisions, with no activity description to choose between them (see When you need the register’s own NACE class);
in Croatia, a code stamped NKD 1994, which predates Croatia’s NACE alignment and so cannot be crosswalked from;
in Latvia, a pre-2008 NACE Rev. 1 or Rev. 1.1 code that cannot be placed in Rev. 2.

In each case the register’s own code is still published under its own key. See Where two revisions run side by side.

Which version of each classification?

Two revisions are fixed platform-wide, for every country and every source:

Key	Standard	Revision
`ISIC`	UN ISIC	Rev. 5
`NACE`	Eurostat NACE	Rev. 2.1

These never vary by country. A register that publishes NACE Rev. 2 is upconverted to Rev. 2.1 using the official Eurostat transition correspondence before we publish it, so activities.NACE is Rev. 2.1 even where the source is not. Every other key is the register’s own national code, published exactly as the register records it. We do not restate, renumber, or re-version those.

Revision-explicit keys

Each classification and revision has one canonical response key. ISIC means Rev. 5 and NACE means Rev. 2.1. National keys name their revision when the source establishes it, such as SIC_2007 for UK SIC.

"activities": {
  "NACE": [{ "code": "62.10", "description": "Computer programming activities" }],
  "ISIC": [{ "code": "621", "description": "Computer programming activities" }]
}

Source aliases are merged into the canonical key, keeping distinct codes and deduplicating repeated codes. For editions resolved per record, bare keys contain only unresolved records; they do not repeat the revision-key arrays.

Earlier responses could return several spellings for the same classification. Current responses return only the canonical key. Update consumers of earlier spellings using the table below. See alternate spellings.

Earlier or source key	Current response key	Country	Classification and revision
`ISIC_REV5`	`ISIC`	all	International Standard Industrial Classification, Rev. 5
`NACE_REV21`	`NACE`	all	NACE, Rev. 2.1
`ISAT`	`ISAT_2008`	Iceland	ÍSAT 2008, including the register’s national subclass digit
`KD`	`KD_BIH_2010`	Bosnia and Herzegovina	KD BiH 2010, the register’s NACE Rev. 2 harmonisation
`NACE_BEL`	`NACE_BEL_2003` / `NACE_BEL_2008` / `NACE_BEL_2025`	Belgium	NACE-BEL, per the version the register stamped
`WZ2008`	`WZ_2008`	Germany	Klassifikation der Wirtschaftszweige 2008
`WZ2025`	`WZ_2025`	Germany	Klassifikation der Wirtschaftszweige 2025
`DBR`	`DB25`	Denmark	Dansk Branchekode 2025
`CNAE`	`CNAE_2009`	Spain	CNAE-2009
`EMTAK`	`EMTAK_2008` / `EMTAK_2025`	Estonia	EMTAK, per the edition stamped on each assignment
`TOL`	`TOL_1995` / `TOL_2002` / `TOL_2008` / `TOL_2025`	Finland	Toimialaluokitus, per the edition the register stamped on the company’s code
`NAFREV2` / `NAFRev2`	`NAF_REV2`	France	NAF rév. 2 (code APE)
—	`NACE_REV2`	France, Latvia, Malta, Ireland, Estonia	NACE Rev. 2 — the register’s own class, see When you need the register’s own NACE class
—	`NACE_REV1` / `NACE_REV11`	Latvia	NACE Rev. 1 / Rev. 1.1 — the register’s own pre-2008 class, per the revision it stamped
—	`NAF_2025`	France	NAF 2025 (INSEE’s implementation of NACE Rev. 2.1), the code INSEE has assigned the company — provisional until 2027-01-01, see France
`SIC`	`SIC_2007`	United Kingdom	UK SIC 2007
`KAD`	`KAD_2025`	Greece	ΚΑΔ 2025
`NKD`	`NKD_1994` / `NKD_2007` / `NKD_2025`	Croatia	NKD, per the revision the entry was filed under
`TEÁOR`	`TEAOR_2008` / `TEAOR_2025`	Hungary	TEÁOR, per the nomenclature the extract stamps on each entry
`ATECO`	`ATECO_2007`	Italy	ATECO 2007 (aggiornamento 2022)
`ATECO2025`	`ATECO_2025`	Italy	ATECO 2025
`CAEN`	`CAEN_REV2` / `CAEN_REV3`	Romania	CAEN, per the revision stamped on each assignment
`CAEM-1.1`	`CAEM_REV11`	Moldova	CAEM Rev. 1.1
`CAEM-2`	`CAEM_REV2`	Moldova	CAEM Rev. 2
`SBI_2025`	`SBI`	Netherlands	No guaranteed edition; current active registrations use 2025, but historical and deregistered records can retain 2008
`CAE`	`CAE_REV3`	Portugal	CAE Rev. 3
`OKVED`	`OKVED_REV2`	Russia	OKVED Rev. 2 (ОК 029-2014)
—	`SNI_2025`	Sweden	SNI 2025 (Statistics Sweden’s implementation of NACE Rev. 2.1)
`KVED`	`KVED_2010`	Ukraine	KVED-2010

SBI does not guarantee an edition. Check historical and deregistered records against the register before assigning a year.

These are the revisions the registers serve, which is not always the revision the national statistics office has most recently adopted. The two routinely disagree, in both directions: a register can serve an older revision for years after a new one is published, and sometimes the register moves first. The Dutch Handelsregister converted every active registration to SBI 2025 in September 2025 while CBS is still phasing SBI 2025 into its own statistics through 2029.

Where two revisions run side by side

Belgium, Estonia, Croatia, Hungary, Romania and Latvia stamp each activity record with the revision it was filed under, so a single company can carry codes from more than one. Rather than average that into one answer, you get a key per revision:

Belgium. The register’s activity file marks every row 2003, 2008 or 2025, so the codes arrive under NACE_BEL_2003, NACE_BEL_2008 or NACE_BEL_2025 accordingly.
Estonia. RIK stamps each assignment with its EMTAK edition. EMTAK 2025 feeds standardized NACE directly; explicitly labelled EMTAK 2008 also preserves the declared class under NACE_REV2 before transition. Unknown or conflicting editions retain native EMTAK and NACE_EE, without a guessed standardized class.
Romania. ONRC assignments stamped Rev. 2 or Rev. 3 retain their national codes under CAEN_REV2 or CAEN_REV3. Only recognized revisions feed the corresponding formal NACE transition.
Croatia. The court register stamps each business-scope entry, giving NKD_1994, NKD_2007 or NKD_2025. A company filed across revisions returns one key for each. NKD 2007 and NKD 2025 are Croatia’s NACE Rev. 2 and Rev. 2.1 transpositions, so both also feed NACE; codes stamped NKD 1994 predate that alignment and are excluded, since reading one as Rev. 2 would produce a class the register never declared.
Hungary. The company extract stamps every activity '08 (TEÁOR’08, the NACE Rev. 2 implementation) or '25 (TEÁOR’25, the Rev. 2.1 one), so the codes arrive under TEAOR_2008 or TEAOR_2025. Only the '08 entries are transitioned on their way into NACE.
Latvia. The Enterprise Register stamps every NACE code 1, 1.1 or 2. Rev. 2 codes arrive under NACE_REV2 and are transitioned into NACE. Pre-2008 codes arrive under NACE_REV1 or NACE_REV11 exactly as declared; where a model can place one in Rev. 2 it also reaches NACE, marked isAIInferred: true, and where it cannot, the register’s own code is still there rather than dropped.
Malta. The Business Registry records one area of activity per entity, from its own NACE Rev. 2 list. It arrives under NACE_REV2 as declared and is transitioned into NACE.

Where we do not state a revision

The following keys have no revision-explicit sibling. The response does not identify their edition, so do not assign a revision from the key alone:

Key	Country	Why
`CAE_QC`	Canada, Quebec	The register’s own economic activity codes, without an edition marker on the enterprise record. These are distinct from Portuguese CAE.
`NAICS`	US states	Each state records the NAICS vintage current when the entity registered and does not publish which one. The code is passed through exactly as the state holds it.
`NACE_SK`	Slovakia	Retains the register’s activity assignment when its code-list marker does not establish a recognized NACE edition.
`SSIC`	Singapore	The retrieved ACRA company dataset does not identify the edition on each record; native assignments are retained without asserting a revision.
`PKD`	Poland	The registers publish PKD codes without stating the revision, and PKD 2007 and PKD 2025 overlap in code shape.
`CAEN`	Romania	CAEN preserves older or unstamped assignments; recognized Rev. 2 and Rev. 3 stamps publish only `CAEN_REV2` or `CAEN_REV3`.
`NACE_EE`	Estonia	The original source NACE string, retained across editions, including unknown or unstamped legacy records.
`TW_BUSINESS_ITEM`	Taiwan	The business items an entity registered, as codes of the Ministry of Economic Affairs business item code table. The table is a licensing list revised over time without an edition on the record, and older registrations carry free-text items with no code.
`NKID`	Bulgaria	Recording an NKID code is optional and it is never retroactively migrated, so a filed code may be КИД-2003, КИД-2008 or КИД-2025 depending only on when the company last amended it.
`NAF`	any	Emitted by our AI profile parser rather than read from a French register, so the key does not fix a revision. France’s own register code is `NAF_REV2`.
`RNA`	France	The associations register’s nomenclature des objets sociaux describes association purposes. We publish no revision identifier; label it as RNA without a year.

Country-specific revision keys are published on the pricing page and in /v2/catalog under activityCodes.responseKeys. That field lists declared canonical classification keys, rather than every possible response key, such as unstamped and association-purpose classifications. See the activity-code page for spelling compatibility.

If you need one revision you can rely on across every country without tracking national transitions, read ISIC or NACE. The national keys are there for round-tripping back to the register, not for cross-border comparison.

One code in, one code out

We never publish an activity the register did not declare. You get one standardized class per declared code — never a list of candidates we could not choose between. This matters because classification systems do not line up one-to-one. When a company’s declared class maps to several classes in the target standard, the true one is unknowable from the code alone. Rather than return all of them, we return the most precise class the correspondence actually supports:

The declared code maps to	What you get
Exactly one class in the target standard	That class
Several classes in the same group	Their shared group (for example `64.2` rather than guessing `64.21` or `64.22`)
Several classes across different groups or divisions	Their shared division (for example `47`)
Classes scattered across unrelated divisions	No standardized code — the register’s own local code only

A shorter code is not missing data: 64.2 means the register told us the company is a holding company but not which kind. It is the most specific statement the source supports. The register’s own code is always published in full alongside it.

The one exception is when the register also publishes a free-text activity description. That is independent evidence about the actual trade, so we use it to pick the precise class — and mark the result isAIInferred: true so you can tell it apart from a formal mapping.

When you need the register’s own NACE class

Upconverting to Rev. 2.1 is the right default, but it has a hard limit: Rev. 2.1 deleted some Rev. 2 classes. 86.90 has no Rev. 2.1 class of its own, so the most precise standardized answer is the group 86.9; for 17 further classes the successors scatter across unrelated divisions and there is no honest Rev. 2.1 code at all, so activities.NACE is absent. Where the register itself publishes NACE Rev. 2, we also publish that class verbatim under NACE_REV2. Today that includes France, Latvia, Malta, Ireland and Estonia’s explicitly labelled EMTAK 2008 assignments. In France, NAF rév. 2 is the French implementation of NACE Rev. 2 — an APE code’s first four digits are the Rev. 2 class, the trailing letter a French subdivision below it — so the key is present on every French company whose APE code we hold:

"activities": {
  "NAF_REV2":    [{ "code": "8690F", "description": "Activités de santé humaine non classées ailleurs" }],
  "NACE_REV2":  [{ "code": "86.90", "description": "Other human health activities" }],
  "NACE":       [{ "code": "86.9",  "description": "Other human health activities" }]
}

Read NACE_REV2 when you need a 4-digit class for every company and can accept the older revision; read NACE when you need one revision you can compare across countries. They are different revisions of the same classification, so never mix them in one field: 86.90 is not a NACE Rev. 2.1 code and 86.9 is not a Rev. 2 class.

The register’s own answer beats any table

Where the register itself publishes the company’s class in the target revision, we read that and convert nothing. France is the worked case: INSEE assigns every active company its NAF 2025 code — the French implementation of NACE Rev. 2.1, i.e. a Rev. 2.1 class with one French letter appended — and publishes it in Sirene ahead of the 2027 cutover. A code-level correspondence can only say where a code went; INSEE says where the company went, and the two differ whenever INSEE recoded the company on its actual activity (a consultancy filed as 62.02A that INSEE recoded to 73.12Y, media representation). So for France, NACE is the first four digits of the NAF 2025 code, the code itself is published under NAF_2025, and the rules below only apply to the small population INSEE has not assigned one (units still coded in pre-2008 nomenclatures, almost all ceased).

National sub-classes are used as evidence

Some registers publish a code that is finer than the standard class it sits in. France’s APE/NAF code is the clearest case: 8690F is the NACE Rev. 2 class 86.90 plus a French sub-class letter, and the letter says something the class does not. Where the national statistics office publishes an official correspondence for those sub-classes, we resolve through it rather than through the class. So 6420Z returns NACE 64.21 (INSEE maps that sub-class to a single Rev. 2.1 class) instead of the group 64.2 the bare class 64.20 would give. The sub-class is only preferred when it names exactly one class; when it straddles several, the class-level answer stands. Both codes are always published, so you can see the reasoning: activities.NAF_REV2 holds the register’s own code and activities.NACE the standardized class.

If you previously filtered or de-duplicated activities.NACE and activities.ISIC yourself to work around long lists, that logic is no longer needed. Counts are now proportional to what the register declared: a company with three declared activities returns three NACE and three ISIC codes, not several dozen.

The main activity

Many registers designate one activity as the company’s main (primary, prevailing) activity — Belgium’s MAIN classification, Poland’s działalność przeważająca, Croatia’s pretežita djelatnost, Hungary’s főtevékenység, and others — and some registers publish only the main activity in the first place (France’s APE code, Finland’s main business line). Where the register makes that distinction, the corresponding activity item carries isMainActivity: true, and every code derived from it (NACE, ISIC, local crosswalks) inherits the flag. At most one code per classification carries it, so activities.NACE.find(a => a.isMainActivity) is a safe way to pick one code per company. Where activity codes are AI-inferred from a free-text activity description, the single best-match code is flagged as the main activity and is marked isAIInferred: true alongside, so a register-declared main activity is always distinguishable from an inferred one.

Absence of isMainActivity means the register does not say — not that the code is secondary. Do not rely on array order to identify the main activity; the flag is the only guaranteed signal.

Example: Italy

Italy’s register publishes a company’s ATECO 2025 code together with its NACE class. ATECO 2025 is Italy’s implementation of NACE Rev. 2.1, so the NACE class is published as the register declared it, and ISIC Rev. 5 is derived from it through the official correspondence. No AI step is involved, so the ISIC code is isAIInferred: false, and the main-activity flag carries over to every derived code. Each classification appears under its canonical key.

API Response

{
  "activities": {
    "ATECO_2025": [
      { "code": "01.11", "description": "Growing of cereals", "isMainActivity": true }
    ],
    "NACE": [
      { "code": "01.11", "description": "Growing of cereals", "isMainActivity": true }
    ],
    "ISIC": [
      {
        "code": "0111",
        "description": "Growing of cereals (except rice), leguminous crops and oil seeds",
        "isAIInferred": false,
        "isMainActivity": true
      }
    ]
  }
}

4. Addresses

Addresses are critical for verification, communication, and compliance (especially for KYC/AML requirements), but registries store them as unstructured text strings in various formats. Parsing addresses correctly is challenging because formats vary by country, and components like street numbers, postal codes, and administrative divisions are positioned differently. We parse and structure unstructured address strings into standardized component parts, enabling you to validate addresses, perform geocoding, and integrate with address validation services without writing country-specific parsing logic. How we do it: We use pattern recognition and country-specific parsing rules to extract address components, then normalize them according to international standards. Country codes follow ISO 3166-1 alpha-2 format for consistency.

Street
House Number
Postal Code
City
Country (ISO 3166-1 alpha-2)

5. Status

Company status information is crucial for risk assessment. You need to know if a company is active, dissolved, in liquidation, or bankrupt before entering into business relationships. However, registries use different terminology and status codes, and some countries have complex status hierarchies that don’t map cleanly to simple active/inactive states. We normalize company status to a simple active/inactive boolean plus a standardized status enum, a closure reason, and key dates. This makes it easy to filter and reason about company status across jurisdictions without learning each country’s specific status terminology. How we do it: We map local status codes and descriptions to a three-layer model (boolean active, raw localName, and standardized statusDetails), preserving the original status information while providing a clean cross-country view.

active: true / false (omitted when the register’s status cannot be classified)
statusDetails.status: ACTIVE, UNDER_INSOLVENCY_PROCEEDING, INACTIVE_NOT_CLOSED, PENDING_DISSOLUTION, CLOSED, UNKNOWN
statusDetails.closureReason (when closed or under insolvency): BANKRUPTCY, LIQUIDATION, VOLUNTARY_DISSOLUTION, ADMINISTRATIVE_DISSOLUTION, COURT_ORDER, MERGER, SPLIT, ACQUISITION, OTHER, UNKNOWN

See the Company Status guide for the full model and usage patterns.

Getting Started

AI Agents

Integration Guides

Core Features

Behavior & Operations

Data Standardization

1. Legal Forms

2. Roles

3. Activity Codes (Activity Mapping)

Mapping Process

Step 1: Local Classifications → ISIC Rev.5

Step 2: ISIC Rev.5 → NACE Rev.2.1

Both standards, always together

Which version of each classification?

Revision-explicit keys

Where two revisions run side by side

Where we do not state a revision

One code in, one code out

When you need the register’s own NACE class

The register’s own answer beats any table

National sub-classes are used as evidence

The main activity

Example: Italy

API Response

4. Addresses

5. Status

​1. Legal Forms

​2. Roles

​3. Activity Codes (Activity Mapping)

​Mapping Process

​Step 1: Local Classifications → ISIC Rev.5

​Step 2: ISIC Rev.5 → NACE Rev.2.1

​Both standards, always together

​Which version of each classification?

​Revision-explicit keys

​Where two revisions run side by side

​Where we do not state a revision

​One code in, one code out

​When you need the register’s own NACE class

​The register’s own answer beats any table

​National sub-classes are used as evidence

​The main activity

​Example: Italy

​API Response

​4. Addresses

​5. Status

1. Legal Forms

2. Roles

3. Activity Codes (Activity Mapping)

Mapping Process

Step 1: Local Classifications → ISIC Rev.5

Step 2: ISIC Rev.5 → NACE Rev.2.1

Both standards, always together

Which version of each classification?

Revision-explicit keys

Where two revisions run side by side

Where we do not state a revision

One code in, one code out

When you need the register’s own NACE class

The register’s own answer beats any table

National sub-classes are used as evidence

The main activity

Example: Italy

API Response

4. Addresses

5. Status