CRM and RevOps
Which accounts are one company, which merges to refuse, and a receipt for both.
A migration, a merger, or the quarter somebody finally counts how many rows in the account object are the same company.
Send the export. What comes back is which of your rows are the same company, in terms of your own record ids, plus the merges we refused and the rows we would not call — each of those carrying the one field that would have settled it. Nothing is written to your CRM, at any point.
Two pages carry what this one only points at: where assurance stands, and every figure with the population it was measured over.
trust and security →every figure, with its population →On this page
RevOps and sales operations leads, CRM administrators, Salesforce and HubSpot migration agencies, and private equity operating teams merging two go-to-market systems.
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.
How it actually goes wrong
What causes it, what it costs when nobody notices, and the part of it a resolver can reach.
Every CRM accumulates duplicate accounts, and none of the ways it happens are anybody's fault. A rep types a name that already exists in a slightly different form. A list import lands under a trading name. Self-serve signup creates an account for a subsidiary. An acquisition brings in twelve thousand rows that overlap yours by an unknown amount. The result is not a tidiness problem — it is two account teams discovering each other mid-deal, pipeline double-counted at board level, a renewal quoted to a subsidiary of an existing customer at the wrong discount, and a territory dispute that takes a director to settle.
The native dedupe tools make it worse in a specific way. They score on string similarity, they present a confidence that is a statement about two strings rather than about how often decisions like this one have been right, and the merge they perform is a write with no evidence attached. Six months later, when somebody asks why these two accounts became one, the answer is that a rule scored 0.87 and somebody clicked. And they merge the wrong things as readily as the right ones: two branches of a franchise group, a parent and its subsidiary, or two genuinely different companies whose names differ by a word the matcher was configured to ignore.
The migration moment concentrates all of it. Two systems have to become one, the overlap has to be decided under time pressure by people who did not create either dataset, and the decision is irreversible in the target. That is the point at which somebody usually buys a matching tool, runs it, and discovers that the interesting output is not the matches — it is the rows the tool was not sure about, which it has silently merged anyway.
If that reads like your week, create your Free workspace and upload a company CSV to see which rows match and which need review. Contact us separately if you want a guided first file.
Start freeWhat we do about it
Each of these runs today. Where one needs a column you might not have, or fails in a particular way, the sentence says so.
- 01
Clusters in your ids, not ours
Your key column travels through the pipeline as a client reference and is echoed back on every row, so the output joins to your data on your identifiers. The duplicate report groups resolved rows by the entity they landed on and labels members by your own key values: these six of your rows are one company, stated in the ids your CRM already uses. - 02
A guard that refuses the merge
A merge is blocked outright on one disagreeing strong identifier — a company number, an LEI — or on two or more disagreeing weak signals such as a domain and a phone number together. One weak contradiction is noise; several agreeing that these are different companies is evidence. An agreeing strong identifier short-circuits the weak check, which is how the company that relocated and changed every contact detail still resolves. - 03
Abstentions as a work list
The rows we will not call come back with a typed cause from a closed vocabulary and the cheapest of your own columns that would make each one decidable — and where nothing we could name would help, it says that rather than inventing a field. Two of the eight causes are ours rather than yours. That is a work list your operations team can price, not a coverage shortfall to argue about. - 04
A receipt per decision
Every merge, and every refusal, persists its feature vector, the thresholds it was judged under, the cited evidence, the adjudicating model and prompt version where one ran, and a re-run of the score from the stored features. It reopens at a URL. The question six months later is not "can you reproduce this" but "can you explain it", and a receipt answers the second one. - 05
Reversible when we are wrong
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 requires a review-scoped credential, so an ingestion key cannot do it, and it fails closed before any write if the split would not be safe.
Which of these is your export?
One export usually sits in three of these at once. Your rate is set by the columns still standing once the names have been stripped back to a comparable form.
Account name plus website or domain
The strongest shape most CRM exports carry, and the one worth mapping first. Domain agreement is a decisive digital signal and the row usually decides without a model call.
Measured100% (197/197). 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.
Account name plus a billing or shipping postcode
Resolves well and cheaply. A postcode is a qualifying signal, so these rows go the normal route rather than returning a shortlist.
Measured98.74% (313/317) on the representative GB fixture.
A company name, GB, and a sentence naming the registered town
Map the free-text column into `context` and it reaches the adjudicator as caller-supplied evidence rather than as an identifying field. The historical measurement used country and prose naming a registered town; it does not establish general description-only coverage.
Measured99.37% (315/317), 95% CI [97.7, 99.8]. Historical 2026-08-29 recording with earlier identifier arrivals seeding the catalogue. This does not measure a business description, email footer or generic verification purpose alone. Two same-stem groups remained unresolved. Separately, in the historical 50-record wrong-town fixture, 72% resolved and zero wrong bindings were observed. This is a measured adversarial sample, not a guarantee for every misleading description.
A name truncated by a field-length limit
The weakest shape and a common one in older CRMs and in exports through middleware. The missing tokens are usually the discriminating ones, so most of these come back as an abstention with a shortlist rather than a guess.
Measured58.10% (61/105). 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.
Account name and nothing else
Abstains at the probabilistic stage and returns the top five candidates plus the column that would decide it, so the tier that cannot be answered is not the tier that costs the most. The claim is about the shortlist rather than the winner, and no row of it may be treated as a match.
MeasuredThe true company ranked first for 151/205 (74%) and appeared in the top three for 205/205 (100%), on the gated acquisition fixture. Recall is a property of the list, not of the winner. 74% is far below the 0.90 acceptance floor, so no row of that shortlist may be offered as a match, quoted as an accuracy number, or folded into an accepted-match count.
- Name and website — A company name and its domain
- 100% 197/197Measured 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.
- Truncated name — A name whose ending has been cut off by a field-length limit
- 58.10% 61/10544 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.
Zero wrong bindings were observed across the historical six-shape recording and the separate domain fixture. Observed correctness was 1.0000 on accepted outcomes; this does not guarantee an error-free new workload.
317 live GB companies sampled from the 2026-08-01 Companies House snapshot, with same-name siblings included. Identifier-rich arrivals seed the catalogue before the weaker input shapes are evaluated. 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. The whole table, including the shapes this page does not use, with the safety results and an account of what none of it demonstrates.
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.
Not sure which of these your export is? Create your Free workspace and inspect your own CSV columns. For an assisted composition preview, contact us with the file: we tier each row by its strongest surviving signal before quoting a Sprint.
Start freeEight rows out of a CRM export
One pass, in order, including the rows that do not resolve. The interesting rows are always the ones at the end.
Three spellings of Monzo sharing one company number, two Revolut rows, one Starling row, one consultancy carrying nothing but a name, and one row whose name is a placeholder and nothing else.
- 01Normalisation strips legal forms and punctuation, and canonicalises the company number to its full eight characters. The placeholder row normalises to nothing comparable and stops there.
- 02Rather than compare every row against every company, the pipeline shortlists candidates on the rarest tokens in each name — rarity-weighted blocking — for the six rows that carry a usable signal.
- 03The three Monzo rows agree on a company number checked for register shape rather than string equality, so a deterministic identifier rule decides them without a model call.
- 04The two Revolut rows and the Starling row decide on scoring.
- 05The name-only consultancy abstains with a five-candidate shortlist and a prescription naming the column that would settle it.
- 06The placeholder row returns `no_identifying_signal`: no entity minted, no fingerprint bound, no review item queued, nothing to bill for.
Four entities, two duplicate clusters, and an audit pack that reconciles one input row at a time — every row lands in exactly one ledger, and the ledgers add back to the file you sent. No newly minted entity appears anywhere in the accepted-matches ledger, every accepted confidence sits at or above the floor, and every packaged receipt equals the live decision it was drawn from.
The interesting rows are the last two rather than the first three. A resolver that returned an answer for the name-only consultancy would be guessing, and a resolver that returned an answer for the placeholder row would be inventing. The three Monzo rows are the easy case, and the easy case is what a demonstration gets built from.
That example is ours. The one worth having is the same walk-through on eight rows of yours.
Start freePrefer to put it to a person? Talk to us instead →
What this will not do
Each of these is a decision we intend to keep. Read them before you scope the work.
- We do not write to your CRM, and there is no writeback connector coming. Automatic CRM and ERP writeback is explicitly off the roadmap: we propose actions and you apply them under your own change control.
- We do not deduplicate contacts, leads or people. Scope is company and organisation identity, and a duplicate-person problem needs a different vendor.
- We do not decide which of your two records should survive as the master. Which field value wins when two of your own records disagree — survivorship — is a policy about your fields and your systems; ours is about which real-world company the rows point at.
- A zero in the blocked-merge ledger is normal and is not a safety claim. 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.
- The audit pack we ship today is version zero and says so in every row of every file it contains. It has no incumbent comparison ledger, no counterfactual sensitivity analysis and no rollback manifest; those are declared absent with a reason rather than shipped empty.
- Correction is a single-record detach, not a general unmerge. There is no arbitrary cluster split, no rollback to a historical cluster shape and no automatic reattach.
We will not tell you how many dangerous merges we will find
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 this product does not have — no SOC 2, no external validation of the accuracy figures, no customer holdout — is published in full, with the retention, erasure and tenancy detail a security review asks for. Read the trust page →
Check these scope limits before integrating. Free signup lets you inspect your own company CSV; if a requirement falls outside the published scope, contact us and we will tell you whether it is supported.
Start freeThe method behind this, at length
3 articles that carry the working this page summarises.
- GuideHow to deduplicate a CRMExport, 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.
- GuideSurvivorship and golden recordsMerging records is only half the job. Field-level survivorship, source precedence, temporal facts, per-field provenance, and why last-confirmed beats first-seen.
- GuidePrecision, recall and abstentionEntity 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.
The same pipeline, in other people's words
One product, described 6 other ways. If your team has a different vocabulary for the same file, start from the page that speaks it.
Audit company overlap before a CRM migration
Review duplicate companies across both exports while every source ID is still intact.
Master data management
An independent admission policy beside the platform you already run.
Supplier master and accounts payable
Duplicate vendors, remittance conflicts and concentration you cannot see.
KYC and onboarding
Counterparty identity with a receipt that survives seven years.
Reference data
Every identifier a company is known by, each separately cited — and the ones nobody holds.
AI agents
A counterparty check before the agent acts, and a receipt for what it acted on.
Start with your own company records.
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.
300 credits. No card.
For a guided review of your file, explore the Merge Safety Sprint →
Questions about crm and revops
Will this merge our accounts for us?
No. You get files keyed on your own record ids saying which rows are one company, which merges were refused and why, and which rows we would not call. The join and the merge happen on your side, inside your change control. That is a deliberate position: the moment a supplier writes to your master, an argument about a bad merge becomes an argument about whose fault it is, and the receipt stops being the point.
What happens to a franchise group or a parent and its subsidiary?
They should not merge, and the guard is built to refuse them. Two rows carrying different company numbers are answered as a non-match outright and never even reach the merge guard. Where the numbers are absent, two or more disagreeing weak signals block the merge and the pair is recorded as blocked with the attribute that disagreed named. Where the evidence genuinely does not separate them, the pair is withheld rather than called, which is the right outcome for a parent and a subsidiary trading under one brand.
Our account names are truncated. Is this worth running?
Possibly not on names alone, and the number is published so you can judge before you spend anything. Truncated names resolved 58.10% on the representative fixture — 61/105 — with the remainder returning a shortlist rather than a guess. If your export carries a website, a postcode or a registration number alongside the truncated name, map it and the same rows resolve on a much stronger tier. Ask for the free preview first: we run it on your file, it tiers every row by the strongest signal that survives normalisation, and it calls nothing and spends nothing.
How do we defend a merge to an auditor a year later?
By reopening its decision id. The receipt carries the features, the top weighted contributions, the exact thresholds that call was judged under, the cited evidence with source URLs, the model and prompt version where a model was involved, and a re-run of the score from the stored features. Receipts are also queryable as a population, filtered by pipeline version, threshold and date, so "show me every merge taken under the threshold we have since raised" is a query rather than a project.
We are combining two CRMs after an acquisition. Is this the same thing?
It is the same mechanism under more pressure. Send both exports with their source ids preserved and the overlap comes back as clusters spanning the two systems, with the rows that must not merge separated and the rows nobody can decide listed with the field that would decide them. One thing to decide deliberately rather than leave to a loader: batching. Resolution is order-independent within a batch, but smaller batches collapse more duplicates and one large batch buys order-independence within it. Both directions are real.