The Discount Nobody Approved: Where Retail Margin Actually Goes
Discounting is the fastest way to give away a year of margin without a single missing item. Every shilling comes straight off profit, none of it touches your stock count, and in most Kenyan shops nobody can tell you who authorised any of it.
Shrinkage gets the attention. A missing carton is visible, countable, investigable — and it makes people angry. Discounting takes more money out of more Kenyan retailers than shrinkage does, and it does it in the open, one small kindness at a time, with a cashier's hand on the keyboard and nobody's name against the decision.
This is not an argument against discounting. Discounts move slow stock, keep good customers, and close a sale that would otherwise walk. It is an argument against untracked discounting, because the arithmetic is unforgiving in a way that most owners have never actually done on paper.
Do the arithmetic once and you never forget it
A discount is not a percentage off the price. It is a percentage off the margin, and those two numbers are very far apart on a retail item.
A 10% discount on an item with a 25% gross margin
A tenth off the price is two fifths off the profit. To earn back that one discount at full price you need to sell the item roughly another two thirds of a time over. The cost figure never moves, which is exactly why the damage is invisible in a stock report: nothing is missing, the shelf is right, the count is right, and the profit is gone.
Shrinkage shows up as a hole in your stock. Discounting shows up as nothing at all.
Why one gets investigated and the other does not
How a discount is actually recorded at our till
Precision here matters, because the shape of the field determines the shape of the control.
- The discount is entered per line, as an amount per unit, and it is multiplied by the quantity on that line.
- It is capped at the line subtotal, so a line can never go negative no matter what is typed.
- The line is pre-filled from the item itself: an item can carry a configured discount value, or a discount percentage applied to its selling price. The value wins where both are set.
- That pre-filled figure is then freely editable at the counter. There is no maximum, no percentage ceiling, and no approval step.
- The discount reduces the taxable base — tax is computed on the discounted amount, which is correct, and means a discount also reduces the VAT you charge and remit.
- The cost of the item does not change, so the entire discount lands on margin.
- Every line discount is stored on the sale line, summed onto the sale, and totalled in the POS sales summary report.
So the catalogue-level discount is a genuine control: set a promotional price on the item once and every counter applies it consistently. The gap is what happens when someone changes that figure at the counter.
Where the trail stops
Here is the part we are not going to dress up. There is a table in the schema built precisely for authorised discounts — it can hold a discount against a whole sale or a single line, with a description and an amount. Nothing writes to it. The discount that reaches a sale today is a bare number on a line with no reason attached to it.
Discount controls: what exists, what does not
| Control | Available today |
|---|---|
| A promotional price or percentage set once on the item and applied at every till | Yes |
| A per-line discount amount recorded on the sale and visible on the receipt | Yes |
| Discount totals per period in the sales summary report | Yes |
| A hard cap so a line cannot be discounted below zero | Yes |
| Correct tax treatment — tax charged on the discounted amount | Yes |
| The sale, cashier and counter attached to every discount, since it lives on the sale | Yes |
| A reason code or description required on a counter discount | No |
| A supervisor approval step above a threshold | No |
| A maximum discount percentage per item, category or cashier | No |
| A whole-sale discount as its own recorded object rather than spread across lines | No |
| A separate permission for discounting, distinct from the permission to sell | No |
| Discount included in the POS sales CSV and PDF export columns | No |
Built and maintained Configurable by you, not maintained by us Not built
The last row is the smallest and most annoying gap: discounts are totalled in the on-screen summary, but the sales export columns run subtotal, tax, total, paid and balance — so a discount analysis today means the summary screen rather than a spreadsheet.
What to do while the reason code does not exist
Every one of the gaps above can be substantially closed with policy and reading, and none of it requires waiting for us. The controls that actually work in Kenyan retail are boring and cheap.
-
Move real discounts into the item, not the counter
If a product is on promotion, set its discount value or percentage on the item. Every till then applies the same figure automatically, the promotion ends when you clear the field, and no cashier has to remember anything. This single move removes the majority of legitimate counter discounting.
-
Set a spoken ceiling and make it specific
A rule like "no discount above 200 shillings or 5% without the supervisor" is enforceable by reading, even without a technical block. A rule like "use your judgement" is not a rule.
-
Read discount totals per cashier, weekly
Absolute totals mislead — a busy till discounts more. Read discount as a percentage of that cashier's sales. One cashier at 4% against a floor average of 0.9% is the whole finding, and it takes two minutes to see.
-
Ask about the outliers without accusing anyone
Most of what you find is not theft. It is a cashier who has been told to keep customers happy, or one who does not know a promotion ended, or a damaged-stock workaround nobody documented. All three are fixable once visible.
-
Stop using discounts as a workaround for something else
Damaged goods, price errors and goodwill on a faulty item are three different events with three different correct records. Pushing all of them through the discount field destroys your ability to see any of them.
Rating your own discount exposure
Five questions, weighted by how much money hangs on the answer
Answer honestly rather than aspirationally. The purpose is to find where your money is going, not to score well.
Can you state your total discount as a percentage of sales for last month?
Make them prove it: Open the sales summary for the period and read the discount total against total sales. If nobody has ever looked, that is the answer.
Are your promotional prices held on the items, or typed at the counter?
Make them prove it: Pick three items currently on promotion and check whether the discount is configured on the item record.
Do you know which cashier discounts the most, adjusted for their sales volume?
Make them prove it: Compare discount as a share of sales, per cashier, over four weeks — not the raw totals.
Is there a stated ceiling above which a cashier must ask?
Make them prove it: Ask two cashiers separately what the limit is. Different answers mean there is no limit.
Are damaged goods and price corrections handled as discounts?
Make them prove it: Ask what a cashier does when an item is dented. If the answer involves the discount field, your discount figure is measuring three things at once.
What we do and do not do
What AWRA OpsHub does today
- A discount value or percentage configurable on each item, pre-filled automatically at the counter.
- Per-line discounts recorded on the sale line and summed onto the sale.
- A hard cap preventing a line from being discounted below zero.
- Tax computed on the discounted amount, so VAT charged reflects what the customer actually paid.
- Discount totals for any period in the POS sales summary, filterable alongside subtotal, tax and total.
- Every discount inherently attributable to a sale, a cashier and a counter, because it is stored on the sale.
What it does not do
- A required reason code or description on a counter discount — the schema has a place for it; nothing populates it.
- Supervisor approval above a threshold.
- Maximum discount limits by item, category, cashier or role.
- A separate permission for discounting, distinct from the permission to use the till.
- A sale-level discount recorded as its own object rather than distributed across lines.
- Discount columns in the POS sales CSV and PDF exports.
- Automatic margin alerts when a discount pushes a line below cost — the cap stops a negative price, not a below-cost one.
A reason code with a required description, plus a threshold that asks for a supervisor, is the smallest change on this list and the one that would close most of the gap. If discount leakage is your live problem, say so and it moves up the queue rather than sitting behind features nobody has asked for.
Our take
Discounting is the leak that never triggers an investigation, because nothing goes missing. Put your real promotions on the item records where they apply themselves, set a ceiling people can repeat back to you, and read discount as a percentage of sales per cashier once a week. Those three habits recover more margin than any technical control, and they work today — while the reason code and the approval threshold are honestly still on our list rather than in our product.
The neighbouring mechanics are worth reading alongside this: tax-inclusive pricing at the till explains why the discount changes your VAT, returns and exchanges covers the damaged-goods route that discounting is often standing in for, and counters, cashiers and the handover explains why every discount already has a name attached to it.
See where the margin actually went
Promotional prices held on the item, every line discount recorded against a named cashier and counter, and discount totals for any period you care to look at.
See POS in AWRAFrequently asked questions
Can we stop cashiers giving discounts altogether?
Not with a switch today. There is no separate discount permission — anyone who can use the till can enter a line discount, and there is no maximum or approval threshold. What you can do is set your genuine promotional prices on the item records so the correct discount applies automatically, then treat any counter-entered discount as an exception to be read weekly. Most shops find that removes almost all legitimate reasons for a cashier to touch the field, which makes the remainder easy to spot.
Is the discount a percentage or an amount?
At the counter it is an amount per unit, multiplied by the line quantity and capped at the line subtotal so a line cannot go negative. On the item record you can configure either a discount value or a discount percentage of the selling price — the value takes precedence where both are set. The percentage is resolved to an amount when it pre-fills the line.
Does a discount reduce the VAT we charge?
Yes, and that is correct. Tax is computed on the line amount after the discount, so a discounted sale charges proportionally less VAT. It also means a large volume of untracked discounting quietly reduces your output VAT, which is another reason the total is worth reading rather than ignoring — your tax figures and your margin figures are moving together.
Where do I see how much we discounted last month?
In the POS sales summary report, which totals discounts for the period alongside subtotal, tax, total sales and average sale, and can be filtered. What it will not do yet is put a discount column in the CSV or PDF export of sales, so per-cashier analysis over a long period is on-screen work rather than spreadsheet work. That export column is a small gap and a fair thing to ask us for.
Can a discount push an item below its cost?
Yes. The cap stops a line going below zero, not below cost. Nothing warns you that a discounted line is now unprofitable, and because the cost of the item never changes, the whole discount lands on margin. If you sell items with thin margins, a spoken ceiling per category matters more than it does in a high-margin trade.
Is there any record of who authorised a discount?
There is a record of who rang the sale — the cashier and counter are attached to it — but no record of who authorised the discount or why. There is a table in the schema designed for exactly that, holding a description and an amount against a sale or a line, and nothing currently writes to it. Being straight about it: a required reason and a supervisor threshold above a limit is the change that would close this, it is small, and it is not built yet.
