Inventory and Supply Chain Automation: Replacing the Spreadsheet Relay

The spreadsheet relay works like this: the warehouse team updates a stock workbook at the end of each day. The file is emailed to the operations manager, who reconciles it against the orders workbook from the sales team, who received their data from the procurement team's purchasing file. By the time the operations manager has a complete picture, it reflects yesterday's state. Decisions made today are made on yesterday's data.

This is not a people problem. The warehouse team, the operations team, and the sales team are all doing their jobs. The architecture is the problem: disconnected files enforcing a batch update cycle that the business has outgrown.

The cost of this architecture compounds:

Stock-outs on available items: Sales closes a deal on product that appears in stock, but the stock was actually committed in the field an hour earlier. The sales team cannot see that commitment because it has not made it into the spreadsheet yet.
Ghost inventory: Items recorded as in stock have been issued, damaged, or misplaced. The count has not been reconciled. The system shows thirty units; the warehouse has four.
Excess working capital: Without accurate demand visibility, buyers over-order to avoid stock-outs. Excess inventory ties up capital and creates storage costs.
Reconciliation time cost: Monthly stock reconciliation takes several days of accounting time to cross-reference physical counts, supplier receipts, and sales records. This time cost is recurring and scales with business volume.

The Architecture That Replaces It

A real-time inventory system has three layers: the event capture layer, the stock state layer, and the reporting and planning layer.

Layer 1: Event Capture

Inventory changes are caused by events: goods received from a supplier, goods issued to a customer order, goods moved between locations, goods damaged or written off, and returns from customers. Every stock change is traceable to one of these event types.

The event capture layer records each event at the moment it occurs, by the person performing the action, with a reference to the document or order that authorised it.

Goods received: The receiving team scans or selects the purchase order line items as they arrive and records actual quantity received (which may differ from order quantity). The stock count updates immediately. The discrepancy — order quantity minus received quantity — is automatically flagged to procurement.

Goods issued: The warehouse team records outgoing items against a sales order or production order. Stock is decremented at the moment of physical issue, not at the end of the day. The sales team can see available-to-promise inventory in real time rather than a yesterday-plus-estimation figure.

Inventory adjustments: Physical counts, damage write-offs, and corrections require a separate adjustment event type with a mandatory reason code and approval step for adjustments above a threshold. This creates an audit trail for every stock discrepancy.

This event capture layer can work from:

A web application accessible from warehouse workstations
A mobile application for warehouse staff on the floor
Barcode or QR scanning integration (adding physical scan verification to digital records)
WhatsApp bot interface for field operations with simple items

The critical requirement is that events are recorded at the point of action, not reconciled later. If the receiving team records goods receipt in a paper sheet and later enters it into the system, you have a batch update cycle — which is the same problem as the spreadsheet relay. The architecture only works if recording is the action.

Layer 2: Stock State

The stock state layer maintains the authoritative current position for every stock-keeping unit (SKU) at every location. This is a materialized view computed from the event history — not a separately maintained number that people edit directly.

Key computed fields:

Quantity on hand: Physical inventory at each location
Quantity reserved: Committed to confirmed orders but not yet shipped
Available to promise: On hand minus reserved — the true available quantity
Quantity on order: Ordered from supplier but not yet received
Projected stock in X days: Based on pending orders and in-progress shipments

Separation between "on hand" and "available to promise" is the critical distinction that prevents over-selling. When a sales order is confirmed (not when it ships), the items are reserved. The sales team querying available stock sees available-to-promise, not on hand. A salesperson sees twenty units available; there may be forty on hand with twenty reserved for other orders.

The stock state layer serves as the single source of truth queried by every other system: the sales order form checking availability before confirmation, the production planning tool checking component availability before scheduling, the accounting system calculating inventory asset values, and the reporting layer generating management information.

Layer 3: Reporting and Planning

The reporting layer transforms event history and current stock state into operational intelligence:

Reorder alerts: When available-to-promise falls below a configured minimum (accounting for procurement lead time), an automatic alert routes to the procurement team with a suggested reorder quantity calculated from average daily consumption and safety stock policy.

Slow-moving inventory: Items with no outbound movement in 60+ days flagged for review. Working capital analysis showing value of stock by velocity category (fast-moving, medium, slow, dead stock) to guide purchasing decisions.

