Data matching for B2B records: exact, fuzzy and probabilistic rules

That separation is the foundation of dependable CRM enrichment. If two records share a company domain, they may refer to the same organisation but different offices or subsidiaries. If two contacts share a name and employer, they may still be different people. If an email matches exactly, it may be recycled, stale or attached to the wrong employment period. A single “matched” flag hides these operational differences.

This guide is for enterprise RevOps and data leaders choosing data matching rules for enrichment, deduplication and write-back. It explains exact matching, fuzzy name matching, fuzzy string matching for company names and probabilistic matching as parts of one governed workflow. It also supplies a worked method for measuring precision, recall, review capacity and cost per policy-usable unique result.

What data matching should decide

Data matching compares records to decide whether they represent the same real-world entity. In B2B systems, that broad definition must be split into narrower questions. Are these two company records the same legal or operating organisation? Are these two person records the same human? Does this employment record connect that person to that company now? Does this email or phone belong to that employment relationship, and is its status acceptable for the intended workflow?

Do not collapse those decisions into one master confidence score. A domain can be strong evidence for a company and weak evidence for a person. A professional profile URL can strongly identify a person while saying nothing about whether an old phone is still usable. Separate decisions preserve the evidence needed to correct mistakes without unmerging an entire history.

Use exact, fuzzy and probabilistic rules for different jobs

Exact matching compares values after a defined transformation. Case-folded email equality, a stable vendor person ID or a normalised company domain can produce high-confidence candidates. Exact does not mean infallible: generic inboxes, recycled addresses, duplicate supplier IDs and parent-company domains can all create false merges. Require evidence appropriate to the entity and action.

Fuzzy matching measures similarity rather than equality. Edit distance can catch a missing character; token-based methods can tolerate reordered company-name words; phonetic methods can surface pronunciation variants. Fuzzy name matching is useful for candidate generation, but it should rarely auto-merge people by itself. “Jon Smith” and “John Smith” may be one person, while two “Alex Lee” records can be genuinely different.

Probabilistic matching combines agreement and disagreement across fields according to how informative they are. A rare surname agreeing at the same company usually carries more evidence than a common title agreeing. A company domain conflict can outweigh a similar name. The output should be treated as a decision score under a documented model, not as a literal promise that a record is correct.

A practical hybrid runs the three methods in order. Accept strong exact identifiers first. Apply multi-field deterministic rules next. Score the remaining candidate pairs with fuzzy and probabilistic evidence. Use two thresholds: above the upper threshold, accept; below the lower threshold, reject; between them, review. This avoids forcing ambiguous records into a binary decision.

Normalise for comparison, but retain the source value

Normalisation makes superficial differences comparable. Lower-case domains, remove protocols and paths, convert phone numbers to a consistent international representation where country context supports it, standardise whitespace and Unicode, and parse company suffixes into a separate field. Keep the raw input beside the normalised value so reviewers and downstream systems can reconstruct what happened.

Field-specific rules matter. Removing every company suffix can help “Acme Ltd” match “Acme Limited”, but it can also erase distinctions in jurisdictions where the legal name matters. Removing punctuation from an email local part changes the address for many domains. Treat freemail domains, shared corporate domains and catch-all email domains as special cases rather than ordinary unique keys.

Track the transformation version. If the domain parser, alias dictionary or transliteration rules change, the same record can produce a different key. Versioned transforms let the team reproduce an earlier decision, compare models fairly and rematch only affected candidates.

Reduce comparisons with blocking rules

Comparing every record with every other record grows quadratically. Ten thousand incoming records against ten thousand CRM records create 100 million possible pairs. Blocking generates only plausible candidates using broad rules such as the same normalised domain, the same phone suffix plus country, or a surname prefix within the same company.

Use several blocking rules because any one rule can miss valid pairs. A person who changed company will fail an employer-domain block. A renamed company will fail a normalised-name block. Union the candidate sets, deduplicate pair IDs, then score them. Monitor which true matches each rule contributes; a cheap rule that adds no labelled true pairs creates cost without recall.

Calibrate thresholds with labelled pairs

A match rate is the share of inputs assigned a match. It is not accuracy. A permissive rule can raise match rate by merging unrelated records. Evaluate against labelled pairs that represent the real population and the action you intend to automate.

Build an authorised evaluation set across easy matches, difficult matches and clear non-matches. Include common names, subsidiaries, trading names, role changes, records with missing fields, catch-all domains, international scripts and known duplicates. Prevent the same entity from leaking across training and evaluation groups. Have reviewers record why a pair is the same, different or genuinely uncertain.

Report precision: accepted matches that are truly the same entity. Report recall: true matches that the system found. Also report false merges, false splits and the unresolved share. For CRM merging, false merges are often more expensive because activity history, consent state or ownership can be attached to the wrong entity. For suppression or duplicate prevention, false splits may create repeated outreach. The threshold must reflect that asymmetry.

Do not copy a vendor threshold into your CRM. Scores are not portable across models, fields or populations. A score of 0.9 may mean something different after a schema change, source change or market expansion. Recalibrate by entity type and decision: candidate suggestion, enrichment attachment, automatic merge and destructive deletion should not share one threshold.

Turn a match into a controlled CRM write

Matching decides identity; survivorship decides which value becomes operational. Keep them separate. A high-confidence person match does not authorise overwriting a recently rep-confirmed title with an older provider value. Store source-observed, retrieved and verified times independently, and compare them with field-level trust and freshness rules.

Use stable internal IDs for writes. External provider IDs belong in a mapping table with source and observation dates; they should not replace your CRM key. Make operations idempotent so a retry cannot create a second contact. If a request times out after the upstream system may have committed, reconcile by request ID before repeating it.

Transitive matching needs special care. If A matches B and B matches C, it does not automatically follow that A should merge with C. The middle record may contain a generic address or a shared phone that bridges two entities. Before clustering, require cluster-level consistency checks and block merges that create contradictory domains, legal IDs or simultaneous employment relationships.

Design for ambiguous and stale B2B evidence

Stale employment is a relationship problem, not necessarily a person mismatch. Preserve the person, end-date the former employment when supported and create a candidate relationship to the new company. Do not move open opportunities or account history merely because a provider returned a newer title.

Ambiguous people require more than a fuzzy name. Common names, initials, transliteration and shared employers create collisions. Require independent evidence such as a stable profile identifier, specific location, employment history or corroborated work email. An unresolved person should stay unresolved.

Catch-all email domains can accept mail for addresses that do not belong to a real named mailbox. A catch-all result does not verify the person, current employment or guaranteed delivery. Keep found, syntactically valid, domain-accepting, mailbox-verified and delivered as separate states.

Unverified phone numbers should retain type, country interpretation, source and observation date. A company switchboard is not a person’s direct dial. A number found in two sources is not necessarily independently verified if both obtained it from the same upstream dataset.

Conflicting providers should produce evidence candidates, not a last-write-wins race. Compare source observation dates, field scope and specificity. A recently retrieved old source is not fresher than an earlier retrieval of a later observation. Preserve unresolved conflicts where the cost of a wrong merge is material.

Missing fields and API failures need different states. “No email returned” may mean not found, not requested, unavailable under the plan, filtered by policy or lost in a partial response. A timeout or rate limit is an operational failure, not proof that the entity does not exist. These distinctions determine retry behaviour, billing reconciliation and whether existing CRM data may be cleared.

Measure review capacity and cost per usable unique result

Review is a finite queue. A lower automatic-accept threshold can reduce reviews but raise false merges. A higher threshold can improve precision while sending more candidates to people. Before launch, convert the ambiguous share into hours, cost and backlog.

Then calculate economics with the right denominator. Suppose an illustrative pilot attempts 5,000 records. Data and platform cost allocated to the cohort is £650, implementation cost is £450 and review labour is £900. The workflow returns 4,100 candidate matches, but only 3,400 are unique, pass the identity policy and contain the required sufficiently current field. Total cost is £2,000, so cost per policy-usable unique result is £2,000 ÷ 3,400 = £0.59.

Dividing £650 by 4,100 returned candidates would produce £0.16, but that is not the operational cost of a usable result. It excludes integration and review, counts duplicates and accepts every returned match. Report both the supplier-facing unit cost and the end-to-end decision cost, with denominators visible.

A practical implementation checklist

1. Define entities and actions. Document company, person, employment and channel decisions separately. State which actions can auto-link, auto-write, merge or only propose.
2. Inventory identifiers. Classify fields as stable, contextual, volatile or non-unique. Record where shared domains, generic emails, subsidiaries and recycled channels occur.
3. Preserve raw data. Create versioned normalisation functions and keep original values, source IDs and source-observed dates.
4. Build blocking rules. Use several broad candidate routes, union their pairs and measure which labelled true matches each route contributes.
5. Write deterministic rules. Start with stable IDs, then require multiple independent exact signals. Make exclusions explicit.
6. Score the ambiguous set. Combine fuzzy string comparison with agreement and disagreement evidence. Avoid treating missing as agreement.
7. Label an evaluation sample. Stratify by geography, company size, field completeness and known failure cases. Keep uncertain pairs as an outcome.
8. Choose two thresholds. Set accept and reject thresholds according to false-merge, false-split and review costs for each action.
9. Control writes. Use stable CRM IDs, candidate values, survivorship rules, idempotency keys, write receipts and reversible changes.
10. Monitor drift. Track precision, recall, review rate, unresolved conflicts, duplicates created, API errors, latency and cost per usable unique result by cohort.

Run the first pilot in shadow mode. Produce proposed links and writes without changing CRM records. Ask reviewers to inspect a risk-weighted sample, including automatic accepts near the threshold and apparent non-matches with strong partial evidence. Only enable writes after the team can reproduce decisions and reverse them.

Limitations a buyer should keep visible

No matching method proves identity from incomplete external data. Exact identifiers can be wrong or reused, fuzzy methods can confuse similar entities, probabilistic models inherit labelling and population bias, and manual reviewers disagree. Thresholds can drift as data sources, market mix and input quality change.

Vendor match scores are not directly comparable unless inputs, candidate generation, labels and decision definitions are aligned. A provider can have a high returned-record rate and still produce weak usable coverage after duplicates, stale employment, policy exclusions and unresolved conflicts. Test on records you are permitted to process and define success before seeing the results.

Matching also does not establish permission to contact, lawful use, deliverability or accuracy of every enriched field. Email verification reduces a technical uncertainty; it does not guarantee inbox placement. A phone found on a person record may be unverified or misclassified. Company data and personal contact data need separate governance, access and retention decisions.