Skip to content
All posts

Pricing

POS system pricing in Kenya: what to expect

· 5 min read

A point-of-sale system records what happens at the counter and produces the numbers you reconcile against at the end of the day. In Kenya the constraint that matters most is handling cash and M-Pesa in the same till without either being guessed at. Here is what POS costs in 2026 across the realistic options, the two questions worth asking any vendor, and how the trade between a subscription and a build works out over time.

Your three options

OptionCost (KES)The trade
Cloud POS, subscription2,000 to 10,000 per till, monthlyFast to start, limited to how the vendor built it
Licensed software, one-off30,000 to 150,000 upfrontYou own it, but updates can lag
Custom build80,000 to 250,000+Fits your workflow and carries no per-till fee; larger upfront cost, and you carry the maintenance

These are planning figures for a first budget. 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. Many small shops start on a tablet alone, and hardware can be added later. A workflow the software was not built to support is much harder to add later.

The M-Pesa test

This is a common weakness in POS systems designed for card-first markets. Where the system cannot record an M-Pesa sale as M-Pesa, verified against the transaction rather than typed in by a cashier, the daily split depends on cashier accuracy and reconciliation becomes an estimate rather than a check.

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

Where the connection is unreliable, a till that cannot record a sale offline will stop the queue when the connection drops. 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 complete answer describes a queue that replays in order and a defined rule for resolving the conflict. If the answer is vague, ask to see it demonstrated.

A worked comparison

An illustrative example, not a quotation. 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:

Cloud POSCustom build
Upfront0180,000
Monthly, two tills12,0001,500 (hosting)
Year 1 total144,000198,000
Year 2 cumulative288,000216,000
Year 3 cumulative432,000234,000
Adding a third till+6,000 monthlyOne-off, usually small

On these figures the crossover lands in year two, and it moves earlier with each additional till, because the subscription scales per till while the build does not. That is the trade. At one till, a subscription is usually the lower-cost and lower-risk option; as till count rises, the arithmetic moves toward a build. Where your own crossover falls depends on the per-till rate you are quoted and how long you expect to run the system, so work it through with your numbers rather than these.

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:

ItemRough cost (KES)Buy now?
Tablet or laptop for the till20,000 to 45,000Yes. This is the till
Receipt printer8,000 to 20,000Yes, if customers expect a receipt
Barcode scanner4,000 to 12,000Only if you have barcoded stock and real queues
Cash drawer6,000 to 15,000Only if you take a lot of cash
Backup power for the tillvariesYes if outages are normal where you are

A phone or tablet plus a printer runs a small shop. A scanner earns its cost where the catalogue is barcoded and queues are long, and not before that. Power is the item most often overlooked: where sales are not written locally, an outage can lose every transaction since the last sync.

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 carries the inaccuracy into the new system.
  • 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.
  • Training time: how long a new cashier takes to become confident is a real operating cost, so test it with somebody who has not seen the system before.
  • 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.

  • Stock loss. Better records make it visible sooner, which is useful. 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 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 what you are buying and the hardware follows from it.

Planning a similar project?

We can help define the requirements, implementation options, and an appropriate project scope. There is more detail on pos systems if that is the closest fit.

Start a project

Tell us what you're building.

Describe the project, your current system or process, and any timing constraints. We'll review the details and reply with the next steps.