How Duplicate CRM Records Quietly Break Comp and Quota Calculations

A finance lead pulls the quarter's commission numbers and one account's credit doesn't match what the rep remembers closing. Nobody suspects the CRM at first. They check the comp plan, then the split rules. Eventually someone finds it: the account existed as two separate records for five months, one created by a rep prospecting cold and one imported from a partner list, and the deal that closed got attached to the newer one while the activity history and territory assignment sat on the older one. Both records looked completely reasonable on their own. Neither looked wrong until someone put them side by side.

We've now seen this exact shape of problem often enough to stop treating it as a data-hygiene footnote. In one engagement, a client had removed a third-party dedup and merge tool during an unrelated app cleanup and never replaced it. Nothing broke immediately. Then a new enrichment process started writing straight into contacts, and thousands of orphaned lead records that had never converted sat there as live duplicate targets. It was the kind of near-miss where a rep re-adds someone from a data provider while an old, forgotten lead for that same person is already sitting in the system with no tool left to catch the match. In another, a business unit had built up a bucket of over a thousand unassigned contact records with no owner, and leadership was blunt about why it mattered: a prior redistribution of account ownership had already caused quota and compensation errors, so whatever came next had to be checked twice or it would happen again. In a third, a list-upload process ran with no dedup gate at all and fuzzy-matched a person to the wrong company entirely, creating two contact records for the same human under two different employers.

None of these started as a compensation problem. They all became one, because who owns an account and what a rep gets paid on it are computed off the same record set that campaign and pipeline reporting reads from. A dedup gap doesn't stay contained to the report where you noticed it.

The failures above have a common shape, and it's not carelessness. Every one of them traces back to a control that used to exist, or should have, and got removed or skipped somewhere upstream.

Sometimes the control is a piece of software. A third-party dedup tool gets pulled during a license cleanup or a platform migration, and nobody assigns anyone to own what it used to catch. Sometimes it's a process step. A list gets handed to a contractor with a requirements doc and no QA gate, and net-new-contact creation quietly replaces match-to-existing because nobody's checking which one is happening. And sometimes it's a field behavior nobody thought to question: most CRMs assign owner to whoever creates a record, so years of ad hoc record creation by people who've since left or changed roles builds an ownership backlog that nobody is auditing, because nothing about it looks broken from any single record's point of view.

The pattern worth internalizing is that these gaps are invisible exactly where you'd expect a person to catch them. A rep working one account doesn't see the duplicate sitting three clicks away under a slightly different company name. A manager approving a comp statement doesn't see that the account got redistributed six weeks ago and the wrong person is still listed as owner on the underlying activity. The gap only becomes visible when someone reconciles two things that are supposed to agree and finds out they don't: a payout against a pipeline report, or an owner field against a comp plan.

This is the step people skip, and it's the one that turns a routine cleanup into an incident. If quota attainment or commission math reads off the owner or account field, redistributing that field mid-cycle without freezing the calculation first means you're changing the inputs to a formula while it's running.

The fix is procedural, not technical: pull a snapshot of every comp-relevant field for the current period before any merge or reassignment touches it. That snapshot becomes the reference for reconciling what changed and why, if a rep or a finance partner questions a number later. It also gives you a rollback path. Without it, you're relying on memory to explain why an account's history looks different than it did last month. Memory is exactly what these engagements show breaking down first: the exec who remembered the last redistribution had caused problems only remembered it because it had already happened once.

An unassigned or orphaned-record bucket isn't a queue to clear as fast as possible. It's a set of records that are each missing a piece of context, and that context usually lives somewhere else in the CRM already.

Cross-reference every unassigned contact against the current account list before deciding what to do with it. Some will map cleanly to an existing account and just need an owner assigned. Some belong to an account that's been rolled up or acquired since the contact was created, and forcing them onto the wrong current account is its own kind of data corruption, arguably worse than leaving them unassigned because it at least looks unresolved. A smaller number won't map to anything real anymore and are candidates for archival rather than assignment. Treating all three groups the same way, usually by bulk-assigning everything to whoever owns the most accounts in that territory, is how a cleanup project quietly recreates the exact quota-skew problem it was supposed to fix.

When two records represent the same account or contact, the instinct is to keep whichever one has more fields filled in and delete the other. That instinct is fine for a contact record. It's a mistake for anything tied to billing or contract history, because merge direction in most CRMs determines which record's related history survives and which gets orphaned or deleted along with the loser.

Before merging, ask which record holds the billing and contract history that the business actually needs intact a year from now. That's the survivor, regardless of which record looks tidier today. This is a five-minute check that gets skipped constantly, because merge tools make it fast to pick a winner and slow to verify you picked the right one.

Once compensation-relevant fields are frozen and merges are resolved toward the right surviving record, that's the point where an automated redistribution rule is safe to run unsupervised. Running it earlier just automates whichever mistake was already sitting in the data.

The standing habit that prevents a repeat of all of this is simple to describe and easy to skip. Pick one comp-relevant number, say a quota attainment figure or a commission total, and periodically trace it back to the individual records behind it. Not the whole database. One number, one rep, all the way down to the records. In the engagements above, duplicate records sharing a single email address weren't treated as unusual once someone started actually looking. They were treated as expected, which is the real problem: nobody was looking often enough for expected to have been caught the first time.

Before running any large-scale dedup or account-ownership redistribution project, work through this in order. The checklist is also available as a ranked list above this section.