A French SAS and a Spanish S.L. are both limited companies, but nothing in their registers says so in the same words. A French activity code ends with a letter; the Spanish register publishes no activity code at all. If your product works across both countries, you need one way to compare them, without throwing away what each register actually said. This page explains how Fuentio normalises legal forms, activity codes and statuses, and the one rule behind all of it: the original always travels with the normalised value.
Method as of 10 October 2026; examples are real recorded answers.
Short answer: Fuentio keeps every value as the register published it (original_code, original_label) and adds standard codes next to it: an ISO 20275 ELF code and a closed category for the legal form; NACE Rev.2 and ISIC Rev.4 codes plus an English label for the activity; and one closed status list that never assumes a company is active. Mappings are only filled when they're unambiguous; otherwise the field stays empty.
What you'll learn
- The "original plus normalised" pattern, and why it matters for compliance
- How legal forms map to ISO 20275 ELF codes and categories
- How French NAF codes map to NACE and ISIC
- The single status list, and the rules behind it
- What we leave empty rather than guess
Why keep the original?
Normalisation is an interpretation. Interpretations can be wrong, and rules change. If a system keeps only its own mapped value, nobody can check it later. So every normalised field in a Fuentio record carries the source's own code and label:
"legal_form": {
"original_code": "5510",
"original_label": "SA nationale à conseil d'administration",
"elf_code": "1NF1",
"category": "public_limited_company"
}Your compliance team can quote the register's exact words; your product can filter on the category. Both come from the same answer.
How are legal forms mapped?
The standard. ISO 20275 defines Entity Legal Forms (ELF): one code per legal form per jurisdiction, from an official code list. We use the list's French and Spanish codes.
France. The source gives INSEE's four-digit legal category. We matched each INSEE category to the French ELF names by its normalised label: 257 of 260 categories matched exactly; two more matched by their official abbreviation (SAS and SLP); one, "Assujetti unique à la TVA", has no ELF code and gets none.
Spain. The BORME prints the legal form as a mandatory suffix of the company name (S.L., S.A., S.L.U., S.L.L.…). We read the suffix and map it to its ELF code: S.L. gives DP3Q.
Categories. On top of the ELF code, a closed category (for example public_limited_company, private_limited_company, cooperative) lets you treat an SAS and an S.L. the same way in your rules when that's what you want. See French legal forms and Spain's S.L. and S.A..
How are activity codes mapped?
France publishes the NAF code, which is the European NACE Rev.2 class plus a letter. So 64.20Z becomes NACE 64.20 by dropping the letter, and NACE maps to the UN's ISIC Rev.4 class (6420), which is one-to-one for every class today. We add an English label from Eurostat's list:
"activity": {
"original_scheme": "NAF_REV2",
"original_code": "64.20Z",
"original_label": "Activités des sociétés holding",
"nace_rev2": "64.20",
"isic_rev4": "6420",
"label_en": "Activities of holding companies"
}Codes outside the current NAF list, for example old codes on long-closed companies, keep their original code and get no NACE or ISIC rather than a guess. France is moving to NAF 2025 for APE codes from 2027; see the APE/NAF code explained.
Spain: the BORME publishes no activity code, only the corporate purpose as free text. So activity is empty for Spanish records, and the purpose is kept as published. We don't derive a code from free text.
How are statuses normalised?
Every record has a status with a value from one closed list, the source's own label, and a date:
| Value | FR (Sirene) | ES (BORME acts) |
|---|---|---|
active | State A | Never: no act proves current activity |
inactive | State C (ceased), dated | Provisional closure of the registry sheet |
in_liquidation | Never inferred | Disolución |
dissolved | Never (ceased isn't a legal dissolution) | Extinción |
unknown | — | Anything else, including a recent incorporation |
Two rules matter for risk decisions:
unknownis never treated asactive. For Spain, most companies areunknownbecause the source publishes events, not states.- We never infer a stronger status than the source states. A company that Sirene marks as ceased is never reported as dissolved, liquidated or struck off.
See how we read French data and how we read the BORME.
What do we leave empty?
- A legal form with no ELF code:
elf_code: null. - An activity code outside the official list: no NACE, no ISIC.
- A Spanish activity: always empty.
- A Spanish postal code the BORME didn't print:
null. - A French dissolution date:
null, because the source doesn't state one.
An empty field is information: it tells you the source didn't say. A filled-in guess would hide that.
How to use normalised fields in your rules
A few patterns we see in onboarding and risk rules:
- Filter on
legal_form.category, not on labels: "private limited companies" in one rule covers SAS, SARL, S.L. and S.L.U. - Route on
status.value, but quotestatus.original_labelin your file: the rule stays simple, the evidence stays exact. - Group activities on
activity.nace_rev2for France, and treat a missing activity as "unknown", not as "low risk". - Treat
unknownas its own case. Never let a default turn it intoactive.
And when you show data to a person, show the original wording first: a compliance analyst reading "SA nationale à conseil d'administration" knows exactly what they're looking at.
Why this helps cross-border teams
- Filters work across countries: "private limited companies, holding activities" is one query, not two vocabularies.
- Labels are readable by teams who don't read French or Spanish.
- Audits stay possible, because the original wording is right next to every mapped value.
Fuentio's API isn't open yet. Become an early tester to see normalised records on the companies you work with.
See what we cover in France and Spain.
Limits. Method and figures as of 10 October 2026. Code lists come from INSEE (legal categories, NAF), Eurostat (NACE Rev.2), the UN Statistics Division (ISIC Rev.4) and the ISO 20275 ELF code list. A mapping is a convenience for comparison; the register's own code is the reference.
Frequently asked questions
What is an ELF code?
The ISO 20275 Entity Legal Form code: one code per legal form in each jurisdiction, from an official list. Fuentio adds it next to the register's own legal form.
How do you convert a French NAF code to NACE?
Drop the final letter: 64.20Z is NACE 64.20. Fuentio also adds the ISIC Rev.4 class and an English label.
Why don't Spanish records have an activity code?
The BORME publishes no activity code, only the corporate purpose as text, and we don't derive codes from text.
Do you ever change the register's data?
No. The original code and label are always kept; normalised values are added next to them.
Sources
- INSEE, legal categories: insee.fr
- INSEE, NAF rév. 2: insee.fr
- Eurostat, NACE Rev.2 code list: ec.europa.eu
- BOE, BORME daily gazette: boe.es