Short answer
The indexed e‑äriregister catalogue describes nine daily Business Register download packages plus a separate monthly annual-report series. It also contains six records for public query, catalogue, statistics and visualisation pages; those six are access surfaces, not bulk datasets.
The Estonian registry code (registrikood) is the principal company identifier described by the catalogue. It is expressly present in Basic data, Beneficial owners, Commercial pledge, Persons on registry card, Registry cards, Rulings and Shareholders. General data incorporates the Basic data and also exposes an internal legal-person ID. The annual-report general-information file includes the company registry code and supplies the report_id used to connect the related annual-report CSV files.
The indexed description for Persons not on registry card merely says that it returns such persons and does not list its fields. It does not provide enough evidence to promise that a company registry code is present, even though a relationship to a legal entity would be expected operationally.
The indexed catalogue at a glance
The production collection returned exactly 16 e‑äriregister catalogue records on 13 September 2026:
- nine daily Business Register data packages;
- one monthly annual-report data series; and
- six public surfaces: the open-data landing page, access to legal-person data, name query, single query, statistical queries and data visualisation.
The download records point to official RIK ZIP files. The daily packages are offered principally as XML and JSON, with CSV or Parquet available for some datasets. The annual-report series consists of connected CSV files.
Dataset and company-identifier map
The table distinguishes a company identifier from a person's identifier. Several ownership or officeholder datasets describe a Person ID, but the catalogue also warns that, from 1 November 2024, open-data files no longer contain personal identification numbers for data-protection reasons. A personal identifier must not be assumed to be an Estonian personal identification code merely because the translated field label says “Person ID”.
Basic data: the core matching table
The is the clearest starting point for entity resolution. Its advertised fields are:
- name of the legal person;
- registry code;
- legal form and subtype;
- VAT number;
- current status;
- date of first entry; and
- address.
The registry code provides the stable company key. Names and addresses can change or collide, while VAT numbers may be absent or serve a tax-specific purpose. A data pipeline should therefore preserve the registry code as the primary register identity and treat other fields as attributes, cross-checks or alternative identifiers.
The indexed entry lists daily updates and XML and CSV downloads. It also points to an older Parquet file dated 13 November 2023. File-level dates should be stored separately so that a stale alternative format is not mistaken for the newest daily dataset.
General data: a richer legal-person profile
The says it contains the Basic data plus a much broader company profile:
- internal legal-person ID;
- accounting-obligation information;
- capital and shares without nominal value;
- legal succession;
- lists of annual reports and articles of association;
- first-entry date, contacts and activity areas;
- registry-card list; and
- immovables entered on the registry card for building associations.
Because the description says “in addition to Basic data”, the registry code remains part of the record even though the supplementary field list does not repeat it. The internal legal-person ID is useful within RIK's own data model but should not displace the public registry code in cross-source matching unless its semantics and stability are independently documented.
Ownership and management datasets
Three packages describe relationships between legal entities and people.
Beneficial owners
The gives the legal-entity name and registry code, the beneficial owner's name and residence country, and the method used to verify the beneficial owner's identity. The description says it returns current beneficial owners.
This is entity-linked ownership information, not a historical ownership ledger. The word “current” and the open-data coverage limitation matter when analysing past relationships.
Persons on the registry card
The links the legal-entity name and registry code to a person's role, name, entry and end dates, and textual restrictions or specifications on representation rights.
The company registry code permits a deterministic company join. The person's name alone is not a safe identity key, particularly now that public files omit personal identification numbers.
Persons not on the registry card
The is much less well documented in the indexed catalogue. It says only that the dataset returns a list of persons outside the registry card. No fields are advertised.
The responsible conclusion is therefore “identifier coverage not established by the catalogue description”. A user who needs to join this package should inspect its current XML or JSON schema rather than inferring the presence or meaning of a company or person key from the filename.
Shareholders
The expressly includes the company's registry code and name, the person's role and name, contribution and participation, contribution type, start and end dates, and special representation rights as text.
This record is one reason the catalogue count needs correction: it is a ninth daily Business Register download package, although the repeated catalogue description says that there are eight.
Commercial pledges
The associates current pledge information with a company. Its fields include:
- company name and registry code;
- commercial-pledge number;
- amount, status and entry date;
- pledgee name and code; and
- remarks.
The company registry code identifies the pledgor company. The pledge number identifies the security record, while the pledgee code may identify another legal person. Those keys answer different questions and should be stored separately.
The catalogue describes current commercial-pledge information. Absence from a current file does not prove that no pledge existed historically.
Registry cards and rulings
The links company name and registry code to entry number, entry date and entry type. It can help explain changes in the registered legal-person record.
The links legal-person name and registry code to ruling number, ruling date, additional deadline, ruling type and status, force status, date of entry into force and entry type.
A ruling entry is not the same thing as a court judgment on the company's substantive liability. Its type, status and force fields must be read before drawing conclusions. The registry code connects the event to the company; the ruling number identifies the event itself.
Annual-report data
The indexed annual-report entry describes a separate monthly series rather than one of the daily company-master packages. At the time reviewed, its coverage ended on 30 June 2026 and its files were published on 3 July 2026.
The series contains four connected kinds of CSV data:
- general report-submission information;
- non-consolidated sales revenue by EMTAK activity;
- non-consolidated sales revenue by geographic region; and
- selected non-consolidated financial indicators by report year.
The general-information file includes the company name, registry code, legal type, status, submission date and reporting period, company category, audit information and possible modifications. The files connect through report_id.
This creates two levels of identity:
- company registry code identifies the reporting legal entity in the general-information file; and
report_ididentifies the submitted report and joins its related sales and indicator rows.
The catalogue cautions that these are report metadata and selected indicators. Whole annual reports require the e‑Business Register's services. The indexed collection describes the files; it does not turn every company row or full report into an individually searchable Legalcode document.
Coverage, update and licence limits
The daily catalogue entries state that the files contain public data only for legal entities currently in the Business Register with one of three statuses:
- entered in the register;
- in liquidation; or
- in bankruptcy.
Deleted entities are therefore outside the stated current-file scope. Failure to find a company in a present-day download is not proof that it never existed.
The packages are offered under the , subject to acceptance of the source's licence terms. The open-data downloads are distinct from RIK XML/API services that generally require a contract, apart from any separately verified public exceptions.
“Daily” describes the catalogue's update schedule, not a guarantee that every underlying company fact changes or is reverified every day. Keep the source file date with each import.
Two catalogue defects found during this review
First, the production download endpoint accepted a signed token belonging to the Registry cards document when it was paired with the Commercial pledge numeric path. It returned HTTP 200 and served the token-selected Registry cards content under the mismatched URL. Legalcode issue asks for the token to be cryptographically bound to the requested path so that source substitution cannot occur silently.
Second, all daily package descriptions repeat that there are eight downloadable Business Register datasets, while the exact indexed inventory contains nine: the original eight listed above plus Shareholders. The monthly annual-report series is additional and separately classified. Issue asks for the current source count and normalized inventory to be reconciled.
These defects do not change the field descriptions verified from the correctly matched documents. They do mean that coverage counts and downloaded-document identity require care until fixed.
A safe joining strategy
For a company-focused data model:
- use registry code as the primary cross-dataset company key;
- preserve VAT number and RIK's internal legal-person ID as distinct identifiers with their own namespaces;
- use pledge number, ruling number, registry-card entry number and
report_idonly for their respective child records; - never match people solely by name, and do not assume a generic
Person IDis a public personal identification code; - carry the source dataset, file date and legal-entity status with every row; and
- treat missing or undocumented fields as unknown, not false.
This avoids merging a company identifier with a person, document, pledge or ruling identifier merely because all are represented as codes.
Conclusion
The indexed e‑äriregister catalogue describes a useful group of entity, ownership, management, security, registry-event and financial-report datasets. Company registry code is explicitly available across most packages and is inherited by General data from the Basic dataset. In annual-report data, the general-information file supplies the registry code and report_id connects the related CSVs.
The exception is Persons not on registry card, whose indexed description does not advertise any fields, so its identifier coverage remains unproved. The current files also exclude deleted entities and omit personal identification numbers from 1 November 2024. Reliable use therefore requires company-code matching, source-date tracking and careful separation of company, person and record-specific identifiers.
Sources and audit issues
This article provides general legal information, not advice for a specific matter. Laws, facts and procedural deadlines may change the result. Follow the linked primary sources and obtain local advice before acting.