Duplicate account merge rules decide what your CRM keeps and what it destroys when two records for the same company collapse into one. Finding duplicates is the easy half. The rules that govern the merge itself determine whether you end up with a cleaner database or a quiet hole in your revenue history.
The three decisions in every merge
Every merge resolves three separate questions, and teams usually think about only the first.
- Which record survives and keeps its ID, so that integrations, reports, and external references pointing at the loser break or redirect. - Which value wins for each field where the two records disagree. - Where the child records go, including contacts, opportunities, cases, and logged activity.
Field survivorship rules
Field-level survivorship should follow the field's purpose rather than a blanket "keep the master" setting.
| Field type | Rule | Reason |
|---|---|---|
| Corporate domain | Keep the verified value | Domain is the join key for enrichment and matching |
| Owner | Keep the owner of the record with open pipeline | Prevents reassigning a live deal mid-cycle |
| Firmographics | Keep the most recently enriched value | Employee count and revenue change constantly |
| Original source | Keep the earliest value | Attribution reporting depends on first touch |
| Free-text notes | Concatenate both | Nothing else recovers the lost context |
Protect the child records
The expensive failure is losing attached history. A merge that drops closed-won opportunities changes historical win rate by segment, shrinks the account's contract history, and corrupts the baseline that forecasting models train on. Before a batch merge, export both record sets in full, run ten merges by hand, and confirm the child counts on the surviving record equal the combined counts from before.
Contacts need their own check. Two account records usually carry overlapping contacts, so an account merge leaves duplicate contacts on the surviving account that then need their own pass.
Set a confidence split
Automate the merges you can prove and queue the rest. Exact corporate domain matches are safe to merge without review. Everything resolved by name similarity goes to a human, because parent companies, subsidiaries, and regional entities look like duplicates to a matching algorithm while operating as distinct accounts with distinct contracts.
Merge volume is also a signal worth tracking. A rising duplicate record rate means prevention at the point of entry is failing, and merging faster only clears the backlog while the intake process keeps refilling it. Fix intake first, then clear the existing set, and watch for duplicate opportunities surfacing on the merged account, since two records for one company frequently means the same deal was entered twice and counted twice in coverage.
Frequently Asked Questions
Which record should survive when you merge two duplicate accounts?
The record with the most attached history, meaning the one carrying the closed-won opportunities and the longest activity trail. Age and creation date are poor tiebreakers because the older record is often the abandoned one. Pick the surviving record by attached history, then pull the better field values in from the loser.
What happens to opportunities on the losing account record?
They reparent to the surviving account in most CRMs, which is the behavior you want. Verify it before running a batch, because a merge that deletes child opportunities removes closed-won revenue from your history and changes every segment report that reads it.
Can you undo a CRM account merge?
Not cleanly. Most platforms soft-delete the losing record for a limited window and restore it without its reparented children. Treat every merge as permanent, export the full field set of both records first, and run merges in small reviewed batches rather than one bulk job.
Should merges be automatic or reviewed by a person?
Split by confidence. Exact matches on corporate domain can merge automatically. Name-similarity matches go to a review queue, because subsidiaries, franchises, and regional entities look like duplicates and are separate buying centers with separate contracts.
Put these metrics to work
ORM builds custom revenue forecast models that turn concepts like duplicate account merge rules into prescriptive action for your team.
Schedule a Demo