Supplier performance: On-time delivery rates, fill rates (did the supplier deliver the ordered quantity?), and lead time variance by supplier — automatically computed from purchase order events and goods receipt events.

Demand forecasting: Historical consumption patterns by SKU, adjusted for seasonality if the data supports it, projected forward to inform purchasing. At minimum, trailing 90-day average consumption rates to set reorder points; at scale, time-series forecasting models that account for sales pipeline and seasonal patterns.

Integration Points

An inventory system produces maximum value when it integrates with the adjacent systems that cause and consume inventory changes:

Sales/CRM → Inventory: Order confirmation creates a reservation. Invoice generation triggers a goods issue event. Returns initiation creates a pending receipt. The inventory system should receive these events from the sales system, not require double-entry from staff.

Procurement → Inventory: Purchase order creation creates a "quantity on order" position. Goods receipt against a PO is a system event that updates on hand and clears the on order position. Supplier invoicing cross-references goods received — the foundation for three-way matching (purchase order, goods receipt, supplier invoice must all align before payment approval).

Accounting → Inventory: The inventory asset value in the general ledger should be a live query of stock on hand multiplied by standard cost, not a monthly journal entry based on a physical count. Goods movements create accounting entries automatically: cost of goods sold on issue, inventory asset debit on receipt, variance accounts for price differences between purchase order cost and actual invoice cost.

Production → Inventory: Production orders consume components and produce finished goods. A bill of materials (recipe) associated with each production order drives automatic component reservation when the production order is confirmed, and automatic component consumption and finished goods receipt when production is completed.

The Implementation Path for Nigerian Businesses

Most Nigerian businesses implementing their first real-time inventory system have data in spreadsheets that does not map cleanly to a structured database. The migration path matters:

Phase 1: Clean the master data. Every product must have a unique code, a consistent description, a unit of measure, and a cost. Products that have been tracked inconsistently (the same item under three different names) must be consolidated. This work is unglamorous but determines whether the system produces reliable output. Rushing it produces a digital version of the spreadsheet inconsistencies.

Phase 2: Establish the opening position. A physical count, recorded against the clean master data, becomes the system's starting point. Do not attempt to reconstruct historical inventory from incomplete records — take a clean count and start the real-time tracking from that baseline.

Phase 3: Implement event capture at the warehouse, procurement, and sales nodes. This requires process change for the teams involved, not just system change. The warehouse team needs to log receipts and issues at the time of action. This represents a workflow change for people accustomed to end-of-day batch updates, and requires change management alongside technical implementation.

Phase 4: Integrate with adjacent systems. Once the core event capture and state management is stable and the teams are using it consistently, the integrations with sales, procurement, and accounting deliver the compounding benefits.

The common failure mode is attempting Phase 4 before Phase 3 is stable. Integration amplifies whatever is in the underlying system — good or bad. A clean, consistently-maintained event log integrated with sales produces accurate available-to-promise. An inconsistently-maintained event log integrated with sales produces fast-moving inaccurate data.

The Business Case in Numbers

For a distribution company moving ₦2B in product annually with fifteen warehouse staff and three operations management roles, the business case for real-time inventory typically includes:

Stock-out cost reduction: 1–2% of sales recovered by reducing stock-outs on available items (₦20–40M/year)
Working capital reduction: 10–15% reduction in average inventory value through better demand visibility (₦15–30M reduction in tied-up capital at 15% cost of capital = ₦2–4.5M/year in financing cost reduction)
Reconciliation time: Monthly stock reconciliation reduced from five accounting days to one day per month (₦600K/year in recovered management time)
Expired/obsolete stock reduction: Better visibility into slow-moving inventory reduces write-offs by 20–30%

The total business case typically supports a system investment of ₦8–15M with payback in twelve to twenty-four months for a business at this scale.

The spreadsheet relay is not failing because the people using it are not capable. It is failing because it was designed for a smaller, simpler operation and the business has grown beyond what manual batch reconciliation can support. The architecture change is the solution.

Logistics and Fleet Management Automation — Automating fleet operations and route optimisation
Accounts Receivable Automation: Getting Paid Faster — Automating collections and payment tracking
CRM: Why Custom Beats Salesforce for Nigerian SMBs — Building customer management that fits your business