Warehouse inventory that stays accurate on its own
An inventory automation layer that reconciles counts across warehouses, forecasts replenishment, and flags discrepancies before they become stockouts.
How the work was scoped
- Industry
- Warehousing & Fulfillment
- Duration
- 13 weeks
- Cooperation model
- Fixed price, phased
Client name withheld under NDA. Engagement details are shown to the extent our agreement permits.
The question we were asked
Warehouse counts drifted and replenishment was reactive. We built automation that keeps inventory accurate and predicts what to reorder.
Four distribution facilities, a shared catalog, and cycle counts done on a rolling schedule that took six weeks to walk the whole aisle. By the time a count reached a bin, the number it produced was already historical. The engagement was commissioned after a peak week where pickers hit empty bins on lines the system said were in stock at two other sites.
Data & AI
The decision, first
- 01
Inventory count accuracy increased to 98.7% across all 4 distribution facilities.
Accuracy followed from deriving stock from events: once no one can type over the number, every disagreement has an event behind it.
- 02
Stockouts reduced by 44% through predictive replenishment alerts.
The stockouts that mattered were the ones where stock existed elsewhere. That's a visibility problem more than a forecasting one.
- 03
Cycle-count labor effort dropped by 60% with automated barcode discrepancy catching.
Counting effort fell because counting became targeted. The ledger says which SKUs are drifting, so walking the whole aisle stopped being the only option.
What the numbers couldn't answer
Manual cycle counts lagged reality, so pickers hit empty bins and buyers reordered too late across multiple warehouses.
Stock was a stored number that receipts, picks and adjustments each edited in turn, so a disagreement between the shelf and the screen had no history: nobody could say when it had opened or what caused it. Corrections were applied to make the screen match the shelf, which erased the evidence and guaranteed the next discrepancy would be equally unexplainable.
We built an automation layer that reconciles movements across warehouses in real time, forecasts replenishment, and flags discrepancies before they cause stockouts.
How we worked it through
Streamed stock movements into one real-time inventory model
Streaming was the easy half. The real work was migrating years of stored counts into a ledger without inventing history the sites couldn't vouch for.
Automated cross-warehouse reconciliation and alerts
Reconciliation needed a noise floor before it could alert, and the pilot facility's variance turned out to differ enough by aisle to need measuring per aisle.
Forecast replenishment per SKU and location
Reorder points are solved per SKU per site against the supplier's real lead-time spread. The mean is what the stockouts had been hiding behind.
Piloted in one facility, then scaled to the network
One facility ran the full thirteen weeks before the other three, which is how the per-aisle noise floor came to be measured instead of assumed.
Phase by phase
Phase 1: Stock Drift & Cycle Count Audit
Warehouse Workflow & Accuracy Analysis
Audited cycle counts, barcode scanning latency, and stockout frequency across 4 distribution centers.
- Stock Drift Report
- Warehouse Data Schema
- Cycle Count Benchmark
Phase 2: Real-Time Ledger Engineering
Multi-Warehouse Ingestion Pipeline
Engineered a real-time reconciliation engine streaming stock movements into a central ledger powered by Redis and PostgreSQL.
- Real-Time Ledger API
- Redis Sync Pipeline
- Barcode Connector
Phase 3: Replenishment & Discrepancy Engine
Predictive Forecasting & Alerting
Trained SKU-level demand forecasting models and set up automated discrepancy alerts.
- Replenishment Engine
- Discrepancy Alerting System
- Demand Forecasting Model
Phase 4: Multi-Facility Scale & Rollout
Network Deployment & SLA Sign-off
Piloted in the primary warehouse before scaling across all 4 distribution hubs, reaching 98.7% count accuracy.
- Facility Pilot Report
- Network Rollout Clearances
- SLA Sign-off
The pilot centre's thirteen weekly checks of the ledger against physical counts, the noise floor it measured aisle by aisle before any alert could fire, the rollout to the other three centres, and the four phases with their deliverables.
What it changed
98.7%
Inventory accuracy
−44%
Stockouts
Inventory accuracy is measured against physical cycle counts across all four facilities in the two quarters after rollout. Stockouts means picker-reported empty bins on lines the system showed as available. That's the failure the engagement was actually about, and a narrower measure than the overall stockout rate.
Client name withheld under NDA. Figures are approximate, drawn from the engagement’s own reporting.
Real-Time Stock Reconciliation Ledger
Streams warehouse scans and order fulfillment events into a single real-time inventory model.
Scans, receipts, picks and adjustments all write to one append-only movement ledger, and stock is the fold over it. Nobody updates the number by hand. That's what made reconciliation possible: a disagreement is now a specific event you can point at, not a mystery delta. Redis holds the current fold per SKU per location, so a read is a lookup while the audit trail stays complete.
- Append-only movement ledger; stock is the fold over it
- Every discrepancy traceable to a specific event
- Redis holds the current fold, so reads stay instant
The movement ledger at the pilot centre: every scan, receipt, pick and move appended as a row, and beside it one bin's fold from the 06:00 carry-in to the figure Redis holds now, the blind count that disagrees by four, and the adjustment appended and held rather than typed over.
Predictive SKU Replenishment Engine
Replenishment filtered to cover under ten days: seven lines, three past a reorder point solved per SKU per site. The carton supplier is usually four days and sometimes eleven, so the line that looks covered on the mean orders today on the spread, with this week's seasonal factor set per site.
Forecasts reorder triggers based on lead times, order velocity, and seasonal spikes.
Reorder points are set per SKU per site, solved from order velocity, that supplier's real lead-time distribution and the seasonal curve. No single global cover figure. The trigger uses the lead-time spread instead of the mean, so a supplier who is usually four days but sometimes eleven is treated as the eleven. Averaging that away was what produced the stockouts.
- Reorder points per SKU per site, not one global cover rule
- Triggered on the lead-time spread, not its average
- Seasonal curve applied site by site
Discrepancy Warning System
Detects inventory drift between physical scans and system balances automatically.
Drift is detected by replaying the ledger against cycle-count scans and flagging where the two diverge faster than the site's normal noise floor. Alerts name the SKU, the location, the size of the gap and the window it opened in, which usually points straight at the shift or the process that caused it. Counting goes where the drift is, instead of sweeping the aisle blind.
- Ledger replayed against cycle counts to find divergence
- Alerts carry the gap size and the window it opened in
- Counting aimed at drifting SKUs, not the whole aisle
Variances raised today, system against counted bin by bin: two cleared and five waiting on a person. The selected alert names the SKU, the bin, the gap and the window it opened in, points at the move that likely caused it, and every gap is set against its aisle's noise floor.
How the engagement ran
A cross-functional team of 6 worked on a fixed price, phased basis over 13 weeks, covering Inventory automation, Replenishment forecasting, Alerts. We ran a standing mid-week checkpoint and written decisions in place of status meetings. Nothing shipped without a live demo first.
One facility ran the whole thirteen weeks before anything reached the other three, with its own cycle-count team checking the ledger against physical counts weekly. That pilot is where the drift detector's noise floor came from: the facility's normal variance had to be measured before an alert could mean anything, and it turned out to differ by aisle.
One bin, replayed
A stored number forgets why it is wrong. A ledger remembers.
The same afternoon at one bin, first against a stock figure that every event edits in place, then against the append-only ledger Orbit folds, and finally a carton line reordered on the supplier’s average lead time and on its spread. Switch tabs, or use the arrow keys once one is focused.
Receipts, picks and moves each edit one stored figure in turn. When the count disagrees, the figure is corrected to match the shelf, which makes the screen right and erases any trace of when the gap opened or what opened it.
- 07:52 pick edits on hand by −24
- 09:47 receipt edits on hand by +60
- 10:22 pick edits on hand by −24
- 11:05 pick edits on hand by −12
- 12:31 move edits on hand by −36
- 13:18 pick edits on hand by −12
- 14:32 count finds 88, screen says 92
- On hand typed over to 88
Step timing and the reorder chart’s starting stock of 1240 are illustrative. The bin’s events, the 62-a-day velocity, the lead times and both reorder points are the ones Orbit’s screens show.
From a scan on the floor to a number nobody types over
Python and FastAPI services over PostgreSQL and Redis, scikit-learn for the SKU-level demand models, and a React console on top. Every stage below reads from or writes to the same movement ledger.
- 01 · SourceScans, receipts, picks, adjustmentsWarehouse scans and order fulfillment events from all four facilities arrive through the barcode connector as movements. None of them edits a stored count.
- 02 · IngestionRedis sync pipelineStock movements stream in real time into one inventory model, so reconciliation runs across the whole network at once.
- 03 · EngineReconciliation, drift and replenishmentThe ledger is replayed against cycle counts and flagged only beyond the aisle's noise floor; reorder points are solved per SKU per site on the lead-time spread.
- 04 · StateAppend-only ledger in PostgreSQLStock is the fold over the movement ledger. Redis holds the current fold per SKU per location, so a read is a lookup while the audit trail stays complete.
- 05 · DeliveryReact console and alertsAlerts name the SKU, the location, the size of the gap and the window it opened in, and counting is directed at the SKUs that are drifting.
Why the number can be trusted
Audit trail & alert integrity
A correction can't erase the evidence
Stock is the fold over an append-only ledger, so no one can type over the number. An adjustment is one more movement beside the event it corrects, and every disagreement keeps the event behind it.
No history the sites couldn't vouch for
Years of stored counts were migrated into the ledger without inventing movements to explain them, so the history it holds is only what the sites can stand behind.
Alerts only past a measured noise floor
The pilot facility ran all thirteen weeks, checked weekly against physical counts, before the other three. Its normal variance was measured per aisle, so an alert means a gap wider than that aisle's usual noise.
Does the stock on your screen still match the shelf? Scope your build in 3 minutes.
Scope your buildNearby engagements
Web PlatformsOne long form is why the device records were empty, so the record became tabs
A small desktop tool for cataloging equipment, where a device record is split into tabs so a partial entry is a normal state, never an abandoned form.
Logistics & Distribution · 5 weeks
Web PlatformsA freight portal that brings visibility to every mile
A real-time shipment visibility platform connecting carriers, shippers, and dispatchers with live tracking, geofence alerts, and automated status updates.
Freight & Trucking · 18 weeks
Web PlatformsAn order pipeline that scales for month-end and costs nothing at 2am
An event-driven serverless rebuild of a B2B order-processing pipeline: triggered per purchase order, scaling for month-end volume, and costing next to nothing overnight.
Logistics & Distribution · 10 weeks
Let's talk
Running a large platform, shaping a first MVP, or getting a product ready for a funding round? Tell us where you are. We'll shape the process around it, and stay with you after launch.
