Definition
Record matching is the process of identifying records across different datasets that refer to the same real-world entity. One system has "IBM," another has "International Business Machines Corp," a third has "I.B.M." three rows describe one company. Record matching is the logic that recognizes them as one.
The same problem shows up with people. "Bob Smith, VP Sales, Acme" in your CRM and "Robert Smith, Vice President of Sales, Acme Corp" on a purchased list are almost certainly the same person. A human sees that instantly. A database join on exact values sees two strangers.
Record matching sits underneath most data quality work. Deduplication, CRM migrations, list appends, and entity resolution all depend on deciding, pair by pair, whether two records describe the same thing.
How Does Record Matching Work?
Each serious matching process runs through the same stages, whether it's a Python script or an MDM platform that costs more than your sales team.
- Normalization. Strip punctuation, lowercase consistently, expand or remove abbreviations, standardize entity suffixes such as Inc, LLC, and Ltd, and format phone numbers to one convention. Review the resulting candidate pairs before merging.
- Blocking. A full cross-file comparison grows with the product of the two row counts. Blocking narrows the field by comparing only records that share a cheap key, such as a domain or the opening characters of a company name.
- Comparison. Within each block, candidate pairs get compared field by field. Exact equality for domains and emails, string-distance algorithms like Jaro-Winkler or Levenshtein for names, token overlap for addresses.
- Scoring and decision. Field-level comparisons roll up into a match score. Above one threshold, the pair is an automatic match. Below another, automatic non-match. The band in between goes to review.
- Survivorship. Once two records are declared a match, something has to decide which values win. Newest title, most complete address, the email that passed validation. This is where merges go wrong when nobody defines the rules.
That middle band matters more than teams expect. The remaining few thousand are the two John Smiths at one company, the franchise locations sharing a brand name, the contact who changed jobs mid-quarter. Those need a person.
Deterministic vs. Probabilistic Matching
Deterministic matching says two records match only when key fields agree exactly, usually after normalization. Probabilistic (or fuzzy) matching scores similarity and accepts pairs above a threshold. Neither is better in the abstract. They trade different errors.
| Deterministic | Probabilistic |
|---|---|
| Match requires exact agreement on key fields | Match requires a similarity score above a threshold |
| few false positives | Catches nicknames, typos, and abbreviations that exact keys miss |
| Misses "Jim" vs. "James" and "Acme Corp" vs. "ACME Corporation" | Will occasionally merge two records that shouldn't be merged |
| Cheap to run, easy to explain | Needs tuning, thresholds, and review of borderline pairs |
| Suitable when you have a reliable unique key such as email or domain | Necessary when names and free-text fields are you have |
In practice you run both. Deterministic passes first on the reliable keys, which clears most of the file at near-zero risk. Then fuzzy matching on what's left. Running fuzzy logic on records an exact key would have settled just adds noise and review time.
Which Match Keys Work Best for B2B Data?
Corporate email is the strongest single key for person records. It's unique, it encodes the employer in the domain, and it rarely collides. When it's missing or personal (gmail.com tells you nothing about employer), fall back to name plus company, and expect to do more fuzzy work.
For company records, website domain is usually a stronger key than company name. Names carry entity suffixes, DBAs, abbreviations, and rebrands. Use domains as one signal, follow redirects, and send ambiguous parent or subsidiary matches to review. Phone numbers work better as supporting evidence than as a sole key because switchboards can repeat.
Some industries get luckier. Healthcare has NPI numbers, finance has LEI codes, and matching on those is trivial compared to matching on strings. If your data has a registry identifier available, capture it. Every downstream matched share improves.
What Happens Without It?
A company acquires a competitor and merges two Salesforce orgs on exact account names. "Acme Corp" and "ACME Corporation" both survive. So do a few thousand similar pairs. Six months later, reps are logging activity on different versions of the same account, one account owner is calling a customer the other owner just discounted, and the pipeline report double-counts every duplicated opportunity.
The failure isn't dramatic on day one. It compounds. Duplicate accounts split activity history, which breaks lead routing, which erodes rep trust in the CRM, which leads to reps keeping their real notes in spreadsheets. Measure change against a dated baseline instead of applying a general decay benchmark, then set the review cadence from the changes observed in your own system.
Common Mistakes
- Matching on raw values. Skipping normalization and then concluding the datasets "don't overlap." They overlap. The formatting differs.
- Trusting one source. No single vendor gets everything right. Measure change against a dated baseline instead of applying a general decay benchmark, then set the review cadence from the changes observed in your own system.
- Auto-merging the gray zone. Automated scoring handles clear matches and clear non-matches. Forcing a yes/no on the ambiguous middle band, without review, is how two distinct customers end up as one corrupted record. Un-merging is far more painful than reviewing.
- Treating it as a one-time project. People change jobs, companies rebrand, phone numbers get reassigned. A file matched a year ago has drifted. Periodic re-matching keeps the work from going stale.
Frequently Asked Questions
What is record matching?
Record matching is the process of identifying records across different datasets that refer to the same real-world entity. Two rows might show "IBM" and "International Business Machines Corp," or "Bob Smith" and "Robert Smith" at the same company. Matching logic recognizes both pairs as one company and one person.
What is the difference between record matching and deduplication?
Deduplication is record matching applied within a single dataset, usually followed by merging the duplicates. Record matching is the broader capability: it also links records across separate systems, like matching a purchased contact list against your CRM, where nothing gets merged or deleted.
What is the difference between deterministic and probabilistic matching?
Deterministic matching requires fields to agree exactly, or after normalization, so it can miss variants such as nicknames and abbreviations. Probabilistic matching scores similarity across several fields and sends candidates above defined thresholds to accept or review queues. Measure false positives and false negatives on labeled samples from each path.
What is a good matched share for B2B data?
It depends on the join key and the quality of the source fields. For name-only matching, ask a vendor to report both coverage and accuracy on a labeled sample rather than relying on a headline match-rate claim.
Why do CRM merges produce duplicate accounts?
Because the migration tool matched on exact field values and the two systems formatted those values differently. "Acme Corp" and "ACME Corporation" don't collide on an exact key, so both survive the merge as separate accounts. Normalizing names, domains, and phone numbers before the merge prevents most of it.
How does Verum handle record matching?
The written scope defines deterministic and fuzzy match rules, candidate evidence, exception review, field survivorship, delivery format, and schedule for the submitted file.
Related Terms
Related: All Glossary Terms | CRM Hygiene | Cleaning Services