How to Model What a Trade Scheme Will Cost Before You Launch It

Modelling a scheme's cost means calculating what it pays out under different levels of partner achievement — not just the expected case. Take the slab table, apply it to each partner's likely, best and worst-case volume, total the payouts, and compare the result with the budget. For a distributor incentive scheme — a trade scheme, not a government one — the worst case is the number that should decide approval.

Most schemes are approved on a single expected figure. That is the one number almost guaranteed not to happen, and it hides the number that actually matters: what the scheme costs if it works. This applies to any rate-driven scheme — a slab-based trade rebate, a QPS, or any of the other trade-scheme types that pay more as partners do more.

The same scheme, four scenarios

The table runs one illustrative scheme across four achievement levels. All figures are illustrative — use your own partner data, never these numbers. Assume a scheme generating around ₹6 crore of covered sales, with a ₹15 lakh budget.

Scenario	Assumption	Total payout	% of scheme revenue	Versus ₹15 L budget
Conservative	Few partners cross tier one	₹6.2 L	~1.0%	well under
Expected	Based on last period's distribution	₹11.8 L	~2.0%	under
Optimistic (sales)	Most partners reach the next tier	₹16.4 L	~2.7%	over
Worst case for cost	Every partner tops out	₹21.5 L	~3.6%	well over

Read the bottom two rows together. The optimistic row is the one the sales team is hoping for — and it is already over budget. The worst case for cost is simply that hope taken to its limit. The scenario the commercial team wants most is the scenario the finance team should fear most: they are the same direction, and a scheme modelled only on the expected row cannot see it.

Why the expected case is not enough

A scheme approved on its expected cost carries a quiet assumption: that performance lands in the middle. But payout scales with achievement, so if the scheme works better than expected, it also costs more than budgeted — and it can cost a great deal more. The expected case is a forecast of the middle; it says nothing about the tail.

Worse, the overrun happens at the least convenient moment. When a scheme is outperforming, the internal story is a success story — targets beaten, partners engaged — and nobody is watching the budget line. The cost lands after the celebration, at settlement, as a payout larger than anyone signed off. By then it is a claim to honour, not a decision to reconsider.

This is why the figure that should gate approval — the number a CFO signing off the scheme should ask for — is the scheme's maximum liability, not its expected cost. The maximum liability is what a payout cap is designed to contain, and you cannot set a sensible cap without having modelled the number it is protecting against. Expected-case budgeting and no cap is how a scheme that succeeds becomes a scheme that loses money — a specific, avoidable form of revenue leakage, the same margin drain that quietly runs through high-volume, low-margin distribution.

Building the model

The model is not complex; it is disciplined. Build it the same way every time:

1. List each partner and their volume for the last comparable period. Start from what actually happened, not from a target — real distribution, partner by partner, on whichever measure the scheme rates (sell-in or sell-through).
2. Apply the slab table to that volume to get a baseline payout per partner. This is where the slab mechanics live — the rate table, and crucially whether it is all-volume (retroactive) or incremental. Do not re-derive them here; reuse the design.
3. Build three alternative volume assumptions per partner — conservative, optimistic, and a top-out case. Where you have many partners, group them (by tier, region or size) and model the groups rather than each name.
4. Apply the slab table to each assumption. Same table, different volumes, four payout figures per partner or group.
5. Total each scenario across all partners to get the four scheme-level costs.
6. Express each as a percentage of the revenue the scheme generates, not only as an absolute rupee figure.

That last step is what makes schemes comparable. Two schemes of different sizes cannot be compared on absolute cost; expressed as payout-per-rupee-of-revenue on the same basis, they can. The whole model is the claim arithmetic run forward on assumed volumes instead of backward on actual ones.

Where models go wrong

Five mistakes account for most bad scheme models:

• Using an average partner instead of the actual distribution. An "average" hides the partners sitting just below a threshold — the ones who will jump a tier and cost the most. The shape of the distribution is the whole point; the mean erases it.
• Forgetting the all-volume versus incremental basis. Whether the achieved rate applies to every unit or only to units above each threshold changes every number in the model. Model the basis the scheme actually uses.
• Ignoring returns. Returns and reversals inflate achieved volume before they are clawed back, so a model built on gross purchases overstates achievement and understates the clawback that follows.
• Ignoring partners just below a threshold. This is the group most likely to move and the most expensive when they do — a small nudge in volume, a large jump in payout. Model them explicitly rather than in an average.
• Modelling payout without modelling claim timing. A payout earned this quarter but claimed and settled next quarter lands the cash impact in the wrong period. If the model ignores when the claim settles, the cash forecast is wrong even if the cost is right.

From model to cap

The model is not an end in itself — it feeds the design. Once you can see the spread from conservative to top-out, three design decisions follow:

• A per-partner cap — a ceiling on any single partner's payout, useful when one large partner could dominate the cost.
• A total scheme budget — the aggregate the scheme cannot exceed, set with the worst-case row in view, not the expected one.
• A defined action if the budget is breached mid-period — what happens when burn-down says the scheme is tracking above budget before it closes.

The one rule that makes caps work: a cap only controls cost if it is in the published terms. A cap the partners never saw, produced at settlement to trim a payout, is not a control — it is a dispute. State the cap, and the action on breach, in the scheme agreement alongside the rate table and the base. A control discovered after the fact is not a control.

The link to accruals

The pre-launch model and the period-end accrual are the same arithmetic at two moments: the model estimates the cost before the scheme runs, the accrual estimates it during. A business that has modelled a scheme partner-by-partner already holds most of what it needs to accrue for it — the same rate table, the same volumes, updated for actuals as the period progresses.

The accounting treatment of that accrual — how and when it is recognised — is a matter for your accountant, and it is set out separately in the rebate-accounting article. This article takes no accounting position; it only observes that the modelling work and the accrual work draw on the same inputs.

<!-- TODO CA REVIEW: confirm this paragraph asserts no accounting position. -->

Doing this repeatedly

The value compounds when every scheme is modelled the same way. Modelled consistently — same scenarios, same percentage-of-revenue basis — a quarter's schemes become comparable, and the ones that cost the most per rupee of sales become visible before they launch rather than after. ClaimDS holds each scheme's rate table and accrues achievement against it as transactions land, so the pre-launch model and the live accrual run off one definition instead of separate spreadsheets. <!-- TODO: confirm capability wording with founder -->

General information, not accounting or tax advice. This article describes a commercial modelling practice. How a scheme accrual or payout is recognised in your accounts, and any tax consequence, depend on the facts and on current standards — confirm the treatment for your business with a qualified professional.

Read next

• Designing slab-based volume incentives — the rate table and the all-volume vs incremental choice the model runs on.
• How to calculate FMCG distributor claims — the same arithmetic, run backward on actual volume.
• Trade promotion budget: allocation and budget vs actual — tracking the budget this model sizes.
• Rebate accounting and GST credit notes — where the accrual treatment is set out.

---

Model the worst case before you launch, cap against it in the published terms, and a scheme that succeeds stays a scheme you can afford.

<!-- TODO: confirm capability wording with founder -->

Book a demo to see how ClaimDS models a scheme against your own partner base and accrues it from one rate table.