Two ways to compute the same liability
Every rebate programme carries an accrual: the amount earned but not yet settled, recognised in the period the activity happened rather than the period the money moves.
There are two ways to arrive at it.
Estimated. Take aggregate volume for the period, apply an assumed rate derived from last year’s settlement, post the result. Fast to implement, easy to explain, and disconnected from the transactions.
Transaction-level. Evaluate each qualifying line against the agreement’s actual rules as it happens, sum the result, post it. Harder to stand up, and it produces a number that can be interrogated.
The observable difference is variance at settlement. Estimated accruals commonly land 10–30% away from the eventual settlement. Transaction-level accruals land within a couple of percent.
Why the variance is worse than it looks
A 20% true-up is not a 20% problem, for three reasons.
It concentrates. The variance accumulated over a year lands in one period, usually at year end, distorting a period that had nothing to do with the activity.
It compounds the estimate. Next year’s assumed rate is derived from this year’s settlement, which included last year’s catch-up. The estimate is being fed its own error.
It is not explainable. When the auditor asks why the accrual was what it was, an estimated accrual can only answer with the method, not with the evidence. That is an uncomfortable conversation in a good year and a serious one in a bad one.
Four properties of an auditable accrual
Drill-back. Any posted balance resolves to the transaction lines that produced it. This is the one that matters most, because it makes every other question answerable.
Locked periods. The engine validates against the accounting calendar before writing. An engine that can post into a closed period will eventually restate one.
Stable base data. An accrual computed from lines that can still move underneath it is not closed, whatever the ledger says. Restatements must flow through the accrual rather than around it.
A review gate. Computed accruals stage for human review before they post — grouped, compared to prior periods, outliers surfaced. Not every line; exceptions and variances. Automation without a gate is how a rule error becomes a restatement.
Retroactive tiers, honestly
The hardest case is a retroactive tier, where crossing a threshold reprices all volume from the first unit. Until the threshold is crossed, the theoretically correct accrual depends on the probability of crossing it.
Most businesses accrue at the currently-achieved tier and take a catch-up on crossing. That is defensible and makes the liability lumpy. The alternative — probability-weighting the tier — is more accurate in expectation and much harder to explain to an auditor.
Our preference is the simple method plus a projected landing tier reported alongside the accrual, so the business can see the coming step without the balance sheet having to predict it.
Where the effort actually goes
Standing up transaction-level accrual is rarely blocked by the arithmetic. It is blocked by matching: qualifying transactions have to be attributable to an agreement, which requires customer, product and entity identity to resolve.
Which is the same prerequisite as claim validation, and the same prerequisite as net-net cost. That is not a coincidence — it is why these projects should be sequenced together rather than run as three separate initiatives.