Skip to main content

Start here

This guide contains public integration notes for Czechia. Use it for identifier formats, search behavior, and country-specific caveats. The live source of truth for coverage, pricing, data sources, documents, legal forms, roles, and status values is the pricing page.

Czechia coverage, pricing, and sources

Open the current catalog for supported datapoints, documents, sources, identifiers, and availability.
Country details below are preserved as integration notes. If a table or example conflicts with the live pricing page, use the pricing page as the source of truth and contact support.

Data Sources

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.

Registers

  • 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 reading public register 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 reading public register pages. Currently implemented but not yet exposed as a standalone datapoint (commented out in request 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).
  1. ARES is always queried first to discover the entity and get base attributes (name, address, legal form, activity codes, identifiers, status)
  2. 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
  3. For overlapping attributes (e.g., legal name, address), the primary source takes precedence over ARES
  4. AI enrichment is applied as a final step: activities get ISIC codes, status gets standardized classification, legal form gets ISO 20275 codes

Company Identifiers

Query Identifiers

ICO Format: The ICO (Identifikacni cislo osoby) is always 8 digits. Input with spaces is tolerated — they are automatically stripped before processing.

Identifiers in API Response

Once you retrieve company data, the identifiers object contains all available identifiers for that entity:
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 Capabilities

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

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.

Status Determination Logic

Closure Reasons (from VR)

When a company is dissolved, the closure reason is determined by parsing Czech legal text from the Commercial Register:
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.

Sole Proprietors (codes 100–110)

Partnerships and Capital Companies (codes 111–121)

Cooperatives (codes 131–261)

State and Government Entities (codes 301–392)

Foreign / Branch Entities (codes 401–442)

Branches and Sub-units (codes 501–541)

Education (codes 601–671)

Civil Society / Non-profits (codes 701–771)

Municipalities and Regions (codes 801–811)

Foreign and International Entities (codes 901–999)

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.

Extraction Details

  • 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)
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

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.

Shareholders

Shareholders are extracted from the Commercial Register (VR) under the Spolecnici (Partners) section. Data is obtained by parsing the VR HTML pages.

Extraction Logic

  • Section detection: The parser looks for Spolecnici (Partners) or Akcionar (Shareholder) headers in the VR HTML
  • Sole shareholder: When the section header contains Jediny (Sole), the shareholder is assigned 100% ownership if no explicit percentage is found
  • Multiple shares: If a shareholder has multiple entries/shares, they are summed into a single aggregate stake
  • Corporate vs individual: Determined by presence of ICO number or legal form suffix (a.s., s.r.o., etc.)

Ownership Data

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.

Activity Code Mapping

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.

Activity Codes by Source

Data Availability Matrix

Legend: Yes = Available | No = Not Available | Limited = Conditionally Available | Async = Asynchronous processing

Documents by Company Type

All Entity Types (Companies & Sole Traders)

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) fast search dataset.

Data Source Priority & Routing

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:
  1. ARES — Always queried first (30s timeout, 3 retries). Provides base attributes: name, address, legal form, activities, identifiers, status
  2. 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
    • rzp — RZP is fetched (1m timeout, 2 retries). Provides: name, address, registration date, activity descriptions
    • Other/null — Both VR and RZP are queried in parallel (best-effort). Any available data is merged
  3. 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).

Attribute-Level Source Mapping

Example API Responses

All examples use placeholder data. Query: POST /v2/company with { "id": "<id>", "countryCode": "CZ", "dataPoints": ["company", "legalRepresentatives"] }
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 fast search source. 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.).
Documents are returned when "dataPoints": ["availableDocuments"] is requested.

Fast search data

Czech company data is periodically synchronized from the ARES open dataset into a fast search index. Search queries hit the fast search index first for instant results, with automatic fallback to the live ARES API if the fast search index misses.

Companies in fast search data

The fast search index contains all non-terminated Czech entities from ARES. The filtering is based on the dissolution date: 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.

Onboarding Mode

In onboarding mode, requests for the company datapoint use the fast search dataset rather than a live ARES lookup. This provides faster responses with lighter enrichment. Data freshness depends on the source refresh schedule.

Quirks & Gotchas