The Company Record Match Rubric: Merge, Link, or Keep Separate

Deciding whether two company records refer to the same account is the single hardest call in company data, and it is one you make dozens of times before every merge, link, or dedup run. This guide is for revenue operations, recruiting operations, and anyone answerable in a data-governance review for how records were combined. It gives you a scoring rubric: a fixed set of signals, named thresholds, and a documented reason you can defend, so a gut merge becomes a repeatable score another operator would reproduce.

The trap this guide covers that others skip is corporate structure. Two subsidiaries under one parent domain will score a perfect domain match. A brand two levels below a holding company shares nothing obvious with its owner. A name-only or domain-only rule quietly gets both wrong. The rubric here resolves those cases by never letting one field carry the whole decision.

The signals that decide whether two company records match

The identity of a company record is proven by corroboration across independent fields, not by any single strong-looking field. Practitioners compare a fixed set: normalized company name, primary web domain, email domain, headquarters country or region, and the brand-versus-parent-versus-subsidiary relationship.

Each signal proves something different, and each has a way it lies. Knowing the failure mode of a signal is what separates a defensible score from a lucky one.

Name is the noisiest field, and it is the one operators lean on most. Legal designations such as Inc., LLC, Ltd., GmbH, and Pty Ltd are legal metadata, not identity, so they should be removed from the canonical name before you compare. Order matters: remove punctuation and special characters first, then legal suffixes, then stop words such as Company, Services, and Group.

But normalization does not prove two companies are the same. It only makes the name easier to compare. Payfit's much-cited result, cutting CRM duplicate companies from 30 percent to 9 percent through name standardization, only worked because the clean names then fed domain and address matching. Normalization is the setup, not the decision.

The threshold bands: auto-merge, review, keep separate

Route every scored pair into one of three bands, because the cost of a wrong merge is not the cost of a missed duplicate. There is no universal number, but the banded pattern is consistent across published guidance, and the gap between the bands is a risk policy, not a statistical constant.

The asymmetry drives the design. A wrong merge is much harder to undo than a missed duplicate, which is why auto-merge sits at 99 to 100 percent while human review starts near 80 to 85 percent. Published guidance recommends tightening the review start to 80 to 85 percent as a default, so a pair must clear a closer overall match before it is surfaced at all. For automated merging with no manual review, 99 to 100 percent is the recommended floor, because you only want machines to merge when very confident.

One caution on the bands: a single global threshold is a blunt instrument. The cleanest dedup programmes use a ranked model with multiple match paths instead of one rule, so each path reflects both confidence and business risk. A pair matching on identical domain plus country can clear at a lower composite than a pair matching on name alone, because the fields carrying the score are more trustworthy.

Same entity or same corporate family: merge versus link

When two records point to the same real-world business but are distinct legal entities, the documented answer is to link them with a hierarchy, not merge them. This is the call that dedup tours skip, and getting it wrong costs you revenue reporting.

The parent account typically represents a corporate headquarters or holding company, while child accounts represent subsidiaries, regional offices, or business units that roll up to that parent. Every account record can reference another account record as its parent, and that relationship creates a hierarchy surfaced through an account hierarchy view. Salesforce, for example, uses an 80-character Account Site text field to tag a record as a branch versus HQ.

Merging distinct legal entities destroys the structure that routing, territory assignment, and roll-up reporting depend on. Hierarchy roll-up reporting aggregates pipeline and revenue from children up to the parent. Collapse the tree and you lose subsidiary-level whitespace and territory attribution. So the sequence is: confirm identity first, then ask whether the match is the same legal entity or the same family. Same legal entity merges. Same family links.

Merge collapses the tree that routing and roll-up reporting read; link when the entities are distinct.

This is where a search tool earns its place, because you often need to establish the corporate-family relationship from public evidence before you can decide. If you cannot tell from your own records whether a record is a subsidiary, a regional office, or an independent firm, you resolve it against the open web.

Once identity is confirmed, the last question is which values survive. Survivorship is set per attribute, not per record. The four dominant rules: source trust prioritises the value from the most reliable system, recency takes the most recently updated value, frequency keeps the value appearing most consistently, and completeness favours the record with the most fully populated fields. Preserve, do not overwrite, compliance and history: keep the most recent value for titles and phone numbers, retain the most complete mailing address, preserve Do Not Contact flags and opt-outs without fail, and union lists like SKUs, seats, or tags.

The procedure: from two records to a logged decision

Run the pair through eight steps, deferring the riskiest judgement to a human at the end. Each phase shrinks or resolves the candidate pool before the next, more expensive phase.

One note on order. Some frameworks frame the run as three sequential phases where each phase shrinks the candidate pool before the next more expensive phase and defers the riskiest calls to the end. Others make the backup export step one, so nothing runs until the safety net exists. Both are defensible. If your CRM has no undo, put the export first regardless.

How this goes wrong: failure modes and false positives

Most bad merges come from a small set of predictable traps, and each has a tell and a check. This is the part of the rubric that saves you in a governance review, because it names what to look for before you commit.

The shared-domain trap is the most common false positive in company data and the reason a domain-only rule is unsafe. Block any pair from auto-merge when it matches on similar name only, shared company only, or when it has conflicting high-trust identifiers. M&A activity is the most common cause of stale hierarchies, since subsidiaries get acquired or rebranded faster than admins can update parent fields by hand; the Salesforce acquisition of Slack in 2021 is a documented example of a trigger that leaves hierarchies stale. Re-enrich ownership on a schedule rather than trusting a parent field indefinitely.

Two failure modes are about what happens after the match, not the match itself. Survivorship can overwrite validated data when a low-confidence value clobbers an enriched field, so align survivorship weight with your enrichment hierarchy and let preferred-provider fields win. And consent can vanish silently: a merged record looks complete while a Do Not Contact flag from one side was dropped. Treat consent and opt-out flags as always-preserve, unioned across both records, never subject to source-priority.

Reversibility is the real constraint, not accuracy

The defensible merge is defined by its snapshot and log, not by its score, because most CRMs have no platform-level undo. This is the point governance frameworks converge on, and it is why the strongest documented survivorship rule sets come out of regulated industries.

There is no platform-level undo in a typical CRM merge, so the backup export is the only safety net, which is why governed dedup programmes treat the export as mandatory. Before any commit, store a pre-merge snapshot and a reversible mapping from old IDs to the new survivor ID, and document who approved each merge along with the business or model rationale. A common rollback window for sensitive merges is 30 to 90 days.

The audit entry has to permit reconstruction of both the decision and the decision context: which fields matched, at what score, on what reason, by which reviewer. That is what another operator reads in a review to confirm you would both have reached the same verdict.

In Refolk's index, the operators who own this policy cluster in specific roles and places. Data steward and MDM title holders in the US number 724, and they concentrate at JPMorgan Chase, Siemens, Citi, and UnitedHealth Group. That clustering is not incidental: regulated firms enforce survivorship and audit trails, which is why the most rigorous documented rule sets trace back to regulated-industry master data management.

Who owns this decision, and where they sit

The population that owns company-merge policy is concentrated, and knowing where it sits tells you where the standards come from and who to recruit as a reviewer. In Refolk's index, the market for this judgement is roughly six times larger in the US than the UK.

Revenue operations owns the merge rubric in most companies, but the governance discipline sits with data stewards. The two roles are not the same size, and the gap matters when you staff a dedup programme.

There are roughly twice as many RevOps title holders as data stewards in the US index, and the two populations overlap only partly. RevOps tends to own the routing and reporting consequences of a merge; stewards own the survivorship and audit rigour. When you need a second reviewer for a hard pair, pull from the steward pool, because they carry the reversibility discipline by default. When you need to find people who have run a specific dedup project, Refolk lets you ask for them in plain English across public professional records rather than guessing at title strings.

Ship a defensible run: the pre-commit checklist

Before you commit any merge, verify the run against a fixed checklist, because the merge is only as defensible as the artefacts it leaves behind. Run this once per batch, or once per sensitive pair.

To keep the rubric current, treat two things as scheduled work rather than one-time setup. First, re-enrich ownership from filings and news, because M&A drift stales your hierarchies faster than manual updates can keep pace. Second, sample the review queue periodically: if it fills with obvious non-matches, your lower threshold has drifted too low and needs raising. The template below is the audit entry that makes any single decision reconstructable.

decision: merge | link | keep-separate
survivor_id: <winning record ID>
absorbed_id: <old record ID, retained in snapshot>
matched_fields: name, domain, hq_country
composite_score: <0.00 to 1.00>
band: auto-merge | review | keep-separate
reason: <what agreed and what conflicted, one line>
entity_basis: same legal entity | same corporate family
reviewer: <name or system>
snapshot_ref: <export or backup location>
rollback_by: <date, 30 to 90 days out>

Score the pair, route it by band, resolve the entity-versus-family question, preserve consent and history in survivorship, and leave a snapshot and a log behind. Do that and any merge you make is one another operator would make the same way, and one you can defend when someone asks how the data was gathered.