The circular goes out on a Monday. A new scheme on a single pack size, three slabs, live to the end of the cycle. By Wednesday it exists in four versions: the one in the circular, the one a billing clerk has keyed in, the one a rep has copied onto a route sheet, and the one a duka owner in Nairobi believes he was promised.
Trade schemes are how Kenyan brands move volume through a channel they do not own. They fund a launch, clear ageing stock, or defend a pack size against a competitor. Designed well, a scheme changes what a shop orders. Designed badly, it changes what a shop argues about.
The difference is rarely the generosity of the offer. It is whether the offer resolves to the same answer for everyone who touches it. A scheme that a rep has to calculate by hand is a scheme that will be applied inconsistently, and inconsistency at the counter becomes a claim dispute weeks later.
What a Scheme Has to Do at the Counter
A trade scheme is a conditional price. Conditions are met — a quantity, a value, a pack mix, a channel — and the price or the goods change. Everything else in scheme management is machinery that makes that condition testable at the moment an order is taken.
Three parties have to reach the same number: the rep who promises it in the shop, the system that raises the invoice, and the finance team that settles the claim after the cycle closes. When they diverge, the real cost is not the discount but the reconciliation, the withheld payment, and a distributor who starts treating every future scheme as a negotiating position.
Value, Volume and Free Goods
Almost every scheme running in Kenyan trade is one of three shapes, or a combination of them.
- Value schemes — the reward turns on crossing a KSh threshold of invoice value. Easy to explain across a mixed portfolio, but indifferent to what was bought. Good at lifting order size, poor at directing mix.
- Volume schemes — keyed to quantity: cartons, cases or units of a named SKU or brand. Slower to explain, far more precise, and the right instrument when the objective is a specific pack rather than a bigger bill.
- Free goods — the reward is paid in stock. To take a purely illustrative shape: buy ten cartons of a pack size, receive one free. Popular in general trade because the benefit is visible and the shelf price stays undisturbed.
Free goods carry complications the other two do not. The free units must exist in the warehouse when the order is booked, must appear on the tax invoice defensibly, and consume stock forecast as saleable. A scheme that runs out of the free item mid-cycle is worse than no scheme at all.
Slabs, and How They Change Ordering
A slab is a band. Buy up to a certain quantity or value and one reward applies; cross into the next band and a better one does. Slabs are how a brand tries to buy incremental volume rather than paying for volume that was coming anyway.
Two structures are common, and they pay out differently on the same order, so which one is in force must be stated rather than assumed. In a whole-order slab, reaching a band applies that band's reward to the entire qualifying quantity. In an incremental slab, each band's reward applies only to the units falling inside it. The first is easier for a rep to explain and costlier at the edges; the second models better and is harder to sell in a doorway.
Slabs also want a minimum and a maximum per band, and the maximum matters more than teams expect: without a ceiling, one wholesaler order can absorb a whole cycle's promotional allowance. Edges change behaviour, which is both the point and the risk. A duka owner two cartons short of the next band will find room for two cartons — genuine uplift the first time, and by the third cycle simply loading, with stock ageing in a back room in Thika and reported as growth.
SKU Level Versus Category Level
Scope decides what the money actually buys. Category-level schemes are quick to configure and blunt: they reward the whole basket, including lines that were selling perfectly well without help.
SKU-level schemes are the precise instrument. A newly launched variant that needs distribution. A larger pack a competitor is attacking on price. A slow-moving flavour with dated stock in the depot. An agrovet pack that only moves in the weeks around planting. None of those can be reached by a scheme written at category level.
SKU-level scoping has a prerequisite that derails more programmes than the scheme logic ever does: a clean product master. Every pack must exist once, with a stable code, a defined pack configuration and correct unit conversions between piece, dozen and carton. If two systems disagree on how many units make a carton, a volume slab resolves differently on each — and the argument gets blamed on the scheme.
Validity Windows and the Edges of a Cycle
Every scheme needs a start and an end, expressed as dates and understood in East Africa Time. The end matters more: schemes nobody formally closed quietly become permanent price cuts.
The subtler question is which date governs: the date the order was taken, or the date the invoice was raised. In van sales they are the same moment. In pre-sales they are not — an order booked on the last day of a cycle may be invoiced inside the next. Whichever rule is chosen must be the same rule in the field application, the billing system and the claim reconciliation. An order placed inside the window and billed outside it is the most common scheme dispute there is.
Retro-dating deserves its own rule, because extending a scheme backwards over billed orders reopens documents already inside the tax invoice trail and teaches the channel to wait rather than buy.
Deciding Who a Scheme Is For
A scheme aimed at everyone is usually aimed at no one. Kenyan trade offers several axes to target on.
- Channel type — a slab built for a duka or kiosk should not fire on a supermarket order, and an agrovet scheme timed to planting has no business on a petrol-station forecourt.
- Trade tier — distributors, sub-distributors, wholesalers and retail outlets buy in very different quantities, and one slab table rarely fits more than one of them.
- Geography and history — a route or beat where a position is being defended around Kisumu or Eldoret, or outlets that have never stocked the SKU.
All of it has to be resolvable by a machine at the moment of order entry. Described in prose — "for our better-performing upcountry retailers" — eligibility is an opinion, and every rep will resolve it differently.
Stacking, Conflict and Precedence
Kenyan brands rarely run one scheme at a time. A cycle value scheme, an SKU volume scheme on a new pack and a distributor-funded local push can all run in the same week, and a single order can qualify for several at once. What happens then is a policy decision, not a technical one.
- Do schemes stack? If two apply, does the order receive both benefits or only the better one?
- What is the base? If a discount computes on invoice value, is that before or after tax, and before or after any discount already applied?
- Which one wins? A declared precedence order settles ties without escalation. Undeclared, the answer is whatever the system evaluates first.
- What is mutually exclusive? A launch offer and a clearance offer on the same pack should never combine.
- Is there a ceiling? A cap on total benefit per order, outlet or cycle is the only safeguard against a combination nobody modelled.
Funding is the quiet part of the same question. A brand-funded scheme and a distributor-funded one can look identical on the invoice and settle to entirely different ledgers, so the funder has to be tagged when the scheme is created.
Applying the Scheme at Order Entry
This is where the argument lands. If the rules live in the order-capture application and fire automatically, every rep applies the same scheme the same way, and the order document becomes the record of what was promised. If they live in a circular, the scheme is only as consistent as the arithmetic of whoever is holding the route sheet that morning.
Auto-application also turns a scheme into a selling tool rather than a settlement obligation. A rep who can see that the order in front of her is two cartons short of the next slab has something specific to say to the shopkeeper.
One Kenyan condition is not negotiable. Coverage upcountry is uneven and mains power is not always dependable — the country had a nationwide outage in 2026 — so scheme rules have to sit on the device and evaluate without a connection, syncing when the network returns. An engine that only works online fails in exactly the territories where a rep cannot phone the office and ask.
A Thursday Round Out of Kisumu
Picture a Thursday round out of Kisumu: dukas on residential streets, kiosks near the market, a mini-mart on the main road, and an agrovet on the way towards the farms.
At the third duka the owner knows a scheme is running. The rep has the slab table, but two schemes overlap on the order in front of him — a value scheme on the whole invoice and a free-goods offer on one pack size. He works out an answer, quotes it, and the shopkeeper pays by M-Pesa on the spot. An hour later at the agrovet, a second rep facing the same combination reaches a different answer, because he applies the value discount to a different base.
Neither rep has done anything wrong. Both have done arithmetic the scheme design left to them. The consequence surfaces after the cycle closes, when the distributor's claim does not match the brand's computation and a payment sits unsettled while two teams rebuild the month from invoices.
Settling the Payout After the Cycle Closes
Application and settlement are different events. Application is what happens on the order: the discount computed, the free goods added. Settlement is what happens afterwards — who reimburses whom, on what document, and when.
A discount taken on the invoice needs no settlement between distributor and outlet, but it still needs one between brand and distributor if the brand funded it. That is usually a credit note raised on an approved claim, and it is the cleanest instrument because it sits inside the tax document trail.
eTIMS makes that distinction consequential. KRA has required electronic tax invoices through eTIMS since January 2024, for businesses across the trade including those not registered for VAT, and from January 2026 income and expenses declared in income tax returns are validated against eTIMS data — an expense without a valid eTIMS invoice is not deductible. Scheme discounts, credit notes and the value of free goods therefore belong on the electronic documents, not in a side spreadsheet.
Where a settlement moves as money it moves by M-Pesa or bank transfer, and must tie back to the claim and the orders underneath it. The reconciliation should be a comparison, not a reconstruction — the distributor's claim on one side, the computed entitlement from actual order lines on the other, and the difference itemised down to the order.
Where These Programmes Go Wrong
The most expensive failure is the ambiguous base. A scheme that applies a discount to invoice value, without saying whether that is before or after tax and before or after any other discount, will be computed at least two ways within a week. Beside it sits the undeclared precedence rule, which turns every overlapping scheme into a judgement call made by the person with the least information.
Then the operational ones. Schemes with no end date that become permanent price cuts by default. Free-goods offers launched without reserving the free stock. Claims assembled by hand on both sides, so reconciliation becomes a rebuilding exercise with working capital idle while it runs.
And the structural one: designing a scheme in a head office and communicating it as a document. Every hop between design and counter — the circular, the forwarded message, the billing clerk's interpretation, the rep's mental arithmetic — lets the rule change shape, until the scheme running in the market is not the scheme that was approved.
How 1Channel Supports Scheme Management
1Channel's sales scheme management is configured in the admin portal and executed in the field application, so the rule a brand manager approves is the rule that fires on the order. Volume, value and free-goods schemes are all supported, including multi-slab buy-X-get-Y structures with minimum and maximum quantities defined per slab.
Scope and eligibility are set when the scheme is created. A scheme can target a category, a brand or an individual SKU, and can be mapped to store lists drawn from the store master — distributors, sub-distributors, duka and kiosk lists, or supermarket and modern-trade accounts — so a slab built for one channel does not fire on another. Funding tags separate brand-funded from distributor-funded schemes, and new schemes pass through a workflow approval before any outlet sees the offer.
In the field, mapped schemes cache on the rep's device after sync and apply automatically at order capture, including offline in upcountry territories; the order, claim and settlement queue upload when the device reconnects. Each redemption is recorded against the order line as it happens.
On settlement, approved claims post as scheme credit notes to the distributor ledger and into the electronic invoice trail KRA administers through eTIMS, and cash settlements can run through M-Pesa or Pesalink. 1Channel is not a certifying body and makes no certification claim; the platform is designed to align with those obligations and to keep the document trail a distributor needs.
Key Takeaways
A scheme programme is only as reliable as its weakest resolution point — almost always a person doing arithmetic under time pressure in front of a customer.
- A scheme a rep calculates by hand will be applied inconsistently. Move the rules into order capture so they fire automatically, and the order becomes the record of what was promised rather than one party's recollection of it.
- Scope decides what the money buys. Category-level schemes pay for volume the brand already had; SKU-level schemes reach the pack that needs help, but only if the product master is clean and unit conversions agree across systems.
- Stacking and precedence are policy decisions, not technical ones. Declare the base, the precedence order, the exclusions and the ceiling before schemes go live, or the answer becomes whatever the system evaluates first.
- Validity is about which date governs, not just the end date. Order date or invoice date must mean the same thing in the field app, the billing system and the claim, because orders booked at the edge of a window are the most disputed of all.
- Settlement belongs on the tax documents, not in a spreadsheet. With KRA validating declared expenses against eTIMS data, scheme credit notes and the value of free goods belong in the electronic invoice trail, and every claim should reconcile down to the order lines that created it.
None of this needs a larger promotional programme. It needs the schemes already running to be written so they resolve identically in every shop — the same base, the same precedence, the same dates, applied by the system rather than from memory. Do that and the conversation after the cycle closes is about whether the scheme worked.
