TL;DR
- Choose a registry source such as OpenCorporates when the answer must identify a legal entity. Evaluate Dun & Bradstreet when commercial business identity and linkage are central. Senzing is a resolution engine for supplied records, rather than a ready-made universe of companies.
- A high match rate can conceal expensive false joins. Preserve candidate records and allow the system to abstain.
- Compare cost per accepted match, including human adjudication and data rights. API calls alone are a poor buying denominator.
- Keep legal company, trading brand, office and ultimate parent separate before matching.
Decide what entity the record describes
“Acme” is not an identifier. It can mean a legal company, an old name, a local branch or a brand shared by unrelated businesses. An entity-resolution API becomes useful when it returns the right kind of entity with enough evidence to explain the join.
For outbound account research, a trading business may be sufficient. For a contract, tax record or regulatory check, the legal entity and jurisdiction matter. For account planning, the ultimate parent is a relationship, not a replacement for the local company. These differences belong in your matching policy before they belong in a model.
Take a hypothetical CRM record with the name “Acme Europe”, a London address and a group website. Matching the website to the US parent may be plausible but wrong for an agreement signed by a UK subsidiary. The same parent match might be useful for consolidated reporting. Store both relationships and their purpose rather than overwrite the local record.
The adjacent lead-to-account matching guide covers routing inside Salesforce. This decision concerns identifying external businesses when the original record is incomplete or ambiguous.
Three different purchases
| Option | What you are buying | Strong fit | Main boundary | Budget basis |
|---|---|---|---|---|
| OpenCorporates | Registry-derived company records and reconciliation access | Legal identity with source provenance | Coverage and timeliness follow available registers | Commercial API/data terms and request allowances |
| Dun & Bradstreet | Commercial business identity and related data | Business matching within a D-U-N-S-based estate | Entity granularity and country coverage need validation | Contracted product, data scope and usage |
| Senzing | An entity-resolution SDK | Resolving records you already hold | The engine does not supply a global company dataset | Record-volume licence plus hosting and data |
This is an architecture comparison checked on 6 October 2026, not an accuracy ranking from a live three-product test. A database and a matching engine solve different parts of the job. Some teams need both.
OpenCorporates for registry-backed identity
OpenCorporates' API reference documents company search, jurisdiction/company-number identifiers and source information. It also points to its OpenRefine reconciliation service for matching names to legal entities. Those are useful capabilities when your analyst must inspect the candidate and trace it to a registry.
The buying advantage is explainability at the record level. A company number plus jurisdiction is more durable than a name alone. Preserve retrieved dates and registry links alongside the matched identifier. Neither a registry address nor an active status proves that the company is a good prospect or that the listed address is its sales office.
Use this route for company-name clean-up, supplier identity and account research where legal provenance matters. It is a weaker standalone choice when the task requires rich sales attributes or an operating-location hierarchy. The documentation distinguishes open-data use from other access and account-dependent limits. A commercial GTM pipeline should obtain terms for its use, storage and onward delivery rather than assume that public visibility means unrestricted reuse.
Dun and Bradstreet for commercial identity
Dun & Bradstreet's developer resources describe its data/API ecosystem. Its business identity proposition centres on D-U-N-S and commercial company data. That makes it a logical candidate when your existing CRM, credit process or account hierarchy already uses that identity system.
The practical attraction is continuity between matching and downstream enrichment. A resolved business identifier can become the key for subsequent data retrieval and linkage. Specify whether the expected result is a headquarters, subsidiary or site. Accepting a parent identifier everywhere may improve apparent completeness while making territory ownership less accurate.
Choose this route when commercial records and an established identity estate justify a contracted data purchase. Do not buy it solely for a name-similarity score that a smaller workflow could provide. No scope-comparable public quote was established for this guide. Budget the precise API products, countries, refresh frequency, stored fields and permitted CRM use. A bundled contract may make a match cheaper than a standalone purchase, but that is a quote comparison rather than a general product price.
Senzing for resolution over supplied data
Senzing's pricing page describes an entity-resolution SDK and a record-based commercial model, with support included in paid subscriptions. The important distinction is that you bring the records. Licensing the engine does not purchase the external company evidence required to resolve a vague name.
This architecture suits a data engineering team combining CRM, billing, partner and third-party datasets while retaining control of processing. Resolution can reveal that two input records describe one entity or that records are related. The team still owns data mapping, hosting, accepted identifiers and the policy for sending a result into revenue systems.
It is a poor fit for a buyer who needs a simple hosted lookup returning fresh company profiles with little implementation. Compare licence thresholds and record counting with your ingestion pattern, including repeated source versions. The public pricing slider displays US$58,560 annually for 10 million Data Source Records, based on upfront payment and standard terms. That is a large-volume reference, not a quote for this 5,000-record project. Paid subscription support is included; hosting and any purchased reference dataset remain separate. Keep engine confidence distinct from the truth of an underlying source record.
A labelled ambiguity sample
For the proposed 5,000 noisy records, do not start by demanding that every input receive a result. Label a stratified sample containing complete records, common names, missing countries, renamed companies, branches and group websites. Have an authorised data owner identify the intended entity from inspectable evidence.
Use three dispositions: auto-accept, review and abstain. A confidence threshold should be chosen from the cost of a false join and the observed labelled results, rather than copied from another provider's score scale. A score of 90 in one API does not necessarily mean the same thing in another.
In a hypothetical evaluation of 200 labelled inputs, a setting returns 160 auto-matches and eight are wrong. Precision is 152/160, or 95%. A stricter setting returns 120 and one is wrong: 119/120, or about 99.2%. The stricter setting reduces automatic coverage from 80% to 60%. This example illustrates the trade-off; it is not a vendor benchmark.
Evaluate incorrect parent joins separately from harmless punctuation differences. Measure unresolved records as well as accepted matches. An honest abstention is preferable to assigning a contract or territory to the wrong business.
The economics of accepted matches
Suppose 5,000 inputs produce 3,500 auto-accepted matches, 1,000 reviews and 500 abstentions. If each review takes three minutes, that is 50 analyst hours. At an assumed loaded cost of £40 an hour, the review component is £2,000. If 800 reviewed records are accepted, the workflow produces 4,300 accepted matches.
Cost per accepted match is therefore (data/API cost + engine and hosting cost + £2,000 review labour) / 4,300. An illustrative £1,000 data/technology bill would make it about £0.70. That £1,000 is a scenario assumption, not a quote for any provider. Include remediation if rejected or incorrect matches require manual CRM repair.
The RevOps CRM setup playbook can help turn these fields into a written implementation brief. Put the accepted entity type, evidence, identifier and disposition in that brief so procurement compares equivalent outputs.
Ship a reversible match contract
Write the original input, normalised fields, candidates, chosen identifier, relationship type, source date, engine version and decision reason to an audit record. Send the accepted identity to the CRM separately from the raw source name. A later correction should reverse a link without deleting the original evidence.
Use an idempotent request key and cache permitted results to avoid charging repeated retries as fresh research. Route ambiguous records to a queue with an owner and deadline. Apply an expiry policy to cached evidence according to licence and business risk; company mergers and renamed entities make permanent assumptions unreliable.
For most teams, begin with the identity source that matches the legal or commercial question. Add a dedicated resolution engine when multiple datasets and ongoing maintenance justify it. A universal match-rate winner would obscure the decision that matters: which accepted identities can your business safely act on?
FAQ
Can we match on company domain alone?
A domain is useful evidence but can describe a brand, group, reseller or shared platform. Combine it with country, address and known registration identifiers where available. Preserve domain-to-entity relationships instead of treating a domain as a permanent unique legal identifier.
Should uncertain records be deleted?
No. Keep them unresolved with the original input and reason. An abstention should block the risky join, not erase a prospect or hide a data-quality problem. A later enrichment source or human correction may resolve it.
Is a provider confidence score a probability?
Only if the provider defines and validates it that way for the relevant task. Otherwise treat it as an ordering signal. Calibrate auto-acceptance against labelled records and repeat the exercise after a material model, source or market change.
How does this differ from CRM deduplication?
Deduplication decides which internal records to combine. External resolution decides what real-world entity a record describes. Resolve identity before a destructive merge, retain survivorship rules and use the separate CRM data-cleaning guide for internal repair. The company-data provider guide covers broader enrichment procurement.
