Czechia uses multiple official registers orchestrated through ARES. For a given entity, data is assembled from ARES as the discovery layer, then enriched from the primary source register indicated by ARES. The primary source takes precedence for overlapping attributes.
ARES (Administrative Register of Economic Subjects) — Operated by the Ministry of Finance (ares.gov.cz), ARES is the central discovery layer for all Czech entities. It aggregates data from over a dozen underlying registers and provides: company name, legal form, registered address, activity codes (CZ-NACE), registration/dissolution dates, tax identifiers (DIC/DPH), and registration statuses across all connected registers (VR, RZP, DPH, IR, etc.). ARES also indicates a primary data source per entity (primarniZdroj), which drives the orchestration strategy.
VR (Commercial Register) — The Obchodni rejstrik, operated by the Ministry of Justice (or.justice.cz). Contains detailed data for legal entities registered in the commercial register: legal name, registered address, share capital, legal form, business purpose, legal representatives (Statutarni organ), shareholders (Spolecnici), and dissolution/deletion information. Data is extracted by parsing HTML pages (no structured API is available).
RZP (Trade Licensing Register) — The Rejstrik zivnostenskeho podnikani (rzp.gov.cz). Contains business license data primarily for sole traders and licensed businesses: legal name, registered address, registration date, and licensed activities. Accessed via a session-based XML API. Also the source for Trade Register Extract PDF documents.
ESM (Evidence of Beneficial Owners) — The Evidence skutecnych majitelu (esm.justice.cz). Contains Ultimate Beneficial Owner (UBO) data: names, birth dates, nationalities, residence addresses, ownership percentages, voting rights, and control nature (direct/indirect). Data is extracted by parsing HTML pages. Currently implemented but not yet exposed as a standalone datapoint (commented out in workflow configuration).
ARES is the orchestration hub. Every company profile request starts with ARES for discovery and base attributes. ARES indicates a primary source per entity (vr, rzp, or others), and the system fetches complementary data from that source. If the primary source fetch fails, available data from ARES alone is used. If no primary source is indicated, both VR and RZP are queried in parallel (best-effort).
How does the multi-source orchestration work?
ARES is always queried first to discover the entity and get base attributes (name, address, legal form, activity codes, identifiers, status)
ARES indicates a primary source (primarniZdroj):
vr — Commercial Register: the system fetches VR data (legal reps, shareholders, capital, status, legal form) and merges it into the ARES base
rzp — Trade Licensing Register: the system fetches RZP data (name, address, registration date, activities) and merges it
Other/null — both VR and RZP are queried in parallel, and any available data is merged
For overlapping attributes (e.g., legal name, address), the primary source takes precedence over ARES
AI enrichment is applied as a final step: activities get ISIC codes, status gets standardized classification, legal form gets ISO 20275 codes
Spaces are stripped (e.g., 19188 889 becomes 19188889)
ICO Format: The ICO (Identifikacni cislo osoby) is always 8 digits. Input with spaces is tolerated — they are automatically stripped before processing.
Once you retrieve company data, the identifiers object contains all available identifiers for that entity:
Identifier Type
Format
Example
Found In
ico
8 digits
21110365
All entities
dic
CZ + 8-10 digits
CZ21110365
Tax-registered entities (normalized with CZ prefix)
vat
CZ + 8-10 digits
CZ21110365
Only when ARES confirms active DPH (VAT) status
VAT vs DIC: The dic (Tax Identification Number) is always returned when available. The vat identifier is only set when ARES confirms the entity has active DPH (VAT) registration status. We do not synthesize VAT from ICO or query the DPH register separately. For sole traders and individuals, the VAT number may have 9-10 digits and can differ from the ICO.
Search Performance: Use ICO-based searches for best performance and exact matching. Name searches query ARES and may return up to 30 results. If a name search returns too many results, ARES will return an error suggesting a more specific search term.
Unsupported search inputs: DIC and VAT numbers are not supported as search inputs. Only ICO and company name searches are available.
Company status is determined from ARES registration statuses across multiple registers (VR, RES, RZP, DPH, IR). The logic is deterministic — no AI inference is involved for status determination. AI enrichment is applied afterward for standardization only.
When a company is dissolved, the closure reason is determined by parsing Czech legal text from the Commercial Register:
Czech Pattern
Standardized Closure Reason
konkurs / konkurz / insolvence / upadek
Bankruptcy
fuze / slouceni / splynut
Merger
prevod jmeni na jedineho spolecnika/akcionare
Acquisition
zrusena s likvidaci (rozhodnutim valne hromady)
Voluntary Dissolution
zrusena s likvidaci (general)
Liquidation
zrusena dle paragrafu / ex lege
Administrative Dissolution
rozhodnutim soudu / usneseni soudu
Court Order
Other patterns
Other
VR closure reasons are extracted by pattern-matching normalized (diacritics-stripped) Czech text from the Commercial Register’s “Ostatni skutecnosti” (Other facts) and insolvency sections. If no specific pattern matches, the closure reason defaults to “Other.”
Czechia uses a deterministic legal form mapping via the ARES “Právní forma” codelist. The mapping provides the local Czech name and an English translation for each code. For known codes, standardized classification is applied directly; for unrecognized codes, AI-based classification is used as fallback. ISO 20275 (ELF) codes will be populated in a future update.
Legal forms are classified from official registry data. For known codes, standardized classification is applied directly; for unrecognized codes, AI-based classification is used as fallback.
Legal representatives are extracted from the Commercial Register (VR) under the Statutarni organ (Statutory body) section. Data is obtained by parsing the VR HTML pages.
Source: VR (or.justice.cz) HTML pages, specifically the Statutarni organ section
Role detection: Currently extracts persons with the Jednatel (Managing Director) role label
Data extracted per person: Full name, birth date (day/month/year), residential address, function start date (Den vzniku funkce), function end date (Den zaniku funkce)
Role mapping: Jednatel is mapped to Managing Director (standardized)
Czech Role
English Translation
Standardized Role
Jednatel
Managing Director
Managing Director
Current limitation: The VR parser specifically looks for the Jednatel label in the statutory body section. Other statutory roles (e.g., board members in a.s. companies, Clen predstavenstva, Predseda predstavenstva) may not be extracted in all cases. Legal representatives are only available for entities registered in the Commercial Register (VR).
Other key persons (such as supervisory board members and controllers) are extracted from ARES when available. These are persons associated with the company who are neither legal representatives nor shareholders.
Other key persons data availability depends on the entity type and the primary register source. Not all companies have other key persons in their register records.
Determined from register data (ICO presence, legal form suffix)
Shareholder data is primarily available for s.r.o. (Limited Liability Companies) registered in the Commercial Register (VR). Joint-stock companies (a.s.) do not list individual shareholders in the public register. Both individual and corporate shareholders are supported.
Czechia uses the CZ-NACE classification, which is the Czech adaptation of the European NACE Rev. 2 standard. The system maps activity codes across three levels:
AI Enrichment: When ISIC codes cannot be derived from NACE via formal mapping tables, the system uses an LLM to match activity descriptions to ISIC Rev. 4 codes. Every activity item includes an isAIInferred flag to distinguish official vs. AI-derived codes. CZ-NACE and NACE codes are never AI-inferred.
The Trade Register Extract is sourced from the Trade Licensing Register (RZP) via a session-based XML API. It contains current business license and registration information. The document is retrieved by: (1) starting an RZP session, (2) searching for the subject by ICO, (3) fetching an intermediate ISVS XML that contains the link to the final PDF, and (4) downloading the PDF. The document has a 1-day TTL (time-to-live) cache.
For a given entity, data is assembled from multiple sources with a clear precedence hierarchy. ARES provides the base, and the primary source register enriches it.
Orchestration Flow:
ARES — Always queried first (30s timeout, 3 retries). Provides base attributes: name, address, legal form, activities, identifiers, status
Primary source — Determined by ARES primarniZdroj field:
vr — VR is fetched (1m timeout, 2 retries). Provides: legal reps, shareholders, capital, status override, legal form, activity description
Other/null — Both VR and RZP are queried in parallel (best-effort). Any available data is merged
AI Enrichment (2m timeout, no retry) — Applied in parallel for:
Activities: ISIC codes via vector matching + formal derivation
Status: Standardized classification
Legal form: ISO 20275 codes
Merge behavior: The primary source takes precedence over ARES for overlapping attributes. If a primary source fetch fails, ARES data alone is used (graceful degradation).
Note: Dissolved companies have active: false with a closure date and closure reason when determinable from the VR register text. Joint-stock companies (a.s.) do not list shareholders in the public register.
Note: Sole traders (RZP primary source) do not have legal representatives, shareholders, or capital data. The legal name is the individual’s name. Activity description comes from licensed activities in the RZP.
Note: Entities in liquidation are treated as active (active: true) with local status “In Liquidation.” The entity still legally exists during the liquidation process.
Note: Onboarding profiles are served from the batch staging table. No AI enrichment — no standardized or iso20275Code on legal form. Legal form localName is the numeric code from ARES (e.g., "112" = s.r.o.).
Available Documents
Documents are returned when "dataPoints": ["documents"] is requested.
The cache contains all non-terminated Czech entities from ARES. The filtering is based on the dissolution date:
Condition
Included?
Description
datum_zaniku IS NULL
Yes
Entity has not been dissolved
datum_zaniku IS NOT NULL
No
Entity has been dissolved/terminated
This means active entities, entities in liquidation, and entities under insolvency proceedings are all included — only fully terminated entities (with a recorded dissolution date) are excluded.
The onboarding profile (onboardingProfile datapoint) reads directly from the staging table (cz.ares), not the live ARES API. This provides faster, cheaper responses with no AI enrichment overhead. Data freshness depends on the batch sync schedule.
Data is merged from up to three sources (ARES, VR, RZP). The primary source indicated by ARES takes precedence for overlapping attributes. If a source fetch fails, available data from other sources is used (graceful degradation).
ICO spaces are stripped
Input ICOs may contain spaces (e.g., 19188 889) which are normalized to 19188889 before processing.
VAT only for active DPH registrants
The identifiers.vat field is only set when ARES confirms active DPH (VAT) status. We do not synthesize VAT from ICO or query the DPH register separately.
Shareholders only for s.r.o.
Shareholder data with ownership percentages is only available for Limited Liability Companies (s.r.o.) in the Commercial Register. Joint-stock companies (a.s.) do not list shareholders publicly.
ISIC codes may be AI-inferred
CZ-NACE codes from ARES are official. ISIC codes are derived via formal mapping when possible, with AI fallback. Check the isAIInferred flag.
Closure reasons from register text
When a company is dissolved, the closure reason is determined by pattern-matching normalized Czech text from the VR “Ostatni skutecnosti” and insolvency sections (e.g., bankruptcy, merger, acquisition, liquidation, court order).
VR HTML parsing
The Commercial Register (justice.cz) does not provide a structured API. Data is extracted by parsing HTML pages, which may occasionally miss fields if the page structure changes.
Legal form mapping is deterministic
Czech legal forms are mapped deterministically using the ARES_LEGAL_FORM_MAPPING codelist (140+ forms). ISO 20275 codes are added via AI enrichment.
UBO data implemented but not exposed
Ultimate Beneficial Owners from ESM (Evidence of Beneficial Owners) is fully implemented in activities but the standalone UBO datapoint is currently commented out in the workflow configuration. UBOs from ARES are returned when available as part of the company profile.
In Liquidation = Active
Entities with status “V LIKVIDACI” in VR or RES are treated as active (active: true) because the entity still legally exists during the liquidation process.
RZP uses session-based API
The Trade Licensing Register requires starting a session before any data requests. Sessions may timeout, requiring retry logic.
Capital in CZK only
Share capital from the VR is always expressed in Czech Koruna (CZK) with formatted strings using Czech locale (e.g., 200 000 Kc).
Sole shareholder default to 100%
When the VR HTML indicates a Jediny spolecnik (sole partner) section and no explicit ownership percentage is found, the system defaults the shareholder to 100% ownership.