Every result returned by the Match & Enrich API includes a dedicated explainability layer, designed to help you understand how the result was resolved, why it was selected, and how closely it matches your input. The explainability layer has three components:
- Resolution scenario: A plain-language explanation of how the API interpreted your input and what type of result was returned
- Confidence score: A numeric indicator of how closely the returned company matches the provided input
- Matched attributes: A breakdown of which specific input attributes contributed to the match, and how
This section will guide you on how to use these attributes effectively to filter and refine the results according to your specific requirements.
Resolution scenario
The resolution scenario tells you how the API resolved your input. It consists of two parts:
- A scenario label: A categorical identifier describing the type of resolution applied
- A plain-language summary: A human-readable sentence explaining how the input was interpreted and why the result was returned
The following scenarios are possible:
| Scenario | What it means |
|---|---|
direct_resolution | The input mapped cleanly to a single company with no interpretation needed. |
inferred_resolution | The input required contextual reasoning to select the most likely intended entity. Example: Boeing + boeing.com — the API inferred that in the absence of a specific registration name or address, the user is referring to the HQ of the main entity operating the Boeing brand. |
group_proxy_resolution | The result was selected through corporate group connections rather than direct name matching. Example: LVMH + Romania — no LVMH-named entity exists in Romania, but the API identifies Somarest SRL as the entity through which LVMH operates in that market through group-level connections. |
conflict_resolution | Conflicting signals were detected; the API resolved on the strongest available evidence. Example: A company name paired with a website belonging to a different company — the name and address point to different entities; the API identifies the conflict and resolves on the stronger signal, in this case name and address. |
historical_resolution | The input referred to a past identity; the API traced continuity forward to the current entity. Example: A company whose digital identity now points to a new website as part of a rebranding or merger/acquisition. |
ambiguity_resolution | Multiple plausible candidates were returned, ranked by closeness to the input. Example: Green Cleaners Solutions + New York, US — the name is common and shared by multiple unrelated companies; without a stronger identifying signal, the API returns up to five most plausible candidates for the user to choose from. |
intent_resolution | The API recognised what the input referred to but could not safely resolve to a specific entity. Example: Nestlé + Iceland — the API clearly identifies the input as referring to the Nestlé group, but no confirmed Nestlé entity with presence in Iceland exists in the dataset. |
unresolved | No coherent match could be identified after exhausting all resolution logic. |
Each scenario is complemented by a fixed plain-language summary. The table below shows the exact summary returned for each scenario.
Note: Summaries marked with
{placehoders}are dynamic — the placeholder is replaced with the relevant company or group name at resolution time. All other summaries are returned exactly as shown.
| Scenario | Summary |
|---|---|
direct_resolution | The input directly matches a specific company, and no alternative candidates were identified. |
inferred_resolution | The input required interpretation, and the result was selected as the most likely match based on consistent signals. |
group_proxy_resolution | The input was linked to the broader {group_name} group, and a local entity was selected based on its presence in the specified location. |
conflict_resolution | The input contains conflicting signals, and the result was selected based on the most reliable matching information. |
historical_resolution | The input refers to a company identity that has changed over time, and the result reflects its current or most relevant form. |
ambiguity_resolution | The input could not be reduced safely to a single company, so multiple plausible candidates were returned. |
intent_resolution | The intent was identified as related to {company_name}, but no specific entity could be resolved safely. |
unresolved | The input could not be resolved to a specific company because no coherent company identity could be identified. |
Confidence score
The confidence score is a numerical value between 0 and 1 indicating how closely the returned company matches the provided input.
A score closer to
1indicates a higher level of confidence in the match, while a score closer to0suggests lower confidence.
The following factors are considered during scoring:
- Input completeness: The level of specificity of each matched data point.
- For example, if the input address is specified down to street level but the API matches at city level, the score will be slightly lower, unless other strong signals support the same match.
- Relevance of matched information: The probability of a particular data point resulting in a precise match.
- A verified website or domain is highly relevant due to its uniqueness, while a company name alone is less so, meaning it benefits from additional validation such as an address or phone number.
- Data extracted from a company's own website carries greater weight than data sourced from social media or third-party mentions.
- Structural boost: When the API resolves a company through corporate group connections rather than direct attribute matching, the strength of that group-level confirmation is reflected in the score.
- This means a result that looks surprising at the attribute level (e.g. where the returned entity's name bears no resemblance to the input) can still carry a high confidence score, because the group-level evidence is strong.
TipUse the confidence score to establish a threshold and filter out results that do not meet your desired level of confidence. For example, setting a minimum confidence score of 0.7 will exclude any result below that threshold.
Matched attributes
The matched_on field returns the set of attributes that were matched against the Veridion database using the provided input.
For each listed attribute, the attributes field details match information such as confidence scores, values matched, source and type of the match. Some attributes can include additional information.
Company Name
| Field | Description | Possible Values | Example |
|---|---|---|---|
confidence_score | A decimal value between 0 and 1, indicating the reliability of the attribute match. | 0-1 | 0.97 |
match_type | Type of match based on name similarity score. Exact - input name matches exactly name on record; legal name exact matches account for variations in the legal termination ( e.g. LTD is the same as Limited ) Fuzzy - input name matches partially name on record; fuzzy matches are never allowed on legal names | Exact, Fuzzy | "Exact" |
match_source | Source of the matched name on record. Company Commercial Name - the main commercial name of the company Company Legal Names - any of the legal names available on record ( either extracted from the registry or digital footprint, main or historical ) Company Alternate Names - include all names extracted from the digital footprint i.e. secondary/historical names identified on the website, the website URL, or social media | Company Commercial Name, Company Legal Names, Company Alternate Names | “Company Commercial Name” |
value | Matched company name on record | String value | "Nordic Service Group" |
Address
| Field | Description | Possible Values | Example |
|---|---|---|---|
confidence_score | A decimal value between 0 and 1, indicating the reliability of the attribute match. | 0-1 | 0.97 |
match_type | Type of match based on address string equality or geo proximity. String equality is performed at address element level, where an element is any of Country, Region, City, Postcode, Street, Street Number. Geo proximity is verified at latitude and longitude coordinates level. Exact - all address elements present in input are present and equal in output, using string equality Partial - address elements are missing or different in input or output Approximate - method checks distance between address coordinates ( lat, long ) in a radius of up to 3km | Exact, Partial, Approximate | "Exact" |
match_source | Source where the address match was identified Registered Address - the legal address of registration, as provided by the registry with which this company incorporated. The legal address might differ from the operational (office) locations of the company. Operational Address - any place where the company maintains a business presence, such as HQ, regional offices, branch locations, factories, or stores. | Registered Address, Operational Address | "Operational Address" |
match_element | Specific element of the address matched | Country, Region, City, Postcode, Street, Street Number, Coordinates | "Street Number" |
value | Matched Location on record, in JSON format, including all location elements | JSON value | |
Website
| Field | Description | Possible Values | Example |
|---|---|---|---|
confidence_score | A decimal value between 0 and 1, indicating the reliability of the attribute match. | 0, 0.85, 1 | 0.85 |
match_type | Type of match based on matched domain elements. Exact - when input website matches website on record exactly; accounts for differences in schema ( e.g. www.veridion.com is the same as veridion.com ) Partial - when TLD differs between input website and website on record ( e.g. ikea.com vs ikea.nl ) | Exact, Partial | "Partial" |
match_source | Source of the web domain match | Main Domain, Redirecting Domain, Alternate Domain | "Main Domain" |
value | Matched website on record | String value | “nordicservicegroup.com” |
Phone Number
| Field | Description | Possible Values | Example |
|---|---|---|---|
confidence_score | Binary match score, either 0 or 1, indicating the reliability of the attribute match. | 0, 1 | 1 |
match_type | Type of match for the phone number, always Exact | Exact | "Exact" |
match_source | Source where the phone number was matched Primary - primary phone number used to contact the company Secondary - additional phone numbers linked to the company ( generally front-office phone numbers or departmental contact numbers ) | Primary, Secondary | "Primary" |
value | Matched phone number on record | String value | "+1234567890" |
Registry ID
| Field | Description | Possible Values | Example |
|---|---|---|---|
confidence_score | Binary match score, either 0 or 1, indicating the reliability of the attribute match. | 0, 1 | 1 |
match_type | Type of match based on the registry data, always Exact | Exact | "Exact" |
match_source | Type of registry ID matched | VAT, LEI, EIN, TIN, Other | "VAT" |
value | Matched registry ID on record | String value | "FR45448555268" |
TipFor best results, combine the resolution scenario, confidence score, and match details to assess the quality of a result.
For instance, a fuzzy match on an alternate commercial name may be acceptable if the address is fully matched or the overall confidence score is 0.8 or above; but the resolution scenario will tell you whether additional interpretation was involved, helping you calibrate your confidence accordingly.
