Commission reconciliation is the check that what a company actually paid in commission matches what its plan rules say it owed. It compares the deals in the source system against the deals the calculation priced, and the calculated amounts against what payroll released, then explains every difference before the period is closed.
Reconciliation is widely treated as a sanity check on a total, which is the version of the job that catches almost nothing. A total can be within a percent of expectation while two reps are wrong in opposite directions, while five deals never entered the calculation at all, and while a manual adjustment keyed twice quietly offsets a rate applied to the wrong basis. Errors in commission are strongly inclined to cancel each other out in aggregate, so the aggregate is the last place they are visible.
A real reconciliation is three separate tie-outs, each done on counts before amounts. First, coverage: every deal the source system says closed in the period should appear in the calculation, and the count should match before anyone looks at a dollar figure. Second, calculation: the amount produced for each deal should be reproducible from the rule that produced it, at the rate and basis the plan specifies for that rep on that date. Third, release: the total per rep leaving the calculation should equal the total per rep arriving in payroll, including adjustments, which is the step most often skipped because it crosses a system boundary and usually an ownership boundary too.
Do the matching on stable identifiers. Deal id to deal id, employee id to employee id. Names break, and they break silently: a rep who exists in the CRM as an email address and in payroll as an employee number will simply vanish from a lookup keyed on either, taking their whole book with them and leaving a total that still looks plausible. Freeze the source extract with a timestamp and reconcile against that frozen copy, because a source system queried twice an hour apart returns two different answers and neither of them is the one you paid against.
Every variance then gets a category and a name: timing, where a deal landed either side of a period boundary; data, where the source record changed after the run; rule, where the calculation applied something the plan does not say; manual, where a human added or removed an amount; and genuine error. The period closes when each variance has one of those labels and a decision attached, either accepted or scheduled as a true-up in a named future run. A reconciliation that ends with an unexplained residual has been abandoned rather than completed.
Twenty-two reps, one monthly run. The finance lead compares the CRM extract taken on 1 April against the commission run and against what payroll released.
The overpayment is 2.5% of the run, comfortably inside the margin a total-level review waves through. It turned out to be one adjustment keyed twice. The five missing deals closed in the final two days of March and were picked up by the April run, so they were timing rather than loss, which is something you can only say once you have found them.
Four habits account for most of it. Reconciling totals instead of rows, which hides offsetting errors by design. Matching on rep name or customer name, where one renamed account or one rep with two identities drops rows from a lookup without raising anything. Working from an export that was silently truncated, since many systems cap a download at a fixed number of rows and return it as a complete file. And re-pulling the source after the pay run, so the thing you are reconciling against has already moved. All four produce a workbook that balances. None of them produce a reconciliation you could defend to a rep holding a different number.
Commish pays commission reconciliation the way your plan describes it, shows the arithmetic on every line, and traces each payment back to the deal that earned it.