A duka in Thika ordered twelve units of a 500 ml cooking oil line on a Tuesday. What arrived on Thursday was twelve cases, and the shopkeeper refused to sign. The rep had entered twelve against a code whose default ordering unit was the case, and the app had no reason to argue with itself.
In the same week a wholesaler in Nakuru was invoiced at a price withdrawn three weeks earlier. The new record existed. So did the old one, with no end date against it, and the system took the first match it found.
Neither of those is an ordering problem. Both are the product master and the price master telling the truth about how they were built. Most order errors are master-data errors wearing a different hat, and the useful part of that is they are fixable in one place.
Most Order Errors Are Master-Data Errors in Disguise
When an order goes wrong, the first instinct is to look at the person who placed it. Far more often that person did exactly what the system invited them to do, and the system was ambiguous.
Ambiguity lives in two tables. The product master says what you sell, how it is packed, how it converts and what rules attach to it. The price master says what it costs, for whom, where, through which channel and between which dates. Every order line is a lookup against both, and an ambiguous lookup makes the order a coin toss.
That matters more in Kenya than the diagram suggests. A brand serving dukas, kiosks, agrovets, mini-marts and wholesalers writes a very large number of very small order lines daily, so a rule that is wrong in one place is wrong everywhere at once.
A master is not a catalogue. A catalogue is a list you show people; a master is the one record the order app, the invoice, the pick list and the eTIMS submission all agree to obey. If the field app knows a line by one description and finance by another, you have opinions and a reconciliation job. What the master must carry for each sellable line is short:
- A code that never changes, and a description identical word for word in every system.
- Its place in the hierarchy, so it rolls up without anyone mapping it by hand.
- Every unit it can be transacted in, and the exact conversion between them.
- Its tax treatment, whether it is regulated, and whether it is batch and expiry controlled.
Getting the SKU Hierarchy Right
Most hierarchies get built by whoever needed a report first, which is why they describe last year's org chart rather than the product. A hierarchy that works has one job: to answer a question without a manual mapping step.
The layers that survive contact with a real Kenyan network usually run from division to category to brand to variant to pack. Division separates businesses that behave differently, say foods from agri-inputs. Category is how buyers think, brand is how marketing spends, variant is the formulation, and pack is what a duka owner points at.
Two rules keep it honest. Every level must be mandatory, because optional levels fill with blanks and blanks break every roll-up. And a SKU belongs to exactly one node; the moment a line sits in two places to make two reports work, your totals stop reconciling. Keep the code itself meaningless, too. Encoding the category into the SKU number feels tidy for a year, then becomes a trap, because categories get reorganised and codes must not.
Units of Measure Are Where Orders Break
The same product is bought, moved and sold in different units at every step. A supermarket buys pallets. A wholesaler in Kisumu buys cases. A duka on a route buys an inner or a few pieces. A van sales rep might sell all three off one vehicle in a morning.
If the master holds only one unit, somebody is converting in their head, and heads convert inconsistently. If it stores the conversion twice, the copies drift, and a rep answering the question the screen asked will be blamed for it.
The workable pattern is one base unit per SKU, usually the smallest sellable piece, with every other unit an exact multiple of it. Everything is stored in the base unit and displayed in whichever unit the person in front of you uses. Two guards prevent most of the damage: show the unit beside the quantity at the moment of entry, not on a confirmation screen nobody reads, and give each channel a sensible default, so the duka call opens on pieces and the wholesaler call on cases.
A Tuesday Morning in Nakuru
A distributor's depot on the edge of Nakuru starts loading at half past six. Three routes go out: one into town, one towards Naivasha, one on the longer run that reaches Eldoret. The same catalogue serves all three, and the agrovet counters buying a different set of lines from the same depot.
By nine the town rep is at a kiosk taking an order of a few pieces. By ten the wholesale rep is at an open-air market negotiating on cases. By noon somebody is at a supermarket branch where the buyer works from a listing sheet, quotes their own article number and expects an invoice matching it line for line.
Three sales, three units of measure, three price bands, one product master. If the master carries the conversions and the price master carries the channel bands with dates on them, none of those conversations needs a call to the office. If not, all three end with somebody promising to confirm later, and later is where orders die.
Duplicate SKUs and How They Breed
Duplicates are rarely created by carelessness. They are created by helpfulness. A new pack arrives and the existing code is locked, so someone opens a second one to get the shipment out. A distributor cannot find a line on the tablet and creates it locally.
Every duplicate splits the truth. Sales for one product sit under two codes, so the trend looks flat while both halves grow. Stock cover is wrong in both directions at once. And when a price changes, one code gets updated and the other does not.
- One creation path. Only the central master team creates a sellable code. Field and distributor systems may request but never create, and a queue that clears the same day removes the incentive to work around it.
- A duplicate check before saving. Match on the attributes that define the product, not the free-text description, because descriptions are typed differently every time.
- Retire, never delete. A discontinued line keeps its code with an end date, so history stays readable and the code is never reused.
Pack Variants Are Not the Same Product
Pack proliferation is the normal shape of an FMCG business serving informal trade. The single-serve pack that moves through kiosks is a different commercial animal from the family pack that sells through supermarkets, even when the contents are identical. Margins, velocity and channel fit all differ. Roll them together to keep the catalogue tidy and you lose sight of the small pack carrying the route while the large one quietly dies.
Promotional and combination packs need particular care, because they are temporary and they are where the master usually gets damaged. A seasonal bundle or refill offer should be its own code with a start and end date, linked to the parent variant so analysis still rolls up. Editing the base SKU's description to say a promotion is running looks harmless and permanently corrupts that line's history.
KEBS Marks and Other Regulated Attributes
KEBS, the Kenya Bureau of Standards, is Kenya's national standards body. For product lines covered by Kenyan standards, a standardisation mark on the pack indicates the product has been assessed against the relevant standard. Buyers in modern trade look for it, and it is routine in categories such as foods, agri-inputs, building materials and consumer goods.
The master-data point is narrower than the compliance question and worth separating from it. Your systems do not decide whether a line complies. They decide whether that information is recorded consistently, so the same answer appears on the invoice, the delivery note, the listing sheet and the audit query.
That argues for explicit fields on the SKU rather than a note in a comments box: whether the line falls under a Kenyan standard, which permit or mark reference applies, when it lapses, and who owns the renewal. A lapsed reference should be flagged before the next order is taken, not discovered by a customer. Take the requirements from KEBS directly, rather than reconstructing them from memory or copying them from a neighbouring market, which is how a wrong attribute gets replicated across a catalogue in an afternoon.
Batch and Expiry Belong in the Master
Whether a line is batch controlled is a property of the product, not a preference of the warehouse. If the warehouse decides, one depot captures batches and another does not, and you find out during a recall.
So the master should state, for every SKU, whether batch capture is required, whether expiry capture is required, and what the shelf-life rule is. Downstream systems then enforce it without anyone deciding case by case. Goods receipt asks for the batch, and the pick list respects first-expiry-first-out, because the product record says so.
This is not confined to pharma. Food and beverage lines carry expiry. Agri-inputs sold through the agrovet channel carry both expiry and seasonal relevance, and a variant that misses its window sits there until the next season's allocation lands on top of it. The payoff is easy to test: when a question arrives about a batch, you should be able to say which outlets received it and when.
The Price Master Is a Separate Discipline
Product data changes slowly. Price data changes constantly and has a legal edge, because the number that reaches the invoice is the number KRA sees through eTIMS. Since January 2026 KRA validates income and expenses declared in returns against eTIMS data, so a sloppy price master becomes your customer's accounting problem as well as your argument.
A price in Kenyan distribution is almost never a single number. The same SKU can carry a list price, a wholesale band, a modern-trade band and a route price, and it can legitimately differ by county, because the cost of getting stock to Kisumu is not the cost of getting it to Thika. All of that is normal. Holding it in a spreadsheet a regional manager emails around is not.
The structure that holds up treats price as a record with a scope and a life, not a field on the product. Each record answers four questions: which SKU, for whom, where, and between which dates. Scope may be a customer, a customer group, a channel, a county or a region, and the resolution order must be defined once and applied everywhere. A key account's negotiated terms then become a record rather than something a manager remembers.
Validity dates are the part most businesses skip, and skipping them produced the Nakuru credit note above. Every record needs a start date, and a superseded record needs an end date rather than deletion. Dating the change also lets you load it in advance: if a case moves from KSh 2,400 to KSh 2,520 on the first of the month, that figure should already be in the system, taking effect across every route at once instead of arriving as a message.
Where Master-Data Programmes Go Wrong
This work fails in recognisable ways, and almost none of them are technical.
They are about ownership, and about the gap between a cleanup project and a daily habit.
- Nobody owns it. Master data sits between sales, supply chain, finance and IT, so it belongs to none of them. Without one named owner who can say no, every request becomes a new code.
- A cleanup with no gate behind it. Teams de-duplicate a catalogue and change nothing about how codes are created. The duplicates return, and the second cleanup is harder to fund.
- Modelling every attribute anyone might want. Unmaintained fields are worse than absent ones, because people trust them. Start with what changes an order, an invoice or a pick.
- Letting distributors keep their own codes. The moment a distributor maintains a parallel catalogue, secondary sales stop reconciling to primary, and no reporting effort fixes it downstream.
- Changing prices faster than the field can sync. A price change is only real when every handset has it, and on thin routes that is not instant. Future-dated changes handle this; instant ones do not.
- Treating it as a project. Masters decay continuously, because the business changes continuously.
How 1Channel Supports Product and Price Master Discipline
Master data only helps if it reaches the counter, which in Kenya means a handset, sometimes with thin coverage and sometimes during a power interruption. 1Channel holds the product and price master centrally and pushes it to an offline-first field application, so the rep works from the same record the invoice will be raised against.
Because it is a distributor management and field sales platform rather than a standalone data tool, the master is enforced at the moment of use instead of audited afterwards. It confers no regulatory approval of its own; it records and applies what your compliance team determines. It lets a team:
- Maintain one central product master with a multi-level hierarchy and synchronise it to every device, distributor and depot, rather than letting local catalogues form.
- Define multiple units of measure per SKU with fixed conversions and channel defaults, so a duka order in pieces and a wholesaler order in cases resolve to the same base quantity.
- Restrict code creation to an approval workflow, with duplicate checks on defining attributes and retirement dates instead of deletions.
- Carry standards attributes against a SKU, including KEBS standardisation mark references and their validity dates, and flag lines whose references have lapsed.
- Enforce batch and expiry capture at goods receipt, dispatch and outlet level, and trace a batch to the outlets that received it.
- Hold KES pricing as dated records scoped by customer, customer group, channel, county or region, with a defined resolution order and future-dated changes.
- Feed the same description, unit and price into eTIMS-aligned invoicing and M-Pesa collection records, with role-based access and audit trails in line with Data Protection Act, 2019 obligations.
Key Takeaways
This is unglamorous work that quietly decides how many orders survive contact with a delivery van. A few principles carry most of the value:
- Treat order errors as data errors first. Before retraining a rep, check whether the master gave them an unambiguous answer.
- Store one base unit and exact conversions. Ambiguity between pieces, inners and cases is the most expensive gap in a Kenyan catalogue.
- Make duplicates hard to create, not just easy to clean. One creation path with a same-day turnaround removes the reason anyone works around it.
- Put regulated attributes on the SKU. KEBS mark references, batch rules and expiry rules belong in fields with owners and dates, not in comment boxes.
- Give every price a scope and a life. A price record without a customer, a geography and a validity window is a credit note that has not happened yet.
None of this needs a large programme. It needs one owner, a short list of fields that change an outcome, and a gate that holds when someone is in a hurry. Get that far and the boring reasons orders go wrong stop being weekly events.
