Why doesn’t my rebate accrual match my settlements?
Because an accrual and a settlement are computed at different times, on different data, under different assumptions. The accrual was booked from an estimate — the expected finishing tier, the qualifying base as it looked that month. The settlement is computed later, on actuals, after late claims, returns, and master-data changes have moved that base.
The gap is almost never an arithmetic error. It is the sum of every assumption that changed between booking and settlement — and a controlled program doesn’t make the gap zero, it makes the gap decompose into named causes.
The five things that move between accrual and settlement
1. The rate estimate. Tiered programs accrue at the rate the customer is expected to finish at — that is what ASC 606 variable consideration requires. If the finishing tier was called wrong, the settlement lands on a different rate. With retroactive tiers the miss applies to every dollar in the program, not just the marginal band, which is why one wrong tier call can move the number violently at settlement.
2. Late data. Returns, credit notes, late shipments, and late claims land after the period they economically belong to. The base your accrual was measured on and the base the settlement is computed on are different populations of transactions — even when both calculations are correct.
3. Base drift. “Qualifying volume” is a definition, not a fact: gross or net of returns, freight in or out, which entities roll up, which SKUs count. If the accrual and the settlement apply that definition even slightly differently — or the definition was applied inconsistently month to month — the difference accumulates into a number nobody can attribute.
4. Settlement-side netting. Settlements rarely arrive as one clean figure. They net partial payments, disputed lines, prior-period corrections, and sometimes deductions taken by the customer before you agreed anything. Comparing a gross accrual against a netted settlement without unpicking the netting guarantees a mismatch that looks like a calculation error and isn’t.
5. Corrections by overwrite. When last month’s accrual was “fixed” by typing over it, the number you are now reconciling against no longer exists anywhere. The comparison degenerates into archaeology. This is the structural failure the others hide behind — it is why the same gap re-opens every quarter. (The alternative is correction by supersession: the original stands, the correction references it.)
Why the gap persists
Each number is locally rational. The accrual was right for what was known at booking; the settlement is right for what is known now. Treating reconciliation as a monthly meeting between the two — performed by people, on spreadsheets — means re-discovering the same five causes by hand, every period. Reconciliation is a property the calculation model either has or doesn’t: if accruals, corrections, and settlements are recorded on one ledger, in one qualifying-base definition, with estimates marked as estimates, the gap explains itself. If they aren’t, no amount of meetings closes it permanently.
The test to run at your next close
- Can you reproduce last quarter’s accrual today, exactly, with its evidence — after the data has moved?
- Is every estimate in the number — finishing tier, growth baseline — documented as a decision with an owner, or buried in a cell?
- Does your true-up decompose into named causes — rate estimate, late data, base drift — or is it booked as one plug?
Three yeses and the accrual-to-settlement gap is a routine, explainable quantity. Any no, and the gap will keep “surprising” you — whatever tool you buy. How an append-only calculation model makes the decomposition automatic is described on the rebate accrual software page; the free assessment is the structured version of the three questions above.