How Can Latvia's Enterprise Register Data Identify Dissolved or Reorganised Entities?

Short answer

The Enterprise Register catalogue reveals a registration-number workflow, not a reliable name-only lookup. The core register resource contains an entity's registration number, current name, registration date, removal or reorganisation date, and a closed field. A separate reorganisations resource connects the registration number of an involved or predecessor entity to the registration number of the resulting entity. Historical-name data explain name changes, while a separate dataset covers current liquidation processes.

These sources must not be collapsed into one “inactive” flag. A name change does not create a successor. A liquidation process may be ongoing rather than completed. Removal from the register may follow reorganisation, in which case the business activity or rights may continue through another registered entity. The durable evidence chain is registration number, relevant lifecycle date, reorganisation mapping and current resource timestamp.

Legalcode currently indexes only the 30 catalogue descriptions, not the underlying entity rows. Researchers must download or query the linked official resources. A failed company-name or registration-number search in the MCP is therefore not evidence that the entity does not exist.

Four resources answer different questions

Start with the core registration number

The core Enterprise Register dataset is described as daily updated and covering all subjects registered in the Enterprise Register. Its resource fields include regcode, current name, entity form and type, registration date, terminated, closed and address information.

The catalogue describes the relevant lifecycle date as:

datums, kad tiesību subjekts izslēgts no reģistra (vai reorganizācijas datums, ja tiesību subjekta izslēgšanas iemesls ir reorganizācija)

— Enterprise Register open data — core register

In English, that is the date when the legal entity was removed from the register—or the reorganisation date when reorganisation was the reason for removal. That wording prevents a crucial mistake: a populated termination date does not, by itself, establish that the undertaking simply ceased without a successor.

The catalogue lists closed as a text field but does not provide a complete value codebook in the fetched description. A risk system should preserve the raw value and validate its official semantics before converting it into an internal boolean such as “dissolved.”

Follow the reorganisation mapping

The legal-entity reorganisations dataset is the bridge between a removed predecessor and a resulting entity. Its source description is concise:

Tiesību subjektu reģistrētās reorganizācijas.

— Enterprise Register open data — reorganisations

The useful detail lies in the schema. It contains a reorganisation identifier and type, a Latvian description of that type, source_entity_regcode, final_entity_regcode and the registration date. The source-reported CSV contained 10,784 rows when modified on 4 July 2026.

For identification, search the questioned entity's registration number in the source-entity field. Then follow the final-entity registration number back to the core register. That two-step join can distinguish a company that vanished without a mapped successor from one whose legal history continues through a merger, division or other registered reorganisation.

The direction and meaning of a particular reorganisation type must come from reorganization_type_text and applicable law. The schema supports tracing; it does not justify assuming that every asset, liability, contract or credit history transferred in the same way.

Separate liquidation from completed removal

The liquidation-process dataset covers current processes:

Ziņas par aktuālajiem tiesību subjektu likvidācijas procesiem.

— Enterprise Register open data — liquidation processes

Its fields include the legal entity's registration number, liquidation type and description, start date, grounds, registration date and last-modified timestamp. The source-reported CSV contained 9,757 rows on 4 July 2026.

“Current liquidation process” is not synonymous with “dissolved.” A process may have begun while the entity remains in the register. A defensible report should state the process and its date, then separately check the core row for removal. It should not transform one liquidation record into a claim that the entity no longer exists.

The reverse is also important. An entity removed because of reorganisation may not appear as a current liquidation. Absence from the liquidation dataset does not negate the core termination date or reorganisation chain.

Use historical names to avoid false mismatches

The historical-names dataset pairs regcode with the former name and date_to, the date until which that name applied. Its current CSV resource reported 90,974 rows, while an older XLSX resource reported 80,907. Those unequal counts demonstrate why the file format and modification date must accompany any result.

A former and current name joined to the same regcode usually describe one registered identity across a name change. By contrast, a reorganisation row may lead from one registration number to another. Name similarity alone cannot distinguish those situations. Registration numbers also protect against punctuation differences, transliteration, abbreviations and reused or similar trading names.

A defensible entity-history check

For a dissolved-or-reorganised entity assessment:

1. Record the exact registration number and current core-register row.
2. Preserve registered, terminated, closed, entity type and the resource modification time.
3. If removal may reflect reorganisation, search that number as source_entity_regcode.
4. Follow each final_entity_regcode and retrieve its core row.
5. Check historical names using regcode; keep name changes separate from successor mappings.
6. Check current liquidation data independently, with its type, grounds, start date and last modification.
7. Retain the raw source fields and explain any normalization used in a report.

This sequence supports an auditable statement such as: “Entity A was removed on date X in connection with a registered reorganisation mapping to Entity B.” It does not automatically support a legal conclusion about universal succession or a particular debt without the relevant reorganisation type and governing legal documents.

What the MCP can and cannot establish

Production Discovery reports 30 LV_ENTERPRISE_REGISTER guidance/reference records. Fetch returns official package links, schemas, reported counts, licence and update frequency. It does not return the hundreds of thousands of company rows as Legalcode records.

As a control test, an exact source-scoped search for registration number 40003135842 returned no result even though the number appears in a separately indexed Competition Council decision. That result says only that the registration number is absent from the 30 catalogue descriptions. It must not be converted into “not found in the Enterprise Register.”

The MCP's ACTIVE label likewise describes an indexed catalogue document, not the legal entity. The entity's status must be taken from the underlying resource and its documented fields.

MCP source-quality finding

The metadata-only scope, document/entity status ambiguity and missing entity-level search and joins are already tracked in GitHub issue #310. No duplicate issue was filed.

This review also reproduced the source-profile language-count leak tracked in GitHub issue #561: the source profile correctly reports 30 Enterprise Register documents but displays language totals of 3,924 English and 512 Latvian documents, which cannot be source-scoped. That defect affects Discovery metadata, not the underlying official schemas used above.

Conclusion

Latvia's Enterprise Register catalogue supports careful identification through stable registration numbers and distinct lifecycle datasets. The core resource identifies removal and possible reorganisation timing; the reorganisation resource maps predecessor/involved entities to resulting entities; historical names prevent name-change confusion; and liquidation data identify current processes without proving completed dissolution. Because Legalcode currently indexes catalogue metadata rather than entity rows, the actual determination must be made from the linked official resources with dates, raw fields and join direction preserved.

Sources

• Enterprise Register open data — core register
• Enterprise Register open data — reorganisations
• Enterprise Register open data — liquidation processes
• Enterprise Register open data — historical names