Commission Tracking: The Record That Settles a Dispute

A rep closes the quarter believing they are owed a number, finance publishes a different number, and neither side can reconstruct how the other one was produced. The plan document is not in dispute. The rate is not in dispute. What is in dispute is which deals landed inside the period, which rule was applied to a split, and whether a deal that was invoiced in March but collected in May counts yet.

That is a tracking problem rather than a compensation-design problem, and the two get solved in different places. A plan decides what people are paid for. Tracking decides what the company can prove it owes, on a date, from records somebody else can check.

Tracking is the third question, after who and how much

Three questions sit underneath every payout and they are usually answered by three different people at three different times.

How much is the plan: the split between fixed and variable pay, the measurement basis, the rate shape, the clauses that decide a bad quarter. That design work is set out in what a commission plan is made of, and the five decisions the rate is the last of are in the commission plan entry.

Who is crediting: which roles earn on a deal, how a split is tested, and when the credit is awarded. Sales crediting covers the rule and the test that makes a split defensible.

What the company can prove is tracking, and it is the one nobody assigns. It is the record of every commissionable event, the rule that was applied to it, the period it belongs to, and the state it is currently in. A plan with no tracking record behind it is a policy that gets re-litigated by memory every payout cycle, and the person with the best memory wins.

What one commissionable line has to hold

The unit of tracking is not a rep and not a month. It is one line: one deal, one credited party, one rule.

Fields on a commissionable line

• ✓Yes: The deal identifier from the system of record, not the deal name
• ✓Yes: The credited party, and the crediting rule that produced this share
• ✓Yes: The measurement basis used: booked value, invoiced, recognised revenue, margin or units
• ✓Yes: The rate applied, and the tier or accelerator state at the moment it applied
• ✓Yes: The period this line belongs to, and the event that put it there
• ✓Yes: The earned date and the paid date, recorded separately
• ✓Yes: The adjustment state: clean, held, clawed back, or superseded by a later version
• ~Depends: A rep-visible explanation of the calculation in words rather than a formula reference
• ~Depends: A free-text note explaining a manual override, with a named approver

Two of those do the work when a line is contested. The crediting rule has to be stored on the line rather than inferred from a policy document, because policies get revised and lines get paid once. And the tier state has to be captured at the moment of calculation, because a rep who crossed an accelerator threshold in week nine has a different rate on week ten deals than the plan's headline number suggests, and a recalculation run in the following quarter against the current tier will quietly produce a different answer.

The four dates that never agree

Most payout arguments are date arguments wearing a money costume.

Close dateOwned by the CRM

• Set by the person whose number the deal counts toward
• Moves when a stage is corrected weeks later
• Drives the pipeline report and the forecast
• Is the date most spreadsheets treat as the whole answer

Earned dateOwned by the plan

• The event the plan names: signature, invoice, first payment or collection
• A legal state rather than a calendar convenience
• Can fall a quarter after the close date on collection-based plans
• Decides which period the line belongs to

Paid dateOwned by payroll

• The payroll run the money actually lands on
• Governed by a cutoff nobody in sales sees
• Separated from the earned date by design, not by delay
• Is what the rep experiences as the answer

The fourth date is the period boundary itself, and it is the one that produces the most heat, because it is the only one that is arbitrary. A deal signed on the last day of a quarter and invoiced on the first day of the next one belongs to whichever period the plan says it belongs to, and the plan usually says nothing. Writing that rule down before a quarter ends costs a sentence. Settling it afterwards costs a relationship.

Earned and paid being different events is the single most common defect in a plan, and treating them as one is what produces a rep who believes they were shorted when they were simply early. Where the earned event is collection rather than signature, the seller is carrying the customer's payment terms in their own cash flow, which is a design decision worth making on purpose.

Where the spreadsheet stops

A spreadsheet holding one plan applied to a few dozen deals a quarter is the honest first version, and it is not a deficiency. It fails at a scale a team can feel, and the failures are specific rather than general.

Version drift comes first. Two files exist, both are named final, and the difference between them is a manual override nobody recorded. Then retroactive change: a plan is revised mid-year, and every line calculated under the old rules has to be either preserved or restated, which a formula grid does not distinguish. Then the joiners and leavers: somebody starts in week six on a prorated quota, somebody leaves with earned but unpaid deals, and both cases live in a corner of the sheet with a comment on it. Then the audit gap: a split was applied because two people agreed on a call, and the only record of why is one of their recollections.

Last, and most corrosive, the rep cannot self-serve. When the only way to know what you are owed is to ask, the plan has stopped functioning as an instruction and become a monthly negotiation.

The vendors in this category describe the same failure. Everstage's commission tracker page states that "Most teams track commissions in spreadsheets until someone gets paid wrong", and describes its own coverage of the restatement problem as tracking "retroactive changes, clawbacks, and post-close adjustments automatically across periods", as published on everstage.com and fetched on 2 September 2026. Whether that is worth buying depends on whether the rule the software would encode has been written down yet. A rule nobody wrote down cannot be automated, and encoding an unwritten rule makes the ambiguity permanent without it ever having been agreed.

The period close, run as a process

The close is where tracking either produces trust or destroys it, and the difference is whether there is a published window in which a rep can disagree before the money moves.

1. Step 1Freeze

   Fix the deal set for the period from the system of record, and stamp the extract. Later CRM edits land in the next period as adjustments.

2. Step 2Calculate

   Apply the crediting rule, the basis, the rate and the tier state to each line, and store what was applied rather than the formula that applied it.

3. Step 3Review

   A named owner checks the exceptions: overrides, splits, held lines and anything restated from an earlier period.

4. Step 4Publish

   Send every rep a statement they can read line by line, before approval rather than after payment.

5. Step 5Dispute window

   A stated number of days in which a line can be challenged, with the challenge going to the owner rather than to a manager.

6. Step 6Approve and pay

   Sign off the run, hand the approved total to payroll, and keep the approved version immutable.

The freeze is the step that gets skipped, and skipping it is what turns every conversation into a negotiation. Without a stamped extract there is no agreed set of deals to argue about, so a dispute about one line reopens the whole period. With one, a late CRM correction becomes an adjustment in the next run, which is a smaller and much more honest object.

The dispute window is the second thing worth protecting. A window with a stated length converts an open-ended grievance into a dated request, and it gives finance a defensible reason to close the run.

The statement a rep can argue with

A statement that shows a total is a claim. A statement that shows how the total was produced is evidence.

Three things make it evidence. Every line names its deal, so it can be checked against the pipeline record. Every line names the rule that produced it, in words, so the rep can see why an assist paid half rather than being told that it did. And every restated line names what it supersedes, so a correction reads as a correction rather than as a number that changed overnight.

Everstage's page describes that traceability as the ability to "Drill into which deal triggered which rule at which rate, line by line", and states that "Every adjustment, dispute, and approval has a clear owner, a tracked timeline, and a logged resolution", both as published on everstage.com and fetched on 2 September 2026. Those are product claims rather than measurements, and the underlying requirement holds whether the record lives in a platform or in four tabs of a sheet.

Working the arithmetic through with invented inputs shows why the explanation matters more than the total. Suppose a plan pays four percent on booked value, with the rate rising to six percent on everything after a seller passes a quarterly target of two hundred thousand dollars, and a deal worth sixty thousand closes in the week the seller crosses that line. Every figure here is invented for the illustration and describes no real plan. Two defensible answers exist: the whole deal at the higher rate, or the portion above the threshold at the higher rate and the rest below it, and the difference on this single deal is over a thousand dollars. A statement showing only the total gives the rep no way to tell which convention was used, and a plan that never names the convention will produce this argument in the quarter it first matters.

What tracking cannot fix

A clean tracking record makes a plan legible. It does not make it right.

If a team misses in numbers rather than one seller at a time, the tracking is reporting accurately on an assignment that was wrong, and how a quota gets set and how it gets gamed is the prior question. If the deal records feeding the calculation are unreliable, that is a pipeline hygiene problem, and records that mean something is where it gets fixed. If the fields the calculation needs do not exist on the opportunity object at all, the fix is upstream in the objects, stages and write-back loop rather than in the payout file.

And where the real constraint is the number of qualified conversations rather than how the credit for them is divided and recorded, no tracking record will move it. We are paid on attended meetings that meet criteria agreed in writing before launch, which is the same unit a quota is written in. See what a first campaign produces against your market before rebuilding a payout process that may not be the thing holding the quarter back.

The short version

Tracking is a third question after how much and who, and it is the one nobody is assigned. It is the record of what the company can prove it owes.

The unit is one line: one deal, one credited party, one rule, carrying the deal identifier, the rule applied, the basis, the rate and tier state at the moment of calculation, the period, the earned and paid dates separately, and the adjustment state.

Four dates attach to one deal and they do not agree. Close date belongs to the CRM, earned date to the plan, paid date to payroll, and the period boundary is arbitrary until somebody writes it down.

Run the close as a process with a freeze at the front and a stated dispute window before approval, and publish a statement that names the deal and the rule behind every line. A total is a claim. A line a rep can trace is evidence, and disputes fall because the argument now has something to be about.

Vendor product descriptions verified against everstage.com as fetched on 2 September 2026. Vendors revise these pages; confirm the current text before relying on them.