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

Important Exception: POST /v2/company with mode: "onboarding" skips some standardization steps (such as legal form ISO codes, role ISO codes, and full status normalization) to maximize speed. However, activity normalization is often included: you may still get ISIC and NACE codes for industry classification. 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

Whenever a company has any activity classification, the response carries both ISIC and NACE. If a register publishes only one of the two (most EU registers publish NACE-based codes; some sources expose only ISIC), we derive the other from the official ISIC Rev.5 to NACE Rev.2.1 correspondence. So you can rely on activities.ISIC and activities.NACE being present together across every country, alongside the register’s own local code (NAF, ATECO, SIC, and so on) under its own key. The only time these are absent is when the source register exposes no activity data at all for the company, or — for Croatia alone — when every code it holds is stamped NKD 1994, which predates Croatia’s NACE alignment and so cannot be crosswalked from. 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` / `ISIC_REV5`	UN ISIC	Rev. 5
`NACE` / `NACE_REV21`	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.

Every key states its revision

A key like SIC or SBI says which classification a code belongs to but not which revision, and the same code can mean different things across revisions. So alongside each of those, we publish a second key that names the revision: <SYSTEM>_<VERSION>.

"activities": {
  "NACE":       [{ "code": "62.10", "description": "Computer programming activities" }],
  "NACE_REV21": [{ "code": "62.10", "description": "Computer programming activities" }],
  "SBI":        [{ "code": "62010", "description": "Ontwikkelen, produceren en uitgeven van software" }],
  "SBI_2025":   [{ "code": "62010", "description": "Ontwikkelen, produceren en uitgeven van software" }]
}

The two hold the same items. Read the versioned key when the revision matters, the original when it does not.

Nothing was renamed or removed. The original keys keep the exact contents they have always had. If you read activities.NACE or activities.SIC today, that keeps working unchanged; the versioned keys are additive.

Original key	Revision-explicit key	Country	Classification and revision
`ISIC`	`ISIC_REV5`	all	International Standard Industrial Classification, Rev. 5
`NACE`	`NACE_REV21`	all	NACE, Rev. 2.1
`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
`TOL`	`TOL_2025`	Finland	Toimialaluokitus 2025
`NAFREV2`	`NAF_REV2`	France	NAF rév. 2 (code APE)
—	`NACE_REV2`	France	NACE Rev. 2 — the register’s own class, see When you need the register’s own NACE class
—	`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_2025`	Hungary	TEÁOR’25
`ATECO`	`ATECO_2007`	Italy	ATECO 2007 (aggiornamento 2022)
`ATECO2025`	`ATECO_2025`	Italy	ATECO 2025
`CAEM-1.1`	`CAEM_REV11`	Moldova	CAEM Rev. 1.1
`CAEM-2`	`CAEM_REV2`	Moldova	CAEM Rev. 2
`SBI`	`SBI_2025`	Netherlands	SBI 2025
`CAE`	`CAE_REV3`	Portugal	CAE Rev. 3
`OKVED`	`OKVED_REV2`	Russia	OKVED Rev. 2 (ОК 029-2014)
`KVED`	`KVED_2010`	Ukraine	KVED-2010

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 and Croatia 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.
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.

Where we do not state a revision

These keys are published with no revision-explicit sibling, because the register does not record which revision the code belongs to. We would rather publish no version than a wrong one:

Key	Country	Why
`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.
`PKD`	Poland	The registers publish PKD codes without stating the revision, and PKD 2007 and PKD 2025 overlap in code shape.
`CAEN`	Romania	The bulk dataset tags rows with a CAEN revision (Rev. 1, 2 and 3 all appear during the transition running to September 2026), but that marker is not currently carried through to the code we publish.
`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`.

Every country’s exact key list is published on its pricing page and in /v2/catalog under activityCodes.responseKeys, so you can check what a country returns before you call it.

If you need one revision you can rely on across every country without tracking national transitions, read ISIC_REV5 or NACE_REV21. 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 is France, whose 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": {
  "NAFREV2":    [{ "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" }],
  "NACE_REV21": [{ "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 / NACE_REV21 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.NAFREV2 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

{
  "input": {
    "classification": "ATECO2025",
    "code": "01.11",
    "description": "Coltivazione di cereali (escluso il riso)"
  },
  "step1_result": {
    "code": "0111",
    "description": "Growing of cereals (except rice)..."
  },
  "step2_result": {
    "code": "01.11",
    "description": "NACE 01.11 - AI mapped from ISIC 0111"
  }
}

API Response

{
  "activities": {
    "ATECO2025": [
      {
        "code": "01.11",
        "description": "Coltivazione di cereali (escluso il riso)",
        "isAIInferred": false
      }
    ],
    "ISIC": [
      {
        "code": "0111",
        "description": "Growing of cereals (except rice)...",
        "isAIInferred": true
      }
    ],
    "NACE": [
      {
        "code": "01.11",
        "description": "NACE 01.11 - AI mapped from ISIC 0111",
        "isAIInferred": 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
statusDetails.status: ACTIVE, UNDER_INSOLVENCY_PROCEEDING, 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, country coverage, and usage patterns.

Getting Started

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?

Every key states its revision

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?

​Every key states its revision

​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?

Every key states its revision

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