Why we published an unedited walkthrough
Most retail software demos show you eight seconds at a till and a dashboard with attractive numbers on it. Both are easy to produce and neither tells you anything, because the till screen is the simplest part of any retail system and the dashboard is only as honest as the data underneath it.
So we recorded the whole day instead, in order, without cutting the slow parts. Receiving a supplier delivery is not exciting. Neither is setting a reorder level or explaining why the cashier cannot see what you paid for a laptop. Those are the parts that decide whether a system is still telling you the truth six months in, which is why they are in the video and why this article follows the same order.
Watch it with your own shop in mind. The useful question is not whether the software can do something, it is whether it does that thing in the number of taps your staff will actually tolerate on a busy Saturday.
The sale: one action, four things happen
A customer buys a laptop. The cashier finds the item, scans or picks the serial number, takes the payment and hands over a receipt. On screen that takes a few seconds.
Underneath, four things become true at once. The shop has one fewer laptop in that specific branch. The money is recorded against the correct payment method. The revenue and the cost of that specific laptop are posted to the accounts. And that serial number is now attached to that customer's name.
This is the whole difference between an ERP and a till app. A till app records the payment and leaves the other three to be reconstructed later, usually in a spreadsheet, usually by the owner, usually at night. Here there is nothing to reconstruct, because the sale and the record are the same event.
- Stock drops in the branch that sold it, immediately and visibly.
- The customer's account and credit balance update on the spot.
- Revenue, tax and cost of goods post to the accounts without a second entry.
- The serial number moves from your stock to that customer's history.
Serial numbers and IMEI: the feature that pays for itself at the counter
If you sell phones, laptops, generators, batteries or spare parts, this is the section of the walkthrough to pay attention to. Every unit is recorded individually, from the supplier delivery it arrived on through to the invoice that sold it.
The payoff shows up in two situations that every dealer knows. A customer returns eleven months later with a fault and a claim. Instead of hunting for a receipt, you search the IMEI and you have the sale date, the price, the warranty position and which supplier it came from. And when stock is counted, a shortfall is a specific serial number rather than a number in a column, which changes the conversation with the person responsible from a dispute into a fact.
One piece of honest advice from implementations: serialise what has a warranty, a resale value or a theft risk, and leave cables, adapters and accessories on ordinary quantity tracking. Trying to serialise everything makes the till slow and staff start working around it, which is worse than not doing it at all.
The buying side, where your margin is actually decided
Half the walkthrough is the part shop owners never ask to see and always benefit from most: purchase orders, goods receipt and supplier ledgers.
When a delivery arrives, it is received against the order that created it. Quantities that do not match are visible at the point of receiving rather than discovered later. The cost of each unit is captured as it enters stock, which is what makes profit per item a real figure instead of an estimate, and the supplier's balance updates so you know what you owe without calling them.
This matters because most shops in Kenya know their sales precisely and their costs approximately. Approximate costs mean approximate margins, and approximate margins are how a business that is busy every day ends the year with nothing in the bank. The moment the buying side and the selling side are in one system, gross profit stops being a guess.
- Purchase order, delivery and supplier invoice all reference each other.
- Short deliveries and price differences surface at receiving, not at month end.
- Unit cost captured on entry makes profit per item a fact, not an estimate.
- Supplier balances and statements are always current.
M-Pesa: the payment is easy, the matching is the point
Everybody demonstrates the same thing: the cashier enters the amount, the customer's phone prompts them for a PIN, the invoice turns green. That part works and it is not where systems differ.
The difference is what happens with money that does not follow the neat path. A confirmation that arrives a minute after the customer has left. A confirmation that arrives twice. A customer who simply pays the till directly without being prompted. In each case the money is real and it has to find the right invoice.
The walkthrough shows payments matching automatically to the invoice they belong to, and it shows what happens to the ones that cannot be matched: they wait in a queue for a person to clear, rather than being attached to the nearest plausible sale. That is deliberate. A system that guesses is a system that will one day tell you a customer paid when they did not.
KRA eTIMS at the counter, not at month end
eTIMS compliance is now a baseline requirement rather than a feature, so the question is not whether a system supports it but when it does the work.
In the walkthrough the tax invoice is produced as part of the sale. The customer leaves with a compliant invoice in hand. There is no separate exercise at the end of the month where somebody compiles sales into a filing tool and discovers that the figures do not tie back to what the till recorded.
The detail worth asking any vendor about is what happens when the connection to KRA is momentarily unavailable. The correct behaviour is that the sale still completes and the filing queues, then goes through when the line returns. A till that stops trading because a government endpoint is slow is not a compliance feature, it is a liability.
Who can see what, and why owners ask this first
The single most common question we get in a retail demo has nothing to do with speed or features. It is whether the cashier can see what the owner paid for the goods.
The answer is that it is controlled, deliberately, and it is set up properly during implementation. Buying prices, supplier records, stock valuation and margin reports sit behind roles. A cashier sees the selling price, the customer and the stock position. A supervisor sees more. The owner sees everything.
The same principle covers discounts and refunds. Both are the most common source of quiet losses in a small shop, and both should require approval rather than trust. In the walkthrough you can see a discount beyond the allowed limit being stopped and sent for approval, which is exactly the moment the system stops being a record keeper and starts being a control.
- Cost prices, supplier records and margin reports are role-restricted.
- Discounts beyond a set limit require approval before the sale completes.
- Refunds are documented and attributable, not an informal till adjustment.
- Every entry carries who made it and when, so nothing is anonymous.
Closing the day with numbers you can trust
The last part of the walkthrough is the close: today's sales, cash and M-Pesa collected, what each branch moved, profit per item, stock valuation and what has dropped below its reorder level.
None of these reports are compiled at the end of the day. They are simply readings of records that were written correctly as the day happened, which is why they are available at five o'clock instead of on the fifteenth of next month. That is the practical case for running a shop on an ERP rather than a till: not that the reports are prettier, but that they exist while you can still act on them.
A shop owner who knows on Tuesday that a line is not moving can discount it on Wednesday. A shop owner who finds out in the following month's accounts has already paid to store it for a month.
What it costs and how to start
UpeoRetail is a one-off licence of KES 80,000. You own the system - it is not rented, and it does not stop working if you stop paying. The optional annual care plan of KES 24,000 covers cloud hosting, support and upgrades. Setup takes about a week, including migrating your existing item list and stock, and training your staff.
We would rather you watched the full walkthrough before you talked to us, because a shop owner who has seen the whole day asks much better questions than one who has seen a feature list. If your trade is electronics, computers, phones, hardware or motor spares, or anything else where units are serialised and valuable, the fit is close to exact.
If your trade is different - a pharmacy tracking batch and expiry, a bar tracking recipes and portions, a fashion shop tracking size and colour variants - the same ERPNext backbone applies with a different configuration, and we would talk to you about that rather than sell you the retail preset.
