Inventory Management System in Kenya: 15 Buying Requirements

An inventory management system should explain where each item is, why the quantity changed and which action needs attention next. It should not merely replace one stock spreadsheet with a slower screen.

For a Kenyan retailer, distributor, pharmacy, workshop, ecommerce business or multi-branch operation, inventory connects purchasing, receiving, transfers, sales, returns, fulfilment, finance and tax invoicing. A small error can therefore travel across several teams. These fifteen requirements help you evaluate packaged software, commission a custom system or improve an existing workflow with clearer acceptance tests.

Begin with movements, not totals

A quantity on hand is the result of events: opening stock, purchase receipts, sales, transfers, returns, adjustments, damage, expiry, assembly or another defined movement. If staff can simply overwrite the number, the system loses the evidence needed to explain a shortage or reproduce yesterday's report.

Document every legitimate movement, who can initiate it, who approves it, which reference is required and how a correction works. Preserve an append-only movement history and derive balances from controlled transactions. This gives managers a dependable trail without preventing authorized corrections.

15 requirements to test before you buy

1. A product master that fits the business

Define SKU, barcode, name, category, unit of measure, pack conversion, supplier references, tax treatment, reorder settings, variants, batch or serial tracking, shelf life and status. Avoid allowing each branch to create a slightly different version of the same item.

2. Multi-location stock with explicit ownership

Model stores, warehouses, shelves, vans, consignment locations and virtual fulfilment points only where they represent real responsibility. A transfer must move through requested, approved, dispatched, received and exception states instead of disappearing from one location and immediately appearing in another.

3. Purchase planning and supplier control

Connect requisitions, approvals, purchase orders, expected dates, partial receipts, price differences and supplier returns. The system should distinguish what was requested, ordered, received, accepted and invoiced so finance and operations can investigate a mismatch without editing history.

4. Receiving with usable evidence

Receiving should capture the purchase reference, quantities, location, receiver, date, exceptions and any batch, serial or expiry details required by the business. Support partial and excess deliveries as explicit outcomes rather than forcing staff to make the paperwork match the screen.

5. Sales and reservation rules

Decide when an order reserves stock, how long the reservation lasts, what happens after payment failure and which event finally deducts the item. Online and counter sales must not both promise the last unit. Repeated payment callbacks or retries must never deduct stock twice.

6. Returns, damage and quarantine

A returned item should not automatically become saleable. Record reason, condition, inspection, disposition and approver. Keep damaged, expired, recalled or disputed stock in a controlled state and location until an authorized decision releases, writes off or returns it.

7. Batch, serial and expiry controls where needed

Use batch or serial tracking only where the item and risk justify it, then make the workflow complete. Capture identifiers at receipt, movement and issue; support expiry alerts and traceability; and test whether the system can identify affected locations and transactions without a manual search.

8. Stock counts that explain variances

Support scheduled full counts and focused cycle counts. Freeze or account for movements during counting, separate count entry from approval, record recounts and require a reason for every adjustment. A variance report should preserve system quantity, counted quantity, difference, value and responsible reviewers.

9. Reorder decisions based on dependable inputs

Reorder points are useful only when lead time, demand, open purchase orders, reservations and location rules are accurate. Let planners see the inputs behind a suggestion and apply judgement. Do not turn an unexplained forecast into an automatic purchase commitment.

10. Role-based permissions and audit history

Receiving staff, sales teams, warehouse supervisors, buyers, finance staff and system administrators need different capabilities. Separate high-risk actions such as stock adjustment, cost changes, write-off approval, exports and permission management. Log who did what, when, from which approved workflow and against which reference.

11. Sales, ecommerce and payment integration

Define the source of truth for products, prices, orders and inventory before connecting systems. Integrations should use stable identifiers, idempotent requests, monitored queues, retries and exception views. A successful API response is not enough if staff cannot find and resolve a record that failed later.

12. eTIMS and accounting boundaries

KRA describes eTIMS as an electronic tax invoicing solution with options for different taxpayer needs. Inventory, tax invoicing and accounting are connected concerns, but they are not interchangeable. Define which system creates the commercial transaction, which submits the tax invoice, how references are shared and how rejected or corrected outcomes are reconciled.

13. Privacy and retention by design

Inventory records may contain supplier, customer, staff and delivery information. Kenya's Data Protection Act makes purpose, minimisation, security, access and retention important design questions. Collect only what the workflow genuinely needs and define how long personal information remains attached to operational records.

14. Reports that reconcile to transactions

Agree on definitions for stock on hand, available stock, reserved stock, stock in transit, ageing, gross margin, shrinkage, stock turns and valuation. Every summary should drill into the transactions that produced it. If finance and operations use different valuation rules, document the boundary rather than hiding the difference.

15. Migration, rollout and support ownership

Clean product masters, duplicate SKUs, units, opening quantities, costs and locations before migration. Reconcile opening balances by location and value, pilot complete workflows, train each role and retain a signed migration report. The agreement should state hosting, backup, recovery, updates, support, source and data ownership, export, documentation and supplier exit.

Questions that reveal whether the demonstration is real

• Can the system explain one item's quantity from opening balance to the present movement?
• Can two branches transfer stock without both claiming ownership during transit?
• Can staff receive part of a purchase order and record damaged units separately?
• Can an online order reserve the last unit without overselling it at the counter?
• Can a supervisor approve a variance without deleting the original count?
• Can every adjustment be traced to a user, reason, reference and approval?
• Can the supplier restore the system and private files into a clean environment from an off-site backup?

A sensible first release

For many businesses, the first complete workflow is product master, locations, purchasing, receiving, transfers, controlled adjustments, sales allocation and core reporting. Add advanced forecasting, supplier portals, mobile scanning or complex integrations after the foundational movements reconcile reliably.

If spreadsheets are still the main operating tool, begin by mapping ownership and exceptions rather than copying every column into a database. Rx Code Labs' dashboards and workflow automation service can improve visibility around an existing process, while custom software development fits teams that need a deeper operational platform.

Frequently asked questions