> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.
# Company Data
> Automated registry lookups, company status validation, and data extraction across 220+ countries. Pay-per-call $2.00 KYB, no contracts.
When a business verification session starts, Didit queries official company registries to retrieve and validate company information. This automated lookup provides the foundation for the entire business verification process.
## Registry lookup
Didit connects to company registries in supported countries to retrieve official data. The lookup is triggered automatically when the company name, registration number, and country are provided.
### Search types
Registry searches support two modes:
| Mode | Description |
| ------------ | --------------------------------------------------------------------------------------------------- |
| **Exact** | Matches the company name or registration number precisely |
| **Contains** | Matches companies whose name contains the search term — useful when the exact legal name is unknown |
### Search workflow
The registry lookup follows an asynchronous workflow:
Didit queries the registry with the provided company name, country, and optional registration number. The search runs asynchronously.
Poll the search status until results are resolved. Large registries may take a few seconds to return results.
Review the returned companies and select the correct match. Didit links the selected company to the KYB check and populates all available data.
If the company is not found in the registry, submit company data manually. The session continues with the provided data, and `is_from_registry` is set to `false`.
### Retrieved data
| Field | Description |
| --------------------------- | ------------------------------------------------------------------------------------------ |
| `company_name` | Legal name as registered with the authority |
| `registration_number` | Official company registration or incorporation number |
| `country_code` | Country of incorporation (ISO 3166-1 alpha-3) |
| `company_type` | Legal entity type (Ltd, LLC, PLC, SA, GmbH, SL, etc.) |
| `registry_status` | Current company status from the registry (`active`, `dissolved`, `struck_off`, etc.) |
| `incorporation_date` | Date the company was originally registered |
| `registered_address` | Official registered office address |
| `tax_number` | Tax identification number where available |
| `alternative_names[]` | Trade names, dbas, former legal names |
| `legal_entity_identifier` | LEI — for financial institutions and listed entities |
| `nature_of_business` | Short description of the business (in the registry's language) |
| `registered_capital` | Authorized / issued capital as an `{amount, currency}` object |
| `location_of_registration` | City / subdivision of the registry of record |
| `control_scheme` | Control / governance scheme where the registry exposes it |
| `website`, `email`, `phone` | Contact details on file with the registry |
| `addresses[]` | Additional registered or trading addresses |
| `industries[]` | Industry classification codes (SIC, NACE, or local equivalents) |
| `accounts` | Filing dates — `due_by_date`, last filed, and next filing date |
| `financial_summary` | Summary financial data where the registry publishes it (revenue, employees, filing status) |
| `confirmed_by_user_at` | Timestamp when the end user confirmed or edited the registry data |
| `last_console_edit_at` | Timestamp of the last console-side edit by an analyst |
| `is_editable` | `true` while registry-sourced data can still be edited by the end user in the hosted flow |
| `is_from_registry` | `true` for registry-sourced companies, `false` for manual entry |
| `fetch_status` | `pending`, `resolved`, or `failed` — registry lookup state |
| `verification_status` | `verified`, `failed`, or `unknown` |
### Company statuses
| Status | Description |
| ------------------ | ---------------------------------------------------- |
| **Active** | Company is currently active and in good standing |
| **Dissolved** | Company has been formally dissolved |
| **Struck off** | Removed from the register (e.g., for non-compliance) |
| **In liquidation** | Company is in the process of being wound up |
| **Dormant** | Registered but not currently trading |
Companies with a status other than **Active** may be automatically flagged or declined depending on your workflow configuration.
### Data source indicator
Each company record includes an `is_from_registry` flag:
* **`true`** — data was retrieved from an official company registry
* **`false`** — data was manually submitted because the company was not found in the registry
The `fetch_status` field tracks whether the registry lookup has completed, failed, or is still in progress.
## Registry data vs user-provided data
Didit keeps registry-returned data and user-confirmed data as **separate audit records**, with a merged canonical view used by downstream checks. Every company carries three related blocks:
| Field | Description |
| -------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `registry_data` | Raw payload returned by the registry. Immutable — kept as an audit record of exactly what the registry said, unchanged. |
| `user_provided_data` | What the end user confirmed or edited during the registry-confirmation step in the hosted flow. |
| Top-level canonical fields (`company_name`, `registration_number`, `country_code`, `incorporation_date`, etc.) | The merged truth — user-confirmed data when present, registry data as fallback. Downstream features (document OCR cross-check, AML screening, risk assessment) run against the canonical view. |
The `confirmed_by_user_at` timestamp marks when the end user confirmed or edited the registry data. While that timestamp is still null and `is_editable` is `true`, the end user can continue to modify fields inside the hosted flow.
For **manual-entry companies** (`is_from_registry: false`), `user_provided_data` is the only source and `is_editable` becomes `false` after the user submits.
Analysts can see the two sources side-by-side in the [Business Console](/business-verification/console) session review and diff what the registry said vs what the user confirmed.
## Configurable registry form fields
You control which company-data fields the hosted verification flow asks for during the registry-confirmation step. Configure them in the Business Console: open the workflow editor, select the **KYB Registry check** node, and switch to the **Fields** tab.
Each field has one of three states:
| State | Behavior |
| ------------ | ----------------------------------------------------------------- |
| **Hidden** | The field is not shown in the hosted flow and is not collected. |
| **Optional** | The field is shown; the user can leave it empty. |
| **Required** | The field is shown and must be filled before the user can submit. |
Three fields are always shown and always required — they identify the company and cannot be configured: `company_name`, `country_code`, and `region` (state/region, where the registry is regional).
The 16 configurable fields:
`registration_number`, `incorporation_date`, `legal_address`, `vat_number`, `alternative_names`, `tax_number`, `company_type`, `legal_entity_identifier`, `location_of_registration`, `nature_of_business`, `registered_capital_amount`, `registered_capital_currency`, `website`, `email`, `phone`, `control_scheme`
By default — and for all existing workflows — only `incorporation_date` is **Required**; every other configurable field is **Optional**, so the form behaves exactly as it did before this setting existed.
Requiredness is enforced server-side: submitting the registry form with a required field empty returns `400` with per-field error messages, and the hosted UI renders only the enabled fields. In the workflow API, the setting is the `kyb_registry_fields_config` object on the KYB Registry node — see [feature configs](/management-api/workflows/feature-configs#kyb-registry) for the shape.
`vat_number` marked **Required** is only enforced for companies incorporated in an EU VAT country (see below) — for all other countries the field is treated as optional even when required, since there is no EU VAT number to collect.
## VAT validation (VIES)
When the end user (or the registry) provides a `vat_number` for a company incorporated in the EU, Didit validates it against the European Commission's [VIES](https://ec.europa.eu/taxation_customs/vies/) service when the registry step is submitted.
* **Coverage** — the 27 EU member states plus Northern Ireland (`XI`). Greek VAT numbers are checked under the `EL` prefix automatically. Companies from any other country skip validation entirely and get `vat_validation_status: "not_applicable"`.
* **Prefix handling** — the number is normalized before the check, so it can be submitted with or without the country prefix (`DE123456789` and `123456789` are equivalent for a German company).
The result is stored on the company and exposed in the [KYB decision payload](/business-verification/response-schema#company-block):
| Field | Description |
| ----------------------- | ----------------------------------------------------------------------- |
| `vat_number` | The VAT number as submitted |
| `vat_validation_status` | `valid`, `invalid`, `could_not_validate`, or `not_applicable` |
| `vat_validated_name` | Trader name registered with VIES, when the member state discloses it |
| `vat_validated_address` | Trader address registered with VIES, when the member state discloses it |
| `vat_checked_at` | Timestamp of the VIES check |
| Status | Meaning |
| -------------------- | -------------------------------------------------------------------------- |
| `valid` | VIES confirmed the VAT number is registered |
| `invalid` | VIES rejected the number (not registered or malformed) |
| `could_not_validate` | VIES or the member state was unavailable — the number could not be checked |
| `not_applicable` | No VAT number was provided, or the company is outside the EU VAT area |
**Name cross-check.** When the number is `valid` and VIES discloses the registered trader name, Didit fuzzy-compares it against the submitted company name. A meaningful divergence raises the `KYB_COMPANY_VAT_NAME_MISMATCH` warning (with `vies_name` and `submitted_name` in `additional_data`) without changing the session status — it is a soft signal for reviewers. Some member states do not disclose the name or address; the fields come back empty and no comparison runs.
**Configurable actions.** Two settings on the KYB Registry check node control what an unsuccessful check does to the session (values `REVIEW`, `DECLINE`, `NO_ACTION`):
| Setting | Fires when | Default |
| --------------------------- | ----------------------------------------------- | -------------------------------------- |
| `kyb_vat_invalid_action` | `vat_validation_status` is `invalid` | `REVIEW` — session goes to In Review |
| `kyb_vat_unverified_action` | `vat_validation_status` is `could_not_validate` | `NO_ACTION` — no effect on the session |
Each outcome also raises the matching warning (`KYB_COMPANY_VAT_INVALID`, `KYB_COMPANY_VAT_COULD_NOT_VALIDATE`) on the registry check — see [Business Verification warnings](/business-verification/warnings#kyb-registry-warnings).
## Data cross-referencing
Didit automatically compares the user-provided / canonical data with what the registry returned, and with OCR data extracted from uploaded documents:
* **Company name** — fuzzy matching to account for abbreviations and formatting differences
* **Registration number** — exact match validation
* **Country** — consistency check between provided and registry country
* **Address** — geocoding and normalization for comparison
Any inconsistencies are flagged as warnings in the session and visible to analysts in the console.
## Financial summary
Where available, Didit retrieves summary financial data from the registry:
* Revenue or turnover
* Number of employees
* SIC/NACE industry codes
* Filing dates and compliance status
## Additional registry fields
Depending on jurisdiction coverage, the registry response may also include:
* `alternative_names[]` — trade names, dbas, former legal names
* `legal_entity_identifier` (LEI) — for financial institutions and listed entities
* `website`, `email`, `phone` — contact information on file with the registry
* `nature_of_business` — short description (in the language of the registry)
* `registered_capital` — authorized / issued capital as an `{amount, currency}` object
All fields land in the [`business`](/business-verification/response-schema) block of the KYB decision.
## Confidence and verification status
Each registry response carries a `verification_status`:
| Value | Meaning |
| ---------- | ---------------------------------------------------------------------------- |
| `VERIFIED` | Registry returned a match and data was retrieved. |
| `FAILED` | Registry returned a match but data retrieval failed (e.g. partial response). |
| `UNKNOWN` | Company could not be located in any registry. |
Combine with `is_from_registry` to drive your own downstream logic:
| `is_from_registry` | `verification_status` | Meaning |
| ------------------ | --------------------- | --------------------------------------------- |
| true | VERIFIED | Fully verified against official registry |
| true | FAILED | Partial — some fields may be stale or missing |
| false | UNKNOWN | User-provided data only; no registry match |
## Cross-referencing outputs
Each cross-reference runs per field and returns one of:
* `MATCH` — provided data agrees with registry.
* `MISMATCH` — meaningful divergence. Flagged as a warning.
* `NO_DATA` — one side was empty; no comparison possible.
Mismatches are visible per-field in the console session review.
## Risk assessment
The company's overall risk level is calculated based on:
| Factor | Impact |
| ------------------------ | --------------------------------------------------------------- |
| **Company status** | Non-active companies increase risk |
| **Country risk** | Incorporation in high-risk jurisdictions increases risk |
| **Age** | Recently incorporated companies may receive additional scrutiny |
| **AML results** | Company-level AML screening results |
| **Ownership complexity** | Multi-layered or opaque ownership structures |
See [risk assessment](/business-verification/risk-assessment) for the full computation.
## Supported countries
Coverage varies by country — see [supported countries](/business-verification/supported-countries) for the per-region tier breakdown.
## Next steps
UBO identification and ownership chains.
Where each field appears in the payload.
Coverage by region.