--- title: "How to deduplicate a CRM" summary: "Export, preview, tier the file, run it, review the abstentions, merge with receipts, measure. The full sequence for deduplicating a CRM account object without making a wrong merge you cannot undo." canonical_url: https://entitybind.com/guides/how-to-deduplicate-a-crm last_updated: 2026-10-12 copy: full --- # How to deduplicate a CRM > Export, preview, tier the file, run it, review the abstentions, merge with receipts, measure. The full sequence for deduplicating a CRM account object without making a wrong merge you cannot undo. Canonical page: https://entitybind.com/guides/how-to-deduplicate-a-crm Last updated: 2026-10-12 For the team that owns a company master and has to defend it. Somewhere in your account object the same customer appears four times, and somebody has asked you to fix it. That is seven steps of work, and the matching is the fourth. Most projects fail at the first — nobody agreed what a duplicate is, so a parent and its subsidiary get welded together — or at the sixth, where a merge is applied as a write with no evidence attached and cannot be explained six months later. Here is the sequence, including the steps that are your job rather than a vendor's. - Reading time: 12 min read - Sections: 8 - Questions answered: 6 - Key takeaways: 7 The same measurement, on your rows: A first file is a few hundred of your own rows with the matches you already have beside them. The numbers in this article come back measured on your data, and we write nothing to your systems. [Start free →](https://app.entitybind.com/app?signup=1) Self-service. Create your workspace online and verify your email to start matching company records. Free starts with 300 credits and no card. Paid monthly plans are available in workspace Billing; VAT is added where applicable. Usage is tracked without automatic overage charges. [Trust and security](https://entitybind.com/trust) A stewardship queue, a CRM after a migration or a merger, a supplier file before a payment run, counterparty onboarding that has to survive an audit. Read the argument here, take the takeaways at the foot into your next vendor conversation, and send us a file when you want the same measurement on your own rows. Playbooks · 2,455 words · every figure carries the population it was measured over By [James Rooney](https://entitybind.com/about), founder of Entity Bind · Last revised 12 October 2026 ## Step zero: decide what a duplicate is, before anything is exported The single most expensive hour in a CRM deduplication project is the one nobody spends. Two account rows can be the same legal entity, the same trading operation under two legal entities, a parent and a subsidiary, two branches of one franchise group, or a company and its dormant name-protection vehicle. Only the first is unambiguously a duplicate. The rest are business decisions, and the answer differs by organisation: a company selling site licences may genuinely want one account per site, and a company selling enterprise agreements may genuinely want one per corporate group. Write the rule down as three lines before you export anything. Which of those five cases merge. Which become a parent-child relationship instead of a merge. Which stay separate and get a note. If you cannot write the three lines, the run will produce a list of candidate pairs that nobody has the authority to action, which is the commonest way these projects quietly stop. The rule also decides what you send. Resolution against a register answers "which registered legal entity is this row". It does not answer "should these two legal entities share an account record", because that is your commercial policy rather than a fact about the world. Nothing in the response answers the second question. Who writes the rule down follows who ships the result. A CRM administrator ships a merge into the system that owns the record, which is what the rest of this playbook is about. An analyst in a warehouse ships a crosswalk and a number somebody will quote in a meeting, so the same five cases reach them with a different deliverable attached: that is [what a data analyst does with company records](https://entitybind.com/guides/data-analyst#what-does-a-data-analyst-do), and it has a playbook of its own. ## Step one: the export, and the columns that actually matter Export the account object with your own record id in the first column and keep it there. Everything downstream joins on it, and a run whose output cannot be joined back to your data is an interesting report rather than a project. The id travels through the pipeline as a client reference and comes back on every row, so the duplicate report names your rows in your identifiers rather than in ours. Then take every column that carries an identifying signal, in roughly this order of value. Take them even where the fill rate is poor: a column populated on eight per cent of rows still decides eight per cent of the file at the cheapest stage there is. The columns worth mapping, strongest first, with what each one buys: - Company registration number or LEI, wherever your CRM holds one — usually a custom field somebody added for invoicing. This is the identifier tier and it resolved 100% (317/317) on the live-adjudicated fixture of 2026-08-29. It decides with no model call and no egress. - Website or domain. The strongest column most CRM exports actually carry: name and website measured 100% (197/197) at zero model spend. Measured separately, at zero model spend, on 197 individually verified company-to-domain pairs. Those companies are large and well known, so this is the tier's behaviour on famous names rather than a register-wide sample. - Billing or shipping postcode. 98.74% (313/317) on the same fixture, and the single most useful column for a file from a low name-uniqueness register. - Country. Weaker than it looks in some registers and stronger than expected in others — 98.42% (312/317) on the GB fixture, because Companies House is 99.53% unique on company names. - Free-text description or notes. Map it into the context field rather than into a name field. It reaches the adjudicator as caller-supplied evidence, ranks candidates rather than filtering them, and is treated as corroboration that can be wrong. - Phone. Weak on its own, and valuable as a contradiction: two records agreeing on a name and disagreeing on both domain and phone are held apart rather than merged. ## Step two: get the free preview and read the tier composition Before any credit is spent, get the preview over the whole file — we run it on the file you send, before anybody quotes. It calls nothing and spends nothing, and it does one useful thing: it tiers every row by the strongest signal left once the text has been cleaned up — case, punctuation, legal suffixes and stray whitespace reduced to a comparable form — and names the populated columns that are unusable, and why. Read the output as a composition, not as a forecast. The preview reports what shape your rows are in; it never predicts a resolution rate, because the rate is a property of the shape and the shape is what it just measured. The interesting rows are the ones that fell a tier: a website column that normalised to nothing because it holds a LinkedIn URL, a registration number column holding a mix of company numbers and VAT fragments, a name column truncated by a middleware field limit. That last one is worth checking before you commit. Truncated names are the weakest measured shape by a long way — 58.10% (61/105) — and 44 of 105 come back as an abstention with a shortlist, which is the correct answer for a name whose missing tokens were the discriminating ones. If your export truncates at fifty characters and your accounts are group subsidiaries whose discriminating tokens are at the end of the name, the fix is a better export rather than a better matcher. ## Step three: size the run from the mix, not from the row count The cost of a run is set by which stage each row stops at. Rows go through seven stages, cheapest first, and stop at the first one that can decide — that sequence is the cascade — so the rule is short enough to do by hand. 1 credit: a decision reached by the deterministic or probabilistic stage. CPU only, no egress. 5 credits: a decision that needed LLM adjudication or agentic research. 0: an abstention, at any stage, including the ones that spent the most getting there. 0: a byte-identical replay. Per tenant, per exact content, and with no expiry. 0: an input that normalised to no identifying signal. There was nothing to answer. So a hundred thousand rows all carrying registration numbers is a hundred thousand credits, and the same file where every row escalates is five hundred thousand. At the Scale rate of $0.032 a credit, the cheapest paid rate we publish, those are roughly $3,196 and $15,980 — a five-fold spread set entirely by your columns. A file that size is past every priced plan's allowance, so Scale quotes it against your volume. This is the reason to map the identifier column even at low fill: every row it decides is a row that does not escalate. The figures above price the credits a run uses; they are not a separate card charge. Paid monthly subscriptions are purchased through Stripe in workspace Billing, with VAT added where applicable. Usage is recorded separately and does not create automatic usage or overage charges. ## Step four: run it, in batches you chose on purpose Batching is a decision, not a loader detail, and it changes the answer. Within one batch, the order of the rows makes no difference: every record is proposed against the store as it stood when the batch began, and the matches found inside the batch are folded together afterwards, so anything linked to anything else — directly, or through a chain of links — lands in one group. Feed the same rows in four different orders and you get an identical grouping. Across batches, the chunking changes the result: the same twenty-four rows produced fifteen entities as one batch and eight entities as twenty-four batches of one. That is a property to choose rather than a defect to work around. Smaller batches collapse more duplicates, because each record is proposed against a store that already contains the previous ones. One large batch buys order-independence within it. Both are real and neither is free, so pick the one that matches what you are doing: a one-off historical clean-up wants the collapse, and a nightly incremental load wants the reproducibility. Batch throughput is a window to plan rather than a rate to assume. Batches run one at a time rather than in a queue, so a three hundred thousand row file is an overnight job you schedule, and a vendor quoting you a records-per-second figure for this workload is quoting a number that does not describe it. ## Step five: review the abstentions before you look at the matches Work this list before you open a single match. A resolver that returns a best guess for every row gives you matches to audit. This one refuses to bind below 0.90 confidence — A match below 0.90 confidence is unrepresentable. The record comes back as an abstention with a ranked shortlist instead. — so the rows it would not call arrive as a separate, typed work list, and that list is where your file's actual problems are described. Each abstention carries a typed cause from a closed vocabulary and, where one exists, the cheapest of your own columns that would make the row decidable. Where nothing we could name would help, it says that rather than inventing a field. Four causes matter operationally and they instruct different actions. Work the queue by cause rather than by row, because the remedies are unrelated: - more_input_needed — the paid stages could not separate the shortlist. Retrying at a greater depth will not change it. Send an identifier, a domain or a postcode; this is a data request, not a retry. - no_identifying_signal — the fields normalised to nothing identifying. No entity minted, no review item queued, nothing billed. This is the one your own export can fix. - depth_capped — you stopped the cascade before it finished, usually because the key or the request pinned a depth. A deeper call may resolve it. - escalation_unavailable — a dependency failed. A retry is genuinely worth trying, which is exactly what the other three do not warrant. ## Step six: merge in your own system, with the receipt attached Nothing is written to your CRM. There is no writeback connector and none is coming — automatic CRM and ERP writeback is explicitly off the roadmap — so what you receive is a proposal and the merge is applied by you, under your change control, in the tool that owns the record. Attach the decision id to every merge you apply. Each decision, including every refusal, persists its feature vector, the top weighted contributions, the thresholds it was judged under, the cited evidence with source URLs, the adjudicating model id and prompt version where one ran, the pipeline version, and a re-run of the score from the stored features. It reopens at a URL. The question somebody asks six months later is not whether you can reproduce the merge but whether you can explain it, and a receipt answers the second one where a similarity score of 0.87 does not. Plan the reversal before you need it. One over-merged record detaches onto a fresh entity in a single transaction, carrying every fact that originated with it and leaving registry and research facts on the source rather than guessing them onto one side. It needs a review-scoped credential, so an ingestion key cannot do it, and it fails closed before any write where the split would not be safe. Ambiguous legacy facts and general multi-member splits refuse rather than guess — which means some over-merges are not automatically reversible, and knowing which before you merge is worth more than knowing after. ## Step seven: measure the right thing afterwards The metric everybody reaches for is the number of duplicates found, and it is the wrong one, because it rewards a matcher for merging aggressively. A run that merges two large customers into one account will score brilliantly on it. Measure four things instead. How many rows were decided automatically, and at which tier — on the continuous-integration gate 63.10% of pairs were decided automatically, and 742 of 1,176 pairs were decided automatically in the September 5 saved gate report. This measures automation, separately from accepted-merge precision. How many merges you applied and how many you rejected on review, which is the only precision signal you will have on your own data. How many abstentions were fixable from your own columns, because that number is your data quality backlog priced. And whether the totals reconcile: every input row should land in exactly one ledger, and the distinct source references should equal the rows in. The one thing not to measure is a count of dangerous merges prevented. We do not promise a count of dangerous merges prevented, and you should distrust anyone who does before they have seen your file. Zero is a normal, honest result: two rows carrying contradicting company numbers are refused outright and never reach the guard that would have counted them. ## What to take away - Decide what a duplicate is before you export. A parent and its subsidiary are not a duplicate unless your commercial policy says so, and no resolver can answer that question for you. - Keep your own record id in the first column and map every identifying column even at low fill — the identifier tier resolved 100% (317/317) and costs one credit with no model call. - Get the free preview first. We run it on your file; it tiers your rows, names the unusable columns, spends nothing, and never predicts a resolution rate. - Cost follows the tier mix rather than the row count: the same hundred thousand rows range across a five-fold spread depending on which stage each row stops at. - Batching changes the result across batches and not within one. Smaller batches collapse more duplicates; one batch buys order-independence. - Read the abstentions before the matches. They arrive with a typed cause and the column that would settle them, and the four causes instruct four different actions. - Merge in your own system with the decision id attached, and know which over-merges are reversible before you make them. Those takeaways hold for anybody's data. The number for yours comes out of your own rows — a few hundred of them, with the matches you already have beside them. [Start free →](https://app.entitybind.com/app?signup=1) ## Read next Each article names its own further reading. These pick up a question this one raises and leaves open. - [What is entity resolution?](https://entitybind.com/guides/what-is-entity-resolution) (9 min read): Entity resolution decides which records refer to the same real-world thing. What it is, why company identity is hard, deterministic versus probabilistic matching, and why fuzzy matching is not entity resolution. - [Survivorship and golden records](https://entitybind.com/guides/survivorship-and-golden-records) (10 min read): Merging records is only half the job. Field-level survivorship, source precedence, temporal facts, per-field provenance, and why last-confirmed beats first-seen. - [Precision, recall and abstention](https://entitybind.com/guides/precision-recall-and-abstention) (8 min read): Entity resolution is a three-way trade, not a two-way one. Why abstention is a design choice rather than a failure, what an abstention has to carry to be useful, and how to measure a system that declines. - [How to deduplicate a supplier master](https://entitybind.com/guides/how-to-deduplicate-a-supplier-master) (12 min read): Duplicate vendors, payment leakage, remittance conflicts and parent concentration. The accounts payable playbook for finding which vendor records are one company, with a citation for every finding. Or try your own rows: create your Free workspace and upload a company CSV to inspect its results. Contact us for an assisted measurement against your labelled data, with the working handed back. [Start free →](https://app.entitybind.com/app?signup=1) ## Where this article is applied 4 pages name this method as the working behind what they claim. - [Audit company overlap before a CRM migration](https://entitybind.com/use-cases/post-merger-company-data-audit) (Use case): Review duplicate companies across both exports while every source ID is still intact. - [CRM and RevOps](https://entitybind.com/use-cases/crm-and-revops) (Use case): Which accounts are one company, which merges to refuse, and a receipt for both. - [Entity Bind vs Enrichment vendors](https://entitybind.com/compare/zoominfo-and-clearbit) (Comparison): A different product, not a competitor. They sell contacts and firmographics; we resolve identity. - [Salesforce](https://entitybind.com/integrations/salesforce) (Integration): An integration pattern, not a managed package: a named credential, a callout that resolves an account, and fields for the receipt. Nothing is written back. ## Is this your file? The article is for anyone. The measurement behind it is worth commissioning for one kind of team. ### Built for Teams with a company master they have to defend — an MDM or stewardship queue, a CRM after a migration or a merger, a supplier file before a payment run, or counterparty onboarding that has to survive an audit. ### Wrong for Buying breadth as the product: we hold a fraction of an incumbent’s records and are not building a global company graph. Entity Bind resolves companies and organisations only. It does not resolve people, vessels, bank-account ownership, sanctions exposure, emissions or geolocation, and its results may not be used for eligibility decisions about individuals, including employment, credit and tenancy. ## The basis for every figure above Internal fixtures only. The historical 2026-08-29 per-tier recording covers 317 GB companies with identifier-rich arrivals seeding the catalogue first; the context tier includes country and registered-town prose. Its legacy replay has no full-prompt-verified calls and cannot certify current calibration. The September 5 CI reports cover 1,176 labelled pairs and 705 records over 250 companies using offline stubs. These are not independent customer holdouts or live production validation; the 99% minimum-input product target remains unmet. Scope is company and organisation identity only — not people, vessels, bank-account ownership, sanctions or emissions. Results may not be used for eligibility decisions about individuals, including employment, credit and tenancy. Figures read off the product repository on 2026-09-05. The per-tier rates come from the live-adjudicated 317-company recording of 2026-08-29; the gate figures come from the stub-adjudicated continuous-integration run and are a floor rather than a ceiling. The two are never averaged. Entity Bind holds no SOC 2, no ISO 27001 and no other certification, and claims none. Every figure, with the population it was measured over and the method behind both recordings, is set out on [the accuracy page](https://entitybind.com/accuracy). The retention, erasure, tenancy and sub-processor detail a security review asks for is under [Trust and security](https://entitybind.com/trust), with where assurance stands: no external validation of the accuracy figures and no customer holdout. ## The same measurement, on your own rows. Create your workspace, verify your email and run your first company file. The Free plan needs no card. Create API keys in your workspace when you need an integration. [Start free](https://app.entitybind.com/app?signup=1) · [Plans and prices](https://entitybind.com/pricing) 300 credits. No card. For a guided review of your file, explore [the Merge Safety Sprint](https://entitybind.com/audit-pack). ## The questions this article answers ### Will you write the merges back into our CRM? No. Automatic CRM and ERP writeback is explicitly off the roadmap rather than a gap on the way to being closed. We propose the clusters in your own record ids, with a receipt per decision, and you apply them under your own change control in the system that owns the record. A tool that writes irreversible merges into a production CRM on the strength of its own confidence is one whose failures you hear about from a customer. ### How many duplicates will we find? Nobody can tell you that before seeing the file, and a vendor who quotes a percentage is quoting a number from someone else's data. What the free preview will tell you before you spend anything is the shape of your file — which rows carry an identifier, which carry a domain or postcode, which carry a name that has been truncated. That composition sets both what a run costs and what it can decide, and it is checkable in an afternoon. We do not promise a count of dangerous merges prevented, and you should distrust anyone who does before they have seen your file. Zero is a normal, honest result: two rows carrying contradicting company numbers are refused outright and never reach the guard that would have counted them. ### What if our account names are truncated? Then a lot of the file will come back as shortlists rather than matches, and the number is published so you can judge before you spend. Truncated names resolved 58.10% (61/105) on the representative fixture, with the remainder returning a ranked shortlist and the column that would settle it. If the export also carries a website, a postcode or a registration number, map it and the same rows resolve on a much stronger tier — which is usually a change to the export rather than a change to the matcher. ### Can we set the confidence threshold ourselves? You can be stricter than us and you cannot be looser. 0.90 is a floor the code cannot represent a match below — it is built into the resolution outcome itself as a domain invariant — and it is checked again by a guard called on the online, batch and replay paths, so a sub-floor accepted match cannot be constructed anywhere. Before adding a stricter filter, measure its coverage cost on your own labelled records. Confidence bounds depend on the recorded evidence population; there is no universal score for every match. Read match_confidence_basis and the evidence. A 0.99 filter can return some v8 adjudicated matches while excluding valid identifier matches, so validate its coverage cost on your own inputs. ### How long does a large file take? Plan it as a window rather than a rate. Batches run one at a time rather than through a queue, so a three hundred thousand row file is an overnight job to schedule. The variable that moves the wall-clock time is not the row count but the share of rows that escalate to adjudication or research, which is exactly what the preview tells you in advance. ### What does the output look like? A duplicate report grouping your rows by the entity they landed on, labelled with your own key values; a list of merges the guard refused, with the attributes that disagreed named; an abstention list with a typed cause and the field that would settle each row; and a decision id per decision, including every refusal, that reopens the full evidence trail at a URL. --- The 0.90 confidence floor. It is an acceptance contract, not calibration evidence: it says what we refuse to return, not how often an accepted match is right. Read it with the coverage it costs. Historical results on an internal UK fixture with a preloaded catalogue. The September 5 replay has no full-prompt-verified calls and cannot establish current calibration. No independent customer holdout or global coverage claim. This is the Markdown copy of https://entitybind.com/guides/how-to-deduplicate-a-crm, assembled from the same data the page renders and carrying every sentence, table row, figure and question the page's main content carries. The HTML page is canonical; it adds the layout, the navigation and the interactive parts (the ask panel, the forms), which a copy can name but not run. Every page on the site, with a line on each: https://entitybind.com/llms.txt.