POS software development in Kenya involves more than building a checkout screen. For wholesalers and businesses with several branches, the difficult work often happens around pricing, stock allocation, customer credit and payment reconciliation.
A standard retail product may already cover your needs. Custom development becomes worth considering when essential processes cannot be handled through reliable configuration. The first question is therefore whether you need a subscription to an existing POS or a system built around distinct operational requirements.
Explain how you sell products
A wholesaler might sell the same item by piece, pack and carton. The system needs an agreed relationship between these units, including what happens when packaging changes. Product codes and barcodes should identify the right item and selling unit without creating duplicate stock records.
Document customer price lists, quantity breaks and authorised discounts. Ask how pricing changes are approved and when they take effect. If a cashier can override a price, the business should decide whether a reason or manager approval is required.
Separate stock availability from physical stock
Goods on a shelf may already be reserved for another customer. Goods recorded at a branch may be damaged, awaiting inspection or in transit. Define which quantities are available to sell and which should remain excluded.
For branch transfers, capture dispatch and receipt as separate events. An illustrative transfer of twenty cartons should remain visible while it is travelling. If the receiving branch records nineteen, the difference should require investigation rather than disappear into an adjusted total.
Treat credit sales as a distinct workflow
If customers buy on account, decide how limits, overdue balances and approval exceptions affect checkout. A cashier needs a clear result when a sale exceeds the permitted amount. Finance needs visibility of authorised exceptions and the person who approved them.
Specify how deposits, partial payments, returned goods and credit notes affect the customer account. Test a realistic sequence, including a payment received after an invoice and a return processed after part of that invoice has been settled.
Reconcile payments without relying on screenshots
Agree which payment channels are included and how confirmation is obtained. A customer message or screenshot should not be treated as authoritative payment confirmation. An integration should match the provider’s verified transaction reference to the correct sale and make unmatched items visible.
Discuss delayed notifications, duplicate callbacks and one payment covering several invoices. Payment integration and eTIMS integration are separate workstreams: confirming receipt of money does not establish the tax-invoice status. Each requires its own validation and operational records.
Test hardware and connectivity assumptions
List the printers, scanners, terminals and operating environments you intend to use. Compatibility should be demonstrated with the actual models or agreed equivalents. “Works with barcode scanners” is not a substitute for testing your checkout setup.
If you need operations during an internet interruption, define exactly what remains available. Offline selling raises questions about stock conflicts, duplicate transactions and later synchronisation. Do not assume that a browser-based application automatically supports offline checkout or that every fiscal process can be deferred.
Make daily closing part of acceptance testing
A complete test should cover opening a shift, recording sales, approving a discount, receiving payment, handling a return and closing the shift. Compare the expected cash position, payment records and stock movements.
Ask how an incorrect transaction is corrected without erasing its history. The reporting team should be able to trace a daily total back to its underlying transactions. Include a method for investigating differences and assigning unresolved items to a responsible employee.
Choose the right procurement route
Businesses seeking a ready-made product should ask for a demonstration against their sales scenarios. Businesses commissioning custom POS software should first agree a requirements document, integration scope and support arrangement. Those are different purchasing decisions and should have different proposals.
For a custom build, discuss your sales workflow with Zama. Bring sample product units, pricing rules, branch movements and closing reports. This gives the team a practical basis for assessing whether an existing product, an integration or custom development is the best fit.