The customer exists twice and both records are wrong
Each record is partly correct and neither is complete, so every team downstream is confidently working from a different version of the same customer.
What actually happens
Duplicate records are not a tidiness problem. Once two records exist, every subsequent update makes the situation worse, because updates go to whichever one the person happened to open.
A customer is created in the CRM by sales. The same customer is created in the ERP by finance a few days later, spelled slightly differently, because the integration did not match them and nobody was looking.
From that moment both records accumulate truth. Sales updates the contact and the renewal date on one. Finance updates the billing address, the payment terms and the credit limit on the other. Support attaches entitlements to whichever one their tooling resolved.
The damage is not that the data is duplicated. It is that the data is split. Credit exposure is calculated against one record while orders are placed against the other, so the exposure figure is understated and the credit control that depends on it is not doing its job.
It surfaces in one of two ways. Either finance notices an exposure that does not reconcile, or a customer receives two invoices with different terms and calls to ask which one is real.
Merging them afterwards is genuinely difficult work, because by then both records have dependent objects attached and merging is not a data operation, it is a series of judgement calls about which version of each field is authoritative.
The cost is not the duplicate. It is that credit exposure was calculated against one record while orders were placed against the other, and both numbers looked correct in isolation.
The same customer, two ways
Measured in how long the split persists, because the merge cost grows with every day both records are used.
Illustrative, not measured. The times below model a scenario built from the patterns we see in production estates. They are not timings recorded at a named customer. The point is the shape of the clock, not the totals: check it against your own last ten incidents.
Today, found in a reconciliation
- Day 0Customer created in the CRM. Created again in the ERP days later under a near-match name. Integration does not match them.
- Day 0 ↓ Day 60WaitingBoth records accumulate updates from different teams. Dependent objects attach to both.
- Day 60Credit exposure does not reconcile. Finance investigates.
- Day 60 ↓ Day 74WaitingDuplicate confirmed. Merge scoped: which field on which record is authoritative, and what depends on each.
- Day 74Merge executed with manual field-level decisions.
- Day 74+WaitingHistorical reporting for the preceding two months remains split across both records.
~10 weeks of split exposure · and a merge nobody wanted to do
With master data matched continuously
- Day 2Sentinel detects a probable match across systems on fuzzy name, registered number, domain and address, not on exact key.
- Day 2Confidence scored. Both records still nearly empty, so the merge is cheap and almost nothing depends on either.
- Day 2Field-level differences surfaced with their source and timestamp, so the authoritative version of each is evidenced rather than guessed.
- Day 2Action Ticket raised proposing the merge with the field-level resolution, the dependent object list and the rollback path.
- Day 3Data owner approves. Merge executed under governance with the pre-merge state retained.
- OngoingCredit exposure is calculated against one record from day three onward.
Caught at day 2 · when the merge was still trivial
The number that matters is not the ten weeks. It is that merge cost grows with time, because every day both records are in use attaches more dependent objects and more conflicting field updates to each.
A duplicate found on day two is a merge of two nearly empty records. The same duplicate on day sixty is a set of field-level judgement calls plus a reporting history that stays split regardless of what you do to the records.
The mechanism is probabilistic matching across systems rather than exact key matching. Duplicates exist precisely because the exact keys did not match. Fuzzy name, registered number, email domain and address together identify what a key comparison cannot.
Retaining the pre-merge state is what makes the merge approvable. A data owner asked to authorise an irreversible merge will hesitate, and should. One that can be unwound is a much easier decision to make quickly, which is the whole point of catching it on day two.
Why the number is what it is
The number that matters is not the ten weeks. It is that merge cost grows with time, because every day both records are in use attaches more dependent objects and more conflicting field updates to each.
A duplicate found on day two is a merge of two nearly empty records. The same duplicate on day sixty is a set of field-level judgement calls plus a reporting history that stays split regardless of what you do to the records.
The mechanism is probabilistic matching across systems rather than exact key matching. Duplicates exist precisely because the exact keys did not match. Fuzzy name, registered number, email domain and address together identify what a key comparison cannot.
Retaining the pre-merge state is what makes the merge approvable. A data owner asked to authorise an irreversible merge will hesitate, and should. One that can be unwound is a much easier decision to make quickly, which is the whole point of catching it on day two.
The mechanism is probabilistic matching across systems rather than exact key matching.
Who decides to press go
Merging customer master data changes a system of record and affects billing, credit and reporting, so it is never automatic.
Matching, confidence scoring, field-level difference analysis and dependent object mapping all run under policy. None of them modify a record.
The Action Ticket carries the proposed field-level resolution with the source and timestamp for each, the dependent object list and the rollback path. The data owner approves before anything is merged.
The pre-merge state is retained on every merge. Master data decisions are judgement calls, and judgement calls need to be reversible when the judgement turns out to be wrong.
Two customer records across CRM and ERP with near-match attributes and different keys. Integration matched on exact key and found nothing. Both records accumulating updates.
Probable match scored on fuzzy name, registered number, email domain and address. Field-level differences surfaced with source and timestamp. Dependent objects on each record mapped.
Action Ticket raised proposing the merge with field-level resolution and rollback. Held for the data owner. Pre-merge state retained on execution.
Matching rule retained so the same near-match pattern is caught at creation. Creation-time duplicate check added to the integration rather than relying on exact key.
This is a platform capability, not a published customer deployment. The mechanism, which is treating a business process outcome as a signal, correlating across the systems that implement it, and then executing a governed MOP with pre-check, post-check, rollback and approval gating, is running in production today; see governed day-2 operations across 2,000+ nodes and closed-loop network automation. The back-office scenario above applies that same mechanism to a business process. The timings shown are modelled, not measured at a named customer.
If the action carries no service impact
Matching, confidence scoring, field-level difference analysis and dependent object mapping all run under policy. None of them modify a record.
If it merges or modifies a record
The Action Ticket carries the proposed field-level resolution with the source and timestamp for each, the dependent object list and the rollback path. The data owner approves before anything is merged.
What Sentinel did, step by step
- ObserveTwo customer records across CRM and ERP with near-match attributes and different keys. Integration matched on exact key and found nothing. Both records accumulating updates.
- InvestigateProbable match scored on fuzzy name, registered number, email domain and address. Field-level differences surfaced with source and timestamp. Dependent objects on each record mapped.
- ActAction Ticket raised proposing the merge with field-level resolution and rollback. Held for the data owner. Pre-merge state retained on execution.
- OptimizeMatching rule retained so the same near-match pattern is caught at creation. Creation-time duplicate check added to the integration rather than relying on exact key.
Let us look at your customer master
We will show you how many probable duplicates are sitting in it today.