When Two Schemes Apply to the Same Sale: Resolving Scheme Conflicts

When a transaction qualifies under two schemes, there are four possible treatments. Both pay, only the higher pays, both pay subject to a combined cap, or one named scheme pays exclusively. No software can choose between them, because the choice is a commercial decision. The scheme terms have to state which applies before the transaction happens.

Throughout this article, scheme means a trade or channel scheme offered to distributors, dealers or stockists, and claims means distributor and channel claims.

The question nobody wrote down

A distributor buys a quantity that qualifies for a quantity purchase scheme. The same invoice also counts toward a quarterly volume rebate. And the product happens to be in a month-long promotional push carrying its own incentive.

Three schemes, one invoice. How much does the distributor earn?

The schemes themselves are each perfectly ordinary — the types of channel incentive a manufacturer runs are well understood, and calculating each one individually is routine. The difficulty appears only where they meet.

The uncomfortable answer for most companies is that nobody knows, because none of the three scheme documents mentions the other two. So the answer gets decided when the claim arrives — by whoever is calculating it, using judgement, under month-end pressure. That person is making a commercial decision about how much the company pays, and they are almost certainly not authorised to make it.

This is what a scheme conflict actually is. Not a technical problem, and not really a conflict between the schemes: a gap in the terms that someone downstream is forced to fill.

The four possible treatments

There are exactly four things that can happen when two schemes cover the same transaction. All four are legitimate. The problem is never which one you chose — it is not having chosen.

Treatment	What it means	When it is the right choice
Cumulative	Both schemes pay in full on the same transaction	When the schemes reward genuinely different behaviours you want at the same time — buying volume and running a display
Best-of	Both are calculated; only the higher-value one pays	When the schemes reward the same behaviour through different mechanics, and you want to guarantee the partner the better deal without paying twice
Capped combination	Both pay, but the combined payout cannot exceed a stated ceiling	When you want to reward stacked performance but need a known worst case for budgeting
Exclusive	One named scheme applies; the other is disapplied for that transaction	When one scheme is a special arrangement intended to replace standard terms, not add to them

Notice that the commercial cost of these differs enormously on identical sales. Cumulative and best-of can differ by the entire value of the smaller scheme. If that choice is being made by whoever calculates the claim, your trade spend has an unowned variable in it.

Notice also that best-of requires a stated tie-break. When two schemes calculate to the same amount, which pays? It sounds pedantic until it happens across hundreds of partners and two teams answer differently.

Where conflicts actually come from

Four patterns account for most of them, and they are worth distinguishing because they need different fixes.

Overlapping base

Two schemes measure the same underlying quantity without either acknowledging the other. A quantity scheme on cases and a volume rebate on the same cases both count the same purchase, so the same units earn twice — not because anyone decided they should, but because both schemes were written as though they were the only one.

This is the most common pattern and the easiest to prevent, because it is visible the moment anyone compares the two scheme bases side by side. It is missed because nobody does.

Different measurement layers

One scheme pays on what the distributor bought; another pays on what the distributor sold onward. These are primary and secondary sales, and the same physical goods pass through both.

Whether that is double payment depends on intent — rewarding purchase and rewarding sell-through are genuinely different things, and paying for both is often deliberate. But the terms rarely say so, and the two numbers arrive from different data sources at different times, which makes the overlap hard to see at all. Secondary scheme settlement is where this pattern most often hides, and in a multi-tier channel the same goods can pass three measurement layers rather than two.

Period boundaries

A monthly promotional scheme ends mid-quarter, inside a quarterly rebate period. A transaction in the overlap qualifies under both. When the quarterly scheme is settled, the promotional payment has usually already been made — and by a different process.

Boundary conflicts are the ones most likely to be found by a partner rather than by you, because the partner is watching a single account and you are watching a portfolio.

Special arrangements

A negotiated deal for one partner — a launch support package, a market-entry arrangement, a settlement of an old dispute — sits alongside the standard scheme structure. Was it meant to replace the standard schemes for that period, or add to them?

This is the pattern that generates the largest individual disputes, because special arrangements are agreed verbally more often than the rest and involve the partners with the most leverage.

Why software cannot decide this for you

It is worth being direct about this, because it is a reasonable thing to hope a system would handle.

Precedence is not a calculation. It is a statement about how much you intend to pay when two of your own offers overlap. A system has no basis on which to prefer cumulative over best-of, because both are arithmetically valid and the difference between them is entirely a matter of commercial intent. RebateLedger does not resolve scheme conflicts by inference, and a system that silently picked one treatment would be making a spending decision on your behalf.

What software can genuinely do is narrower and still valuable:

Apply a rule consistently once you have written it. A precedence rule recorded against the scheme terms gets applied the same way to every partner and every period, which is the part manual process fails at.

Flag transactions that qualify more than once. This is the real win. Detecting that an invoice satisfies the conditions of two live schemes is a mechanical check, and it is exactly the check people cannot reliably do at volume.

Make the overlap visible before the scheme is published, by comparing a proposed scheme's scope and period against live ones.

The distinction matters when you are evaluating any system for this. Ask whether it detects overlaps or resolves them. Detection is a genuine capability. A claim to resolve them means the vendor has chosen a default, and you should find out which one before it starts spending your money.

What to write into the scheme terms

The fix is one sentence per scheme, added at design time.

Every scheme document should state whether it combines with other schemes, and if so, which and on what basis. In practice that means one of:

• This scheme is in addition to standard volume schemes for the same period. (cumulative)
• Where a transaction also qualifies under [named scheme], the higher of the two applies; where both calculate to the same amount, [named scheme] applies. (best-of, with the tie-break)
• Combined payouts under this and [named scheme] are subject to a ceiling of [basis]. (capped)
• This scheme replaces standard schemes for the products and period stated. (exclusive)

Three practical notes.

Name the schemes, do not gesture at them. "Cannot be combined with other offers" is the wording consumer promotions use, and it is useless in a channel context — the partner will reasonably ask which other offers, and there is no answer. Name them, or name the category precisely.

State the base as well as the rate. Most overlapping-base conflicts are really base-definition failures. A scheme whose base says "qualifying purchases in the period" has not defined a base; one that says which transaction types, which products and which dates has.

Record it where it can be checked. A precedence rule agreed in a meeting and not written into the scheme agreement with effective dates is not a rule — it is a recollection, and it will be contested by whoever recollects differently. This is the same discipline that makes the rest of the claim lifecycle checkable.

The manual checks, and why they stop working

Most Indian FMCG companies handle this manually today, and the checks themselves are sound. There are four:

1. Overlap check before publishing — does this proposed scheme cover transactions already covered by a live scheme?
2. Base check — do any two live schemes measure the same underlying quantity?
3. Boundary check — do any scheme periods overlap partially rather than aligning?
4. Special-arrangement check — does this partner have a negotiated deal that the standard schemes should not stack onto?

Run properly, these catch nearly everything. The difficulty is not their quality but their arithmetic.

Checking one new scheme against five live ones is five comparisons. Against forty live ones it is forty — and it has to be repeated every time any scheme changes, across regions, product groups and partner tiers that each have their own scheme sets. The number of combinations grows faster than the team does.

So the checks do not fail by getting worse. They fail by being skipped under time pressure, or performed by someone who knows twelve of the forty live schemes well and the rest by name. And the failure is silent: an unnoticed overlap does not produce an error, it produces a claim that is slightly too large, settled, and discovered — if ever — during a year-end provision reconciliation months later. It is a recognised form of revenue leakage in rebate programmes, and one of the harder kinds to find, because every individual claim is defensible on its own terms.

Two things make this tractable at scale. Fewer, better-specified schemes is the first and least popular. The second is holding scheme scope as structured data — products, transaction types, dates, partner groups — so that the overlap comparison is a query rather than a memory exercise. That is what makes the check survive going from five schemes to fifty.

Book a demo if you want to see how scheme scope and overlap detection work on your own scheme set.

Before you publish your next scheme

1. List every live scheme covering the same products in the same period. If this list is hard to produce, that difficulty is the finding.
2. Compare bases, not names. Two differently-named schemes measuring the same cases are one conflict.
3. Decide the treatment explicitly — cumulative, best-of, capped or exclusive — and get it agreed by whoever owns the trade-spend budget, not by whoever drafts the circular.
4. Write it into the scheme document, naming the other schemes.
5. State the tie-break if you chose best-of.
6. Check the period boundaries against every scheme in the list, not just the obvious one.
7. Check the partner list for special arrangements that standard schemes should not stack onto.

General information. This article describes commercial practice in designing and settling trade schemes. It states no position on tax treatment, and quotes no rates, thresholds or scheme values — the right treatment for overlapping schemes is a commercial decision for your business. Any tax question arising from a scheme payout is covered in the dealer incentive tax checklist and should be confirmed with your own chartered accountant.

Read next

• Slab-based volume incentives — how scheme bases and thresholds are structured in the first place.
• Supplier rebate agreements — where the precedence rule has to be recorded.
• QPS: the quantity purchase scheme — one of the two schemes most often found overlapping another.
• Primary, secondary and tertiary sales — why measurement layers create invisible overlaps.
• Rebate clawbacks and scheme cancellations — what happens when a settled scheme payout has to be reversed.