When two reps both claim a closed deal, the CRM is usually the reason nobody can settle it. Owner fields move; commission maths shouldn't. Here's the fix that ends the argument before it starts.
End of month. A deal closes. Two people claim it: the setter who booked the call in week one, and the rep who owned the record when the agreement was signed. Both open the CRM to prove their case, and the CRM agrees with whoever looked last — because the owner field they're both pointing at has been overwritten three times since the deal was born.
This argument is treated as a people problem. It's a data problem, and it was created by a design decision most CRMs share: the owner field describes the present, not the past. Ownership answers "who works this deal now?" — a genuinely useful question, which is why deals get reassigned as they move from setting to closing, when someone's on holiday, when a manager rebalances the board. Every one of those reassignments is correct, and every one of them destroys the previous answer.
Commission doesn't ask who owns the deal now. It asks who set it and who closed it — questions about history, aimed at a field that only stores the present. That mismatch is the entire argument. No amount of "let's check the CRM" resolves it, because the CRM's record of the past is the thing that got overwritten.
Teams route around this in three ways, all bad. They reconstruct history from memory, which turns payroll into a negotiation. They dig through activity logs, which turns a five-minute question into an hour of forensics that still ends in interpretation. Or they quietly pay both claims a bit, which prices the ambiguity into the payroll forever and teaches everyone that the numbers are soft.
The fix is structural and small: write the attribution down at the moment it happens, in fields that nothing is allowed to move. When a setter books the call, their name and a timestamp go onto the deal — not into the owner field, into a field that exists only to answer "who set this?" When a closer takes the deal, same again. From that moment the owner field can churn as much as operations requires, because the question it keeps overwriting is no longer stored there.
Two details make the difference between this working and being theatre:
Snapshot at assignment, not at payout. If attribution is filled in at the end of the month, it's filled in by whoever's doing the filling, from the same reconstructed memory as before. The write has to happen automatically, at the event, when there's exactly one true answer and no money riding on it yet.
Nothing repairs it by hand. The moment a manager can "correct" the setter field, the field is a claim again rather than a record. Corrections should be rare, logged, and deliberate — an exception process, not an edit box.
The payoff isn't just quieter month-ends. Attribution that survives is what makes rep-level numbers mean anything at all. A setter's booked-to-show rate, a closer's close rate by lead source, whether the new hire's deals stick past 30 days — every one of those reports joins deals to people through history, and if history is whatever the owner field says today, the reports are fiction with decimal places.
Every CRM we install writes setter and closer onto the deal at assignment time, automatically, into fields the pipeline never touches. It's a few fields and a rule. What it buys is that when a deal closes and two people look at it, they see the same answer — written back when neither of them had a reason to argue with it.