A till the cashier can't quietly rob.
Every void, discount and refund passes a supervisor; every sensitive action needs a fingerprint; and every transaction is hash-chained to the one before it, so the audit trail can't be quietly edited after the fact — loss prevention built into the till, not a report you run once the money is gone.
deployment-record
code-inventory
deployment-record
Retail POS + loss prevention (Kenya)
SAP Customer Checkout · Odoo POS · Loyverse
Loss prevention is built into the till — approval chains, a hash-chain audit and biometric 2FA — not an analytics report you run after the money has already walked. code-inventory
| ACTION | CASHIER | AMOUNT | APPROVED BY |
|---|---|---|---|
| Void SALE-4472 | MARY W. | −1,180 | JANE · SUP |
| Discount 10% | MARY W. | −560 | JANE · SUP |
| Refund SALE-4460 | MARY W. | −2,400 | JANE · SUP |
| Price override | PETER K. | — | DECLINED |
| 4 requests | 3 approved · 1 declined |
Nothing risky clears without a supervisor.
ApprovalVoids, discounts and refunds stop at the till until a supervisor approves them — and an unauthorised price override is declined outright — every one recorded with who asked, who approved or declined, and how much was at stake. code-inventory
SALE-4472 1,180 hash(a7f3 · txn) = c19b
VOID-4472 −1,180 hash(c19b · txn) = 4e82
SALE-4473 5,600 hash(4e82 · txn) = d5a1
SALE-4474 890 hash(d5a1 · txn) = 9c30
A ledger no one can quietly rewrite.
AuditEach transaction is hashed together with the hash of the one before it, so the log is a chain — change any past line and every hash after it breaks. The audit trail is tamper-evident by construction, not by policy.
| EVENT | CASHIER | ACTION | AUTH |
|---|---|---|---|
| No-sale drawer | MARY W. | open | FINGERPRINT |
| Void | MARY W. | SALE-4472 | FINGERPRINT |
| Price override | PETER K. | — | DECLINED |
| 3 events | 2 authorised · 1 declined |
A fingerprint at the sensitive edge.
IdentityOpening the drawer without a sale, voiding, overriding a price — the actions that leak money — take a biometric, so an action is tied to a person, not a shared PIN whispered down the line.
| LINE | AMOUNT |
|---|---|
| Gross sales | 284,600 |
| Voids | −1,180 |
| Discounts | −560 |
| Refunds | −2,400 |
| Net sales | 280,460 |
| Cash declared | 96,200 |
| M-Pesa | 148,900 |
| Card | 35,360 |
| VARIANCE | 0 |
The shift closes to the shilling.
ReconciliationAt close, the Z-report totals gross, voids and discounts to net, then reconciles net to the cash, M-Pesa and card actually taken — variance surfaced, not smoothed over. deployment-record
Everything at the till.
In this line| Cashier Till / Checkout (POS core) | Live | Offline-first Flutter till, barcode scan. |
| Kenya Fraud Control Suite | Live | Approval chains, hash-chain, biometric 2FA. |
| KRA Fiscalisation at the till | Live | Dart-native TIMS/eTIMS, multi-device. |
| Multi-rail Payments at till | Live | M-Pesa STK, DTB STK, card, cash. |
| Shift & Cash Management | Live | X/Z reports, float, variance, handover. |
| Retail Inventory Operations | Live | Multi-warehouse, transfers, counts, GR/GI. |
| Retail Pricing Engine | Live | Local price resolution, no SAP round-trip. |
| Customer-Facing Display | Live | Live second-screen cart + total. |
| Walking Cashier (queue-busting) | Live | Mobile sale on a Sunmi in the aisle. |
| Peripheral / Device Framework | Live | Printers, scanners, drawer, scales. |
| Retail Banking module | Designed | Deposits, outgoing payments, statement import. |
| Loyalty Programme Engine | Roadmap | Enrolment, points, redemption, tiers. |
Every entry is sealed to the one before it.
Signature · Synthetic hashes, real chained auditThe till writes every event — sale, void, refund — as a line that hashes the line before it, approvals sealed into the same record. Nothing is quietly editable after the fact: change any past line and every hash after it stops verifying. code-inventory
deployment-record
The first production POS went live at SAMWEST on 5 tills, with the Car & General M-Pesa POS confirmation pipeline live — and the fraud controls ship in the same till that rings the sale, built in, not bolted on.
On Leysco Akili there is no POS today — the till is a separate Leysco100-family product, not a Leysco Akili module. We say so plainly.
- run tills where shrinkage and cashier fraud are the real risk
- need voids, discounts and refunds gated by a supervisor, on the record
- want an audit trail no one can quietly edit after close
- reconcile every shift to the shilling across cash, M-Pesa and card
A spreadsheet of voids reviewed next week, after the cash is gone → controls in the till, at the moment of the sale
Part of the house.
RelatedKRA Fiscalisation
The sale fiscalised to KRA at the till.
LivePayments Hub
The rails the till accepts tender on.
LiveWalking Cashier
The same till, mobile in the aisle.
LiveThe house has worked SAP Business One since 2017. company-books