POS system pricing in Kenya: what to expect

A point-of-sale system should make your counter faster and your end-of-day numbers honest. In Kenya the trick is handling cash and M-Pesa cleanly in the same till. Here is what POS costs in 2026 across the realistic options, the two tests that decide whether a system will work here, and how to think about the trade between a subscription and a build.

Your three options

Hardware is separate: a tablet or laptop, a receipt printer at roughly KES 8,000 to 20,000, and optionally a cash drawer and scanner. Plenty of small shops run perfectly well on a tablet to start, and adding hardware later is easy. Adding a workflow the software cannot do is not.

The M-Pesa test

This is the single biggest weakness in foreign-built POS systems here. If the system cannot record an M-Pesa sale as M-Pesa, verifying the transaction rather than letting a cashier key it in as cash, your end-of-day report will never balance. It is not a reporting inconvenience: it is the difference between knowing your takings and estimating them.

Ask for a demo of exactly this: a sale paid by M-Pesa, from the till prompt through to the daily report, with the transaction verified along the way. Watch whether the cashier has to type anything the system could have confirmed for itself. Every keystroke there is a place where the numbers drift.

The offline test

The network will drop and the queue will not wait. A till that stops selling when the connection goes is not a till, it is a website. Ask what happens to a sale rung up while offline, and specifically what happens when two branches reconnect at once having both sold the last of an item. A good answer describes a queue that replays in order and a rule for resolving the conflict. A vague answer means nobody has tested it.

A worked comparison

Suppose you run two tills. Compare a cloud subscription at KES 6,000 per till per month against a custom build at KES 180,000:

The crossover here lands somewhere in year two, and it moves earlier with every till you add, because the subscription scales per till while the build does not. That is the whole argument. If you are running one till and testing an idea, subscribe. If you are running three and plan on five, the arithmetic stops being close.

Hardware, and what you can skip

Hardware is where a POS budget inflates fastest, usually on things a small shop does not need in month one. What earns its place, and what can wait:

A phone or tablet plus a printer runs a small shop perfectly well. Scanners pay for themselves when the queue is long and the catalogue is barcoded, and not before. The item people forget is power: a till that dies with the lights takes your afternoon takings with it if the sale was not saved locally.

Moving off your current system

Switching tills is the part that worries owners most, and reasonably so, because it happens while the shop is trading. The work is mostly preparation rather than technology:

• Do a full stock count first. Migrating an inaccurate count just moves the inaccuracy into a nicer interface.
• Export your product list, prices, and supplier details from the old system while you still have access to it.
• Cut over on your quietest day, not the first of the month, and keep the old system readable for a while.
• Run both for two or three days if you can, and compare the daily totals. That comparison is the only real proof the new one is right.
• Train the cashiers before cutover, not on the morning of it.

Other things that matter

• Inventory sync: stock should decrement with each sale and warn you before you run out, not after.
• Multi-branch: if you have or plan more than one location, you want one shared stock count and combined reporting.
• Ease of training: if a new cashier cannot learn it in an afternoon, it is the wrong system, whatever else it can do.
• Your data: ask how you would get your sales history out if you left. If the answer is awkward, factor that in now.

What a POS will not fix

Worth saying plainly, because a new till gets bought to solve problems it cannot touch. A POS records what happened at the counter accurately. It does not change what happens there.

• Shrinkage. Better records make theft visible sooner, which is genuinely useful, but visibility is not prevention.
• Bad buying. The system will show you that a line has not moved in four months. Acting on that is still your job.
• Staff who work around it. If ringing a sale properly is slower than not doing it, some sales will not be rung properly. That is a process and training problem, and it is the most common reason a good system produces bad numbers.
• Cash discipline. A drawer that is short is short whether or not the software knows.

Where a POS earns its money is the hour a day somebody currently spends reconstructing the day from receipts and M-Pesa messages, and the ordering decisions you can finally make from real numbers instead of memory.

The question to ask yourself first

What decision would you make differently if you had accurate daily numbers? If the honest answer is none, a cheaper till will do. If the answer is that you would reorder differently, staff differently, or drop a product line, then the reporting is the thing you are buying and the hardware is incidental. Buy for the report, not for the screen.