Inventory Record Reconciliation

Inventory controllers work from a system quantity that is supposed to match what is actually sellable on the floor and in the back room. That number drifts for ordinary reasons: late receiving, unposted transfers, mis-scans at POS, phantom picks, damaged goods that never leave the book, and cycle counts that land on the wrong SKU or location.

When the book is wrong, every downstream decision inherits the error. Replenishment orders too much or too little. Pick paths send associates to empty slots. Availability promises to e-commerce fail. Shrink reports mix true loss with bookkeeping noise. Controllers already know this pattern; what they lack is a reliable way to see which SKUs are drifting before the next full count.

Manual reconciliation usually means comparing two screens at a time, POS versus perpetual, or a count sheet versus the WMS. That works for a short list of exceptions. It does not scale across thousands of SKUs with overlapping movements in the same day. The useful shift is not to replace judgment. It is to rank records that look inconsistent across several systems at once, then leave the adjustment decision with the person who owns the book.

The model only runs when the core movement and count feeds are present. At minimum it expects recent POS sales and voids, warehouse or store perpetual balances by location, receiving receipts, transfer in and out postings, and cycle count results with timestamps and counted quantity. Optional enrichments help ranking: known planogram or facing capacity, open purchase orders, and historical adjustment reasons for the same SKU.

Each signal should carry SKU identity, location (store, back room, DC, or transit), quantity, and event time. Without aligned identity and location, mismatches are noise. Controllers should treat identity mapping (barcode, pack size, case-to-each) as a prerequisite, not something the model invents.

If POS, warehouse perpetual, or count signals are missing for the evaluation window, the model returns empty output for that SKU-location. It does not invent a balance, fill gaps from averages, or post a “likely” quantity. Empty output means “not enough evidence to rank,” not “stock is fine.” That distinction matters when a feed is late: silence is safer than a false clean bill.

Reconciliation here means cross-checking expected on-hand against observed movements, not rewriting the ledger. The model builds an expected balance path from the last trusted count or known good balance, then applies subsequent receipts, transfers, and sales. It compares that path to the current perpetual quantity and to any intervening cycle counts.

Flags arise when the gap between expected and booked quantity is hard to explain with normal timing lag. Examples include sales after a zero balance with no intervening receipt, a receipt that never lifts perpetual, a transfer that left one location without arriving at another, or a cycle count that contradicts both POS velocity and recent receipts. The score reflects how unusual the gap is given recent movement patterns for that SKU and location, not a hard rule that every variance above N units is wrong.

The output is a ranked exception list: SKU, location, booked quantity, expected range or implied quantity from the movement path, contributing events, and a short reason code (for example, “sales without receipt,” “orphan transfer,” “count conflicts with POS”). Controllers see evidence, not a black-box score alone. Nothing in this step posts inventory, creates adjustments, or locks the SKU.

Reason codes should stay operational. Inventory teams already triage with language like late ASN, mislocated stock, and scan error. Aligning model labels with those words shortens review time and makes audit trails usable when finance asks why a balance changed.

Human-in-the-loop is mandatory. The model proposes candidates; inventory still adjusts. A controller opens the exception, checks the cited events, walks the location if needed, and decides whether to count, locate product, correct a posting, or leave the book alone until more evidence arrives.

Typical review steps stay familiar. Confirm the SKU and pack. Verify whether a receipt or transfer is stuck in a staging status. Check POS for mis-rings or returns. If physical stock is unclear, schedule a directed count rather than guessing. Only after that judgment does someone post an adjustment through the existing inventory control process, with the usual approvals and reason codes.

Do not auto-write the book. Automatic adjustments from model scores create silent corruption: one bad feed becomes a permanent wrong balance, and the next cycle count fights the model instead of reality. Keep write permission in the WMS or inventory system under controller credentials. Treat the ML queue like a smarter blind-count list, not like an autopilot.

Measure success by controller outcomes: share of flags that resolve to a true book error, time to clear the queue, reduction in surprise stockouts on previously “in stock” SKUs, and fewer large end-of-period adjustments. Those metrics keep the project honest. A high flag volume with low true-positive rate is a data problem, not a win.

related

Empty output is a first-class result. When POS, warehouse, or count signals are absent, late, or incomplete for a SKU-location, return no flag. Controllers should see coverage status separately (which feeds and locations were evaluated) so quiet queues are not mistaken for clean inventory.

Other failure modes deserve explicit handling. Clock skew between systems can create false orphans; prefer event times from a shared source of truth when available. Case-to-each mistakes look like massive variance; surface UOM conflicts before ranking. Dual locations (floor versus back room) without a transfer posting look like shrink; require location-level balances when the store operates that way. Heavily promotional SKUs with bursty sales need wider tolerance than slow movers, or every promo week becomes a false alarm.

If a feed recovers after downtime, re-evaluate the window rather than backfilling adjustments. Controllers can then decide which gaps still need physical confirmation. That keeps the ledger under human control when systems catch up out of order.

Record reconciliation protects the book. It does not by itself prove that the customer-facing shelf is full or that product sits in the right bay. Pair it with operational checks that see the floor. Planogram Compliance Checker surfaces facing and placement issues that can make a correct book look like a stockout on the shelf. Shelf Availability Computer Vision detects empty or low facings even when perpetual says stock remains. Real-Time Stockout Risk Predictor uses velocity and balance to warn before the next sell-through, which is only trustworthy when the balance is not fiction.

A practical sequence for inventory controllers is: keep feeds healthy, run reconciliation to clean likely book errors, confirm physical exceptions with directed counts, then rely on availability and planogram tools for the floor experience. Each layer answers a different question. Confusing them produces either blind trust in the book or constant recounting of SKUs that were never wrong in the system of record.