Open any inventory control system and ask it whether a SKU is available. It will answer with a number — stock-on-hand. That number is the warehouse-and-ledger view of your inventory, and it is frequently, confidently wrong about what is actually sitting on the shelf. This is the gap most retail teams underestimate. “Inventory control software” gets treated as one category, as if the system that tracks how much stock you own also tells you what a shopper can physically reach. It does not. The ledger and the shelf are two different objects, and the distance between them is where lost sales hide. What Inventory Control Software Actually Tracks Inventory control software — the ERP module, the warehouse management system, the point-of-sale stock ledger — is fundamentally an accounting engine for goods. It increments stock-on-hand when a delivery is received, decrements it when an item sells through the till, and reconciles the two against purchase orders and cycle counts. Done well, it answers questions like “how many units of this SKU do we own across these locations” and “when do we reorder” with real precision. That is a genuinely hard problem and these systems solve it. The trouble starts when teams extend the stock-on-hand number into a claim it was never designed to make: that the item is on the shelf, faced correctly, in the right slot, reachable by a customer right now. The ledger tracks ownership and movement. It has no eyes on the physical fixture. In our experience working on retail computer-vision systems, this is the single most common conceptual error in availability planning — treating a back-office count as ground truth for front-of-store reality. The count is upstream of the shelf. The shelf is where revenue is actually won or lost. Why Does Inventory Software Say a SKU Is in Stock While the Shelf Is Empty? This is the phantom-stock problem, and it has well-understood mechanical causes. The ledger says you own twelve units; the shelf holds zero. Both can be true at the same time. Stock that is “in system but off shelf” accumulates through a handful of recurring failures: Backroom stranding — the units arrived and were received into the ledger, but never made it from the stockroom to the fixture. Mis-shelving — the product is on the floor, but in the wrong slot, so a shopper looking in the planogram-correct location sees a hole. Theft and shrink — units left the building without a till transaction, so the ledger still counts them. Scan and receiving errors — quantities were keyed wrong at receiving, or returns were processed back into available stock without being physically re-shelved. Planogram drift — the fixture layout slowly diverges from the planogram of record, so even correctly stocked items end up where neither staff nor system expects them. Every one of these lives in the gap between the ledger and the shelf. None of them is visible to the inventory system, because the inventory system has no mechanism for observing the physical fixture. It can only know what it was told at receiving and at the till. As a directional industry pattern, on-shelf availability tends to run several points below system stock-on-hand even in well-run stores — the divergence is structural, not a sign of a broken ledger. Where Inventory Control Software Ends and Shelf-Execution AI Begins The clean way to draw the boundary: inventory control software owns the ledger — what you own and where it should be. Shelf-execution AI owns the observation — what is physically present on the fixture and how it compares to both the ledger and the planogram. A shelf-execution layer uses cameras and mobile devices to look at the shelf and produce a second, independent signal: detected on-shelf state. When that signal disagrees with stock-on-hand, you have surfaced a phantom-stock event — an in-system, off-shelf SKU that the ledger alone would never have flagged. We cover the detection mechanics in depth in how shelf-execution AI catches stock-outs and planogram drift without hardware replacement; the relationship to availability accounting is laid out in inventory control explained: how shelf-execution AI fits into on-shelf availability. The two systems are complementary, not competing. Shelf-execution AI does not replace your inventory control software, and it does not try to. It pairs with it — the ledger gives you the expected state, the vision layer gives you the observed state, and the divergence between them is the operational signal you act on. This is the heart of how shelf-execution detection corrects ledger-vs-shelf divergence. Comparison Matrix: Inventory Control Software vs Shelf-Execution AI vs Dedicated Shelf Products The market offers more than two options. Dedicated shelf-monitoring products — Captana/Vusion, ShelfView and similar — sit between the pure ledger and a flexible CV layer. The honest comparison is about what each does on the shelf and what it costs to run. Dimension Inventory Control Software (ERP/WMS/POS) Dedicated Shelf-Monitoring Product (e.g. Captana/Vusion, ShelfView) CV Shelf-Execution Layer on Existing Devices What it knows Stock-on-hand, movement, reorder point Detected shelf state via dedicated sensors/cameras Detected shelf state via existing cameras + staff mobile devices Source of truth for Ledger / ownership Physical fixture (proprietary hardware) Physical fixture (reused hardware) Sees phantom stock? No — ledger only Yes Yes Detects planogram drift? No Yes, within installed coverage Yes, where camera/device coverage exists Hardware requirement None new Proprietary shelf rails / cameras / gateways Reuses store cameras and mobile devices Capital posture Already owned New procurement cycle Avoids procurement; engineering layer Integration Native to retail ops Vendor ecosystem, often closed Integrates into existing inventory + ops workflow Best when You need accurate ownership accounting You want turnkey shelf sensing and accept the hardware lock-in You want to close the phantom-stock gap on infrastructure you already run (Comparison reflects observed product positioning across retail-CV engagements; not a head-to-head benchmark of any named product.) The matrix is not declaring a winner — each column wins under different conditions. A retailer with no usable in-store cameras and an appetite for turnkey hardware may rationally choose the dedicated product. A retailer that already runs loss-prevention cameras and staff handhelds has a different calculus: the observation problem can often be solved on hardware that is already capitalised. What Hardware Does the Shelf-Execution Layer Actually Need? This is where the cost story turns, and it is worth being precise rather than optimistic. A shelf-execution CV layer needs three things: a viewpoint on the shelf, enough compute to run inference, and a workflow to route the result to a human who can act. In many stores, the first two already exist. Loss-prevention and operations cameras frequently have usable angles on fixtures, and staff carry mobile devices that can capture targeted shelf images on a walk. The open question is never “is there a camera” — it is “can that camera’s stream, at that resolution and angle, actually support reliable product detection, and is there enough on-prem or edge compute to run the models at the cadence you need.” That is an empirical question about a specific store’s hardware, not a spec-sheet assumption. This is exactly the scope of a GPU performance audit: before committing to a deployment, measure whether the existing devices can run the shelf-execution layer at the required throughput, or whether a modest edge box is needed. The audit’s payoff is avoiding a full proprietary-hardware procurement cycle when the store’s existing infrastructure — possibly with a single shared inference node — is sufficient. The avoided procurement is itself an ROI anchor, alongside the avoided lost sales on out-of-stock SKUs. We have seen teams assume their cameras were unusable and others assume they were fine; both assumptions are cheaper to test than to act on blindly. The general failure pattern when off-the-shelf models meet real store conditions is covered in why off-the-shelf CV breaks at retail scale — it is a useful prior on why “just point a camera at it” rarely survives contact with a real fixture. How Do You Measure On-Shelf Availability Against System Stock-on-Hand? The measurement that makes this whole exercise operational is a comparison, not a single number. You take the inventory system’s stock-on-hand and you take the vision layer’s detected on-shelf state, SKU by SKU, and you count where they disagree. Three metrics fall out: On-shelf availability rate — the share of SKUs the vision layer confirms present on the fixture, measured against the set the ledger says should be available. In-system, off-shelf SKU count — the absolute number of phantom-stock events surfaced per store per period. This is the gap, made countable. Time-to-restock from detection — how long it takes, from the moment the divergence is flagged, for a human to close it. These are operational measurements, not benchmarks — they come from the deployed system in a specific store, and they will vary with fixture density, traffic, and staffing. The point is that the gap stops being invisible. A team running only inventory control software cannot produce any of these numbers, because it has only one of the two signals the comparison requires. What the Operational Workflow Looks Like When a Divergence Fires A divergence is only worth detecting if it routes to action. The loop is short by design: the vision layer detects that a SKU the ledger calls in-stock is absent or misplaced on the fixture, it raises a task to a staff member’s mobile device with the slot location, the staff member checks the backroom or corrects the facing, and the resolution is logged. That log is what feeds time-to-restock. The detail that matters operationally is suppression — you do not want to fire a restock task for every transient gap a shopper creates by picking up the last front-facing unit when three sit behind it. Tuning the detection threshold and the confirmation logic to the store’s actual replenishment rhythm is where the engineering effort concentrates, and it is store-specific. The worked end-to-end version of this loop, from detection to closed task, is walked through in inventory control example: how shelf-execution AI closes the out-of-stock loop. FAQ How does inventory control software work, and what does it mean in practice? Inventory control software is an accounting engine for goods: it increments stock-on-hand at receiving, decrements it at the till, and reconciles those movements against purchase orders and cycle counts. In practice it answers ownership and reorder questions accurately, but it tracks the ledger view of inventory — it has no mechanism to observe the physical fixture, so it cannot confirm an item is actually on the shelf. Why does inventory software say a SKU is in stock while the shelf is empty (the phantom-stock gap)? Because the ledger only knows what it was told at receiving and at the till. Units can be stranded in the backroom, mis-shelved into the wrong slot, lost to shrink, or mis-keyed at receiving — all of which leave the system counting stock that a shopper cannot reach. These events live in the gap between the ledger and the shelf, invisible to a system with no eyes on the fixture. Where does inventory control software end and shelf-execution AI begin? Inventory control software owns the ledger — what you own and where it should be. Shelf-execution AI owns the observation — what is physically present on the fixture, compared against both the ledger and the planogram. The two are complementary: the divergence between expected state and observed state is the operational signal, and the vision layer does not replace the inventory system. What hardware does a shelf-execution layer need on top of an existing inventory system, or can it reuse what’s already in the store? It needs a viewpoint on the shelf, enough compute to run inference, and a workflow to route results to staff. In many stores the cameras and mobile devices already exist — the real question is whether their resolution, angle, and available compute can support reliable detection at the required cadence. That is an empirical, store-specific question best answered by a performance audit before committing to any new procurement. How do you measure on-shelf availability against system stock-on-hand? By comparing the two signals SKU by SKU: the ledger’s stock-on-hand against the vision layer’s detected on-shelf state. The comparison yields an on-shelf availability rate, a count of in-system-but-off-shelf SKUs, and time-to-restock from detection. A team running only inventory software cannot produce these numbers because it has just one of the two required signals. What does the operational workflow look like when the shelf-execution layer flags a ledger-vs-shelf divergence? The vision layer detects an absent or misplaced SKU the ledger calls in-stock, raises a task with the slot location to a staff member’s mobile device, the staff member checks the backroom or corrects the facing, and the resolution is logged. The engineering effort concentrates on suppression logic — tuning thresholds so transient shopper-created gaps do not generate noise tasks. How do dedicated shelf-execution products (e.g. Captana/Vusion, ShelfView) compare to a CV layer that runs on the cameras and mobile devices a store already has? Dedicated products deliver turnkey shelf sensing but require a proprietary-hardware procurement cycle and tend toward ecosystem lock-in. A CV layer on existing devices avoids that procurement by reusing cameras and handhelds the store already runs, at the cost of upfront engineering to validate coverage and tune detection. Neither is universally better — the choice turns on whether the store has usable existing infrastructure and its appetite for new hardware. Where the Ledger Ends and the Shelf Begins The mistake is not in the inventory control software. It does its job — it keeps an accurate ledger. The mistake is asking the ledger to answer a question it was never built to answer: what is on the shelf right now. That question is a physical-execution problem, and it is answered by observation, not accounting. If you are weighing a shelf-execution layer, the first decision is not which product to buy — it is whether the store’s existing cameras and devices can carry the observation load, or whether the gap genuinely warrants new hardware. That is a measurement, not a guess, and it is cheaper to run than to assume in either direction.
