One tier boundary can move the whole period’s rebate. Your engine should know which kind of tier it is.
The person searching for this owns rebate accounting or channel finance at a manufacturer or distributor with tiered customer programs. Tiered rebates are the most common program shape in B2B — and the most commonly miscalculated, because one contract word (retroactive vs incremental) changes the math on every dollar. Aurgus computes flat, tiered (linear and retroactive), and growth rebates deterministically, with the tier design explicit in the agreement, attainment visible against thresholds, and every recalculation gated on a named human approval. Aurgus is in design-partner stage, which we state plainly.
How tiered rebates actually work.
A tiered rebate steps the rate up as volume crosses thresholds — say 1% to $1M, 2% to $5M, 3% above. Every downstream number is determined by two design decisions made in the contract.
- 1
Decision one: retroactive or marginal tiers.
Retroactive: crossing a threshold applies the new rate to all period volume — one transaction can move the whole period’s rebate. Marginal (incremental): each band’s rate applies only to the volume inside it, like tax brackets. On $5.1M with the tiers above, retroactive pays ~$153K; marginal pays ~$93K. Run your own numbers → Same volume, same contract page, $60K apart.
- 2
Decision two: what counts toward the threshold.
Which products, which entities (one sold-to, or a whole buying group), gross or net of returns, over which window — calendar year, fiscal year, rolling period. Threshold scope is where two well-meaning teams read the same contract differently.
- 3
Growth variants pay on the increment, not the volume.
A growth rebate rewards improvement against a prior-period baseline — 2% if purchases beat last year by 10%. The baseline is the most fragile input in the program: which period, what basis, adjusted for what. Growth disputes are baseline disputes.
- 4
Mid-period, the final tier is unknown — that’s the accounting problem.
Until the period closes you are accruing against an estimate of the finishing tier. That makes tiered rebates variable consideration under ASC 606, with the estimate revisited every close and trued up at settlement.
Where tiered programs leak money in practice.
Tiered rebates fail at the boundaries — of tiers, of periods, of baselines. The Off-Invoice Control Index scores how exposed your own programs are in about three minutes.
- The spreadsheet computes marginal; the contract says retroactive. Or the reverse. The formula was right for the 2023 version of the agreement and nobody changed it at renewal. This is the classic silent leak: no error message, just a wrong number every period.
- Customers land near thresholds at period end — and the data isn’t final. A customer at $4.97M against a $5M retroactive boundary is a five-figure question mark. Late shipments, returns, and credit memos decide it after you’ve already accrued.
- The accrual rate and the earned-to-date rate are conflated. Accruing at the current tier when the customer will clearly finish a tier higher understates the liability all year and produces a painful Q4 catch-up — the shape auditors flag first.
- Growth baselines are missing, stale, or disputed. If the prior-year baseline isn’t loaded and governed, a growth program silently pays on all volume instead of the increment — an over-accrual that looks plausible on every report until someone checks the contract.
- Restated data changes a closed period’s tier and nobody recomputes. Or worse — someone edits the old number in place, and the audit trail now contradicts itself.
What Aurgus does for tiered and growth rebates — and what it deliberately doesn’t.
Volume flat, volume tiered (linear and retroactive), and growth incentive are v1 program patterns in Aurgus, on the same substrate as our rebate management software.
- 1
The tier design is explicit in the governed agreement.
Retroactive or marginal is a structured property of the agreement — authored in plain language, reviewed by a human, and applied by the engine exactly as approved. It cannot drift the way a spreadsheet formula does.
- 2
Attainment computed deterministically, visible against thresholds.
Volume toward each threshold is computed from transaction data — same data, same agreement, same answer every run — and every accrual event carries lineage to the rows and the tier that produced it.
- 3
Corrections are append-only and human-approved.
When late data moves a customer across a boundary, the original events stand; the system proposes a recalculation, shows the delta, and a named human approves before any money moves. The before, the after, and the why are all on the ledger.
- 4
Growth programs run against a governed baseline.
The prior-period baseline is loaded as data the agreement references — visible, versioned, and required. A growth calculation whose baseline you can inspect is a calculation you can defend.
- 5
The accrual estimate is an explicit, gated judgment.
Where the expected finishing tier differs from the current one, that estimation is surfaced as a human decision with its reasoning captured — not a buried cell. The engine owns the arithmetic; people own the judgment, which is the posture the variable-consideration audit defense conversation requires.
Your tiered programs live in per-customer spreadsheets.
If the retro-vs-marginal logic is a formula someone maintains per tab, every renewal is a chance for a silent leak. Making the tier design a governed property of the agreement is exactly what Aurgus ships.
Quarter-end boundary cases eat your close.
Customers near thresholds, late data, true-ups — deterministic recomputation with human-gated corrections is the shipped core of the product.
You want the system to choose the accrual estimate for you.
Aurgus computes attainment and shows the boundary math; the estimation judgment ASC 606 requires stays with your controller, explicitly and on the record. We think that is correct, not a limitation — the model never moves money.
You need forecasting of future-period attainment as a product feature.
Run-rate projection dashboards are not the shipped core. Today the product answers what has been earned and what the boundary math implies — deterministically, with lineage. Aurgus is in design-partner stage, which we state plainly.
Tiered and growth rebates, honestly answered.
- What is a tiered volume rebate?A rebate whose rate steps up as purchase volume crosses agreed thresholds within a period — 1% to $1M, 2% to $5M, 3% above is a typical shape. The two design decisions that determine every downstream number: how tiers apply (retroactive to all volume, or marginal within each band) and what counts toward the threshold (products, entities, gross vs net, window).
- What is the difference between retroactive and marginal tiers?Retroactive: crossing a threshold applies the new rate to all period volume — on $5.1M with the tiers above, ~$153K. Marginal: each band’s rate applies only inside the band, like tax brackets — ~$93K on the same volume. A program computing one design while the contract says the other leaks silently, which is why the distinction must live in the calculation engine, not in a formula someone remembers to change.
- How do you accrue for a tiered rebate under ASC 606?Mid-period, the finishing tier is unknown, so the rebate is variable consideration: you accrue against an estimate — commonly the expected final tier — constrained so revenue isn’t overstated, revisited each close, and trued up at settlement. An engine helps by computing actual attainment deterministically and carrying the estimation judgment as an explicit, human-approved input. See ASC 606 rebate compliance for the full chain.
- What is a growth rebate?A rebate on improvement against a prior-period baseline rather than absolute volume — 2% if purchases beat last year by 10%, for example. The baseline is the program’s most fragile input: which period, what basis, adjusted for what. An empty or wrong baseline silently turns a growth program into a volume program, paying on all volume instead of the increment — so the baseline must be governed, visible data.
- What happens when late data changes the tier?Late transactions and returns can move a customer across a boundary after the rebate was computed — with retroactive tiers, changing the rate on everything. The wrong answer is editing the old number. The correct mechanics are append-only: original events stand, a recalculation produces correcting events that reference them, and a named human approves before it takes effect. That is how Aurgus handles it. To walk through a real boundary case, talk to one of our experts.
The adjacent mechanisms you’re probably also running.
Bring one tiered agreement and its spreadsheet.
Thirty minutes. No pitch. We’ll read the tier language together, check what the spreadsheet actually computes, and tell you honestly whether Aurgus fits — including where it doesn’t yet.