AWRA OpsHub Search

POS for Kenya

A till that complies at the counter and never loses count

eTIMS receipts from the normal sale, M-Pesa and cash reconciled per shift, and every sale moving stock in real time — across every branch.

Sound familiar?

If any of these ring true, you are exactly who this was built for.

Compliance bolted on after the sale

The receipt is raised, then somebody re-keys the day into a separate tool at closing time.

Shift cash that never balances

M-Pesa here, cash there, and a drawer count that argues with both.

Stock and sales living apart

The POS says sold; the stock card says nothing; shrinkage hides in the gap.

Branch blindness

Head office learns what branches sold days later, from photos of notebooks.

What the till does, including the thing it does not transmit

Running in the product today

  • eTIMS on the sale itself, straight to KRA's OSCU API on your own PIN, branch and device serial, with the receipt signature and QR coming back onto the document. Sandbox and production are a toggle, so you validate before going live.
  • Selling needs a connection. This is a correction rather than a feature: the till does not trade offline. Offline queueing exists on mobile only and covers stock transfers, check-out, check-in and asset movements — the POS screens contain no offline path at all, and the web app has no offline support of any kind. An earlier version of this page said the till kept selling. It does not.
  • Shift and drawer reconciliation — cash, M-Pesa and card takings on one record with the variance attributed by name, against the same inventory the back office is counting.
  • Every sale moves stock the instant it rings, so shrinkage is a same-week variance rather than a year-end mystery.
  • M-Pesa collection on your own Daraja credentials into your own till — STK push, dynamic QR and C2B paybill or till.

Absences — on the roadmap, and commissionable now

  • A credit note does not reach eTIMS. The receipt type we transmit is fixed to a sale. A return moves stock back and posts to the ledger correctly, but the eTIMS reversal is not sent and KRA never hears about it. An earlier version of this page said credit notes were included; that was wrong and this line replaced it.
  • The dynamic QR has no callback. The customer scans and pays, the funds land in your till, and confirmation reaches you out of band rather than back into the sale. STK push does confirm.
  • No bank statement reconciliation. M-Pesa matching works on the reference; matching a bank statement does not exist in any form.
  • Unreferenced receipts are matched by hand from a list capped at 300 open invoices. A high-volume operation will exceed that cap and will be attaching against a truncated list.

What we would decline, and would rather say now

  • We will not build an off-system mode so the till can keep taking money during an outage. Selling requires a connection, and the request that usually follows is for a mode that records sales outside the system and reconciles later by hand. That is the one request where saying yes would quietly undo the reason to buy any of this.
  • We will not tell you your VAT position is correct. We transmit what you raised and keep it reconstructable. Whether the return is right is between you and your accountant, and the credit-note gap above is precisely the kind of thing that makes a vendor's reassurance worthless.

The credit-note transmission is the largest item and it is a well-defined build rather than a research problem — the transmission path, the retry handling and the reconciliation report all already exist for sales. Commissionable now on a written specification, a timeline and a price agreed before any money moves. Kenya is the evidence that this is real: the eTIMS integration itself exists because a client needed it and paid for it. We will not print a date here.

The test to run before you sign, with us and with everybody else on your list: raise a credit note against a filed invoice and ask to see the transmission record for the reversal. We will show you the sale going and the credit note not going. Ask the others to do the same before you believe their table.

How teams get started

1

Load items & prices

Catalog, pricing, and tax settings imported; eTIMS connected.

2

Train the counter

Cashiers learn on your products — selling, returns, and shift close.

3

Open with live stock

First shift runs with inventory sync and reconciled close — repeat daily.

Questions we are asked here

Frequently asked questions

What happens when the internet drops?

Two different outages get confused here, so worth separating. If your own connection is down, the till stops selling — there is no offline path in the POS on either the web app or mobile. If your connection is fine and KRA is unreachable, the sale completes normally and the transmission retries on its own with backoff until it lands, so a KRA outage is not your problem to manage. Plan for the first case the way you would plan for a power cut: it is a business-continuity question, not a software setting.

How does M-Pesa reconciliation work?

Mobile money takings are captured per shift alongside cash and card, then matched against statements — per-shift variances are attributed to the person on the drawer, which is what actually changes behavior.

Can it run a small kiosk and a multi-branch chain?

Yes — the same POS scales from one counter to many branches; head office sees consolidated sales, stock, and reconciliations live either way.

Does POS connect to purchasing and accounting?

Fully — sales deplete stock, stock triggers replenishment through procurement, and takings post to the ledger. The point of one suite is that the till is not an island.

Reconcile tonight's shift in minutes

See a full day at the counter — sales, eTIMS on the receipt, and shift close — on your items.