Rule First: Overlapping Trade Promotions for One Store and SKU

Direct answer: For overlapping trade promotions covering the same store and SKU, decide one stacking or exclusion rule before either offer goes live, record it in the approved promotion version with its priority or cap and date range, and adjudicate any disputed claim against that recorded version. Two approved offers for the same store, the same SKU and overlapping effective dates is a governance problem before it is a payment problem. The claim will be paid or rejected on a rule that either existed before execution or is invented afterwards. Communicate that one rule to field and store, and do not resolve the claim from what a sales rep said on the day.

Why overlapping promotion eligibility becomes a claim dispute

Overlap rarely arrives by design. Common causes include a national offer extended while a retailer-specific activity started, a distributor-funded mechanic running inside a manufacturer-funded window, and a mid-quarter push created by a second team that did not check what was already approved for the store list.

At execution the field sees two offers available for the same outlet. The store hears whichever version reaches it first, or the more generous one. By claim time, finance holds two approved documents, sales holds a store expectation, and nobody holds a decision. The cost is not only the disputed amount — it is the precedent set by paying whichever claim was argued hardest.

This is different from logging a mid-campaign change to one promotion. Here the question is eligibility: when both offers are valid on paper, which one applies?

Choose the rule type and record it in the promotion version

There is no universal stacking policy. What matters is that the rule is written, approved and visible to everyone who executes or reviews the offer. Three workable patterns cover most situations:

Whichever pattern is chosen, write it in the promotion record: the rule type, the priority or cap, the exact date range it governs, and who decided it. A rule that exists only in a meeting is not a rule at claim review.

Lock the rule to a promotion version, not to a conversation

The stacking decision belongs inside the same approval that authorises the offer. That means the rule is versioned: it carries a version number, an effective date, the approver and a short reason for the change. If the rule changes after the offer goes live, that is a new version, not a clarification.

Three roles typically need to agree: trade marketing owns the commercial intent, finance confirms the funding exposure the rule implies, and sales operations maintains the version and distributes it. Where a distributor funds part of the mechanic, the distributor’s agreement to the rule should be recorded too, because the reconciliation will touch their money.

Versioning matters because the dispute is almost never about the arithmetic. It is about which document was in force on the purchase date. A dated version trail answers that question without reconstructing email threads.

How to decide and apply the rule before a claim

1. Confirm the overlap: same store, same SKU, intersecting effective dates, both offers approved.
2. Choose one rule type: exclusive, priority order, or additive with a cap.
3. Record the rule in the promotion record with the priority or cap, the exact date range it governs, and who decided it.
4. Approve the rule in the same version as the offer, with version number, effective date, approver and a short reason for any change.
5. Identify the funding owner for each offer, including any distributor contribution.
6. Brief field and store from the approved version, including a short script for which mechanic applies during the overlap and what happens after it ends; limit point-of-sale material to the mechanic in force and capture evidence tied to store, SKU, mechanic and date.
7. Update claim review so reviewers retrieve the approved version in force on the purchase date and apply the recorded rule.
8. Open an exception log with cause codes agreed in advance, logging store, SKU, date, offers involved, cause and outcome; review monthly to fix causes.

Worked example: which offer applies in a hypothetical store

The table below is illustrative, not a recommended policy. Assumptions: one retailer banner; offer A is a manufacturer-funded 10% discount on a 500ml SKU from 1 to 31 March; offer B is a distributor-funded buy-ten-get-one-free on the same SKU from 15 to 30 March; both are approved and the store is in scope for both; the approved plan states offer B outranks offer A and offers do not stack unless the plan says they do.

Communicate the chosen rule to field and store

A recorded rule that never reaches the outlet produces exactly the dispute it was meant to prevent. Practical steps:

• Restate the rule in one sentence on the offer sheet, the point-of-sale brief and the field briefing note.
• Give the rep a short script for the store: which mechanic applies during the overlap and what happens after it ends.
• Limit the store to the point-of-sale material that matches the winning offer for the period; two live mechanics on one shelf is an invitation to a double claim.
• Capture evidence tied to the store, SKU, mechanic and date, so the reviewer can see which offer was actually executed.

Review disputed claims against the approved version

When a claim arrives for two overlapping offers, review it in a fixed order: retrieve the approved version in force on the purchase date, apply the recorded rule, then compare the evidence. If the rule is missing or the briefing contradicted it, the claim moves to an exception path rather than being resolved by negotiation.

Log every exception with the store, SKU, date, offers involved, cause code and outcome. Useful cause codes include: rule not defined at approval, rule not communicated, rule changed without a new version, and evidence mismatch. Review the log monthly and fix the cause rather than the individual claim. An exception paid once becomes the expectation next quarter unless it is explicitly marked as a one-off decision with an approver.

Checklist before two offers go live on the same store and SKU

• Overlap confirmed: same store, same SKU, intersecting effective dates, both offers approved.
• Rule type chosen and written into the promotion record: exclusive, priority order, or additive with a cap.
• Funding owner for each offer identified, including any distributor contribution.
• Rule approved in the same version as the offer, with date and approver.
• Field briefing and store script issued, referencing the rule not the general offer.
• Point-of-sale material limited to the mechanic in force for the period.
• Claim review step updated so reviewers check the version in force on the purchase date.
• Exception log opened with cause codes agreed in advance.

Where trade promotion software helps, and what to verify

A documented rule still has to live somewhere a reviewer can reach it. Airpalm publicly describes mobile visits, route planning, store audits, sales orders, inventory and promotion management (airpalm.com, checked 9 October 2026). That public description does not establish that overlapping eligibility is detected automatically, that a particular stacking rule is enforced, or that promotion versions are held with approval history in a given deployment. Treat those as questions to verify rather than assumptions: ask for a demonstration of how a store-and-SKU overlap appears in the planning view, what happens to a claim when two offers are active, and whether a rule change creates a new version with an approver.

If you are tightening this process, the practical next step is to take your last three disputed overlapping claims and check whether a written rule existed, whether it was versioned, and whether the store was briefed from it. The gaps you find define what your promotion process needs next, whether or not software is involved.

Frequently asked questions (FAQ)

Can a store legitimately receive both offers when the dates overlap?

Only if the approved promotion record states an additive rule and defines a ceiling the reviewer can calculate. If the record states an exclusive or priority rule, only the winning offer is payable for the overlapping period, regardless of what the store was told at the time. The claim is settled against the approved version, and any briefing failure is handled as a logged exception rather than a change to eligibility.

Who should decide the stacking or exclusion rule?

Trade marketing typically owns the commercial intent, finance confirms the funding exposure implied by the rule, and sales operations maintains and distributes the approved version. Where a distributor funds part of the mechanic, their agreement should be recorded as well, because reconciliation will affect their money. The decision needs one named owner to avoid a rule that shifts between functions.

Should a field rep be allowed to choose at the store which offer applies?

Generally no. Store-level discretion makes the payable amount depend on who visited and when, which is difficult to audit and encourages repeat negotiation. If a genuine escalation is needed, define a route, a response deadline and an approver in advance, and record the outcome against the store and SKU so the same case is handled consistently next time.

What should happen if the overlap is discovered only after claims have been submitted?

Hold the affected claims rather than paying them, retrieve the approved version in force on each purchase date, and apply whichever rule it contains. Where no rule exists, treat the case as an exception with a named approver and a one-off note. Then correct the underlying gap so future overlaps are decided at approval, and record the cause in the exception log for review.

Does trade promotion software detect conflicting offers automatically?

Do not assume it does. Airpalm publicly describes promotion management alongside mobile visits, route planning, store audits, sales orders and inventory, but that description does not confirm automatic overlap detection or rule enforcement in a specific deployment. Ask for a demonstration of the actual supported scope, including how version history, role permissions and exception handling work, and what is standard versus configured.