How do I estimate a tiered rebate accrual under ASC 606?
Pick one of the two methods ASC 606 allows — most-likely amount (the single most probable outcome) or expected value (the probability-weighted average) — per program, deliberately, and accrue at that rate from the first qualifying dollar. With a small number of discrete tiers, most-likely usually fits; across a portfolio of many similar agreements, expected value usually fits.
Then apply the constraint — and note that for rebates it works in reverse: the constraint caps recognized revenue, so when the finishing tier is genuinely uncertain, the discipline pushes you toward the higher rebate accrual, not the lower one. Under-accruing a rebate is the aggressive position, not the conservative one.
The same program, both methods
Calendar-year volume rebate, retroactive tiers: 2% on all purchases if the customer reaches $6M, 4% if $12M. Q1 qualified purchases: $2,500,000. Your demand plan says: 60% chance the year lands near $10M (the 2% tier), 30% chance a design win pushes it to $13M (4%), 10% chance it stalls below $6M (no rebate).
Q1 accrual = $2,500,000 × 2% = $50,000
(60% × 2%) + (30% × 4%) + (10% × 0%) = 2.4%
Q1 accrual = $2,500,000 × 2.4% = $60,000
ASC 606 does not let you pick per quarter to manage the number — the method is chosen per program for whichever better predicts the consideration, and applied consistently until the facts change.
The constraint runs backward for rebates
The variable-consideration constraint says: include revenue only to the extent a significant reversal is not probable. Most teams internalize it as “be conservative, book less.” For rebates, that instinct inverts the standard: the rebate reduces revenue, so the constrained — defensible — position when the finishing tier is genuinely in doubt is the higher accrual. In the example above, if the 30% chance of the 4% tier is real and rising, most-likely at 2% is the position an auditor will push on, because a move to 4% is retroactive: it re-rates every dollar already shipped. How violent that catch-up gets is exactly the retroactive-tier mechanic.
Reassess every period — as a decision, not a drift
The estimate must be updated each reporting period, with changes booked as a cumulative catch-up in the period the estimate moves. Operationally that means the finishing-rate call needs three things a spreadsheet cell doesn’t have: an owner, a written basis (run-rate, pipeline, seasonality — whatever the forecast actually rests on), and a revision log. Growth programs add a fourth: an agreed baseline, because an estimate against a disputed baseline is two estimates.
The estimate memo — the artifact that survives audit
One page per material program, written when the estimate is set:
- Method (most-likely / expected value) and why it fits this program’s shape;
- The forecast basis and its source, as of the estimate date;
- The constraint reasoning — what would have to be true for a significant reversal, and why it isn’t probable;
- Owner and revision history — every rate change, dated, with the trigger.
This memo is artifact #2 of the three that end audit conversations early — the full set is on defending a rebate accrual to auditors. When the estimate later meets actuals, the difference should decompose cause by cause — the true-up test. Program-design mechanics for tiers themselves are on tiered volume & growth rebates.