Inventory Management: Ensuring Stock Accuracy

Stock discrepancies are expensive. A 2023 IHL Group study estimated that inventory distortion — the combined cost of overstocks and out-of-stocks — costs retailers globally around $1.77 trillion per year. If you are building or buying an inventory management system, accuracy is the core engineering problem, not a feature on top of it.

This post covers how modern inventory systems maintain stock accuracy: the data models, the sync strategies, the failure modes, and the trade-offs you will actually face.

Why Stock Inaccuracy Happens in the First Place

Inaccuracy is almost never one thing. It compounds from several sources simultaneously.

Concurrent writes without proper isolation. Two warehouse workers scan the same bin at the same time. Both reads show 10 units. Both write back 9 after a pick. The system now shows 9, but the actual count is 8.

Async integrations with no reconciliation. A POS system sends sales events over a message queue. The inventory service consumes them. If a message is processed twice (at-least-once delivery semantics) and the consumer is not idempotent, you subtract stock twice.

Shrinkage and damage that goes unrecorded. Broken items, theft, and expired goods all reduce physical stock without touching the system. No software solves this on its own. Cycle counting and periodic audits are the only control.

Long batch sync windows. If your ERP syncs stock levels to your e-commerce platform every 4 hours, you can oversell during that window. This is a systemic architectural choice, not a bug.

Understanding which category your inaccuracies fall into determines what you actually need to build.

What Does a Reliable Inventory Data Model Look Like?

Most naive implementations store inventory as a single integer: quantity_on_hand. This breaks under any real concurrency.

A more reliable model separates stock into distinct states:

State	Description
on_hand	Physically present in the warehouse
reserved	Committed to an open order but not yet picked
available	on_hand minus reserved
in_transit	Shipped from supplier, not yet received
quarantined	Received but pending quality check

The field your checkout logic should read is available, not on_hand. Many teams get this wrong early and pay for it later.

Beyond the snapshot fields, you need an inventory ledger: an append-only event log of every quantity change, with source, timestamp, reference document (order ID, PO number, adjustment reason), and the actor. The ledger is what lets you reconstruct on_hand at any point in time and answer audit queries without guessing.

Reservation and Release Patterns

When a customer places an order, reserve the quantity immediately before payment confirmation. If payment fails, release the reservation. If the release event is lost (network failure, crash), you need a scheduled job that sweeps stale reservations older than a defined TTL, typically 15 to 30 minutes for consumer checkouts.

PostgreSQL advisory locks or SELECT ... FOR UPDATE SKIP LOCKED work well for this at moderate scale. For higher throughput, Redis with Lua scripts gives you atomic check-and-decrement without a database round-trip.

How Do You Keep Multiple Channels in Sync?

If you sell across a physical store, a website, a mobile app, and a marketplace like Amazon, all channels read from the same inventory pool. The synchronisation architecture matters more than the individual channel integrations.

Event-driven over polling. Polling at 5-minute intervals means you are always working with stale data. Publish an inventory.updated event every time stock changes, and let downstream consumers react. Kafka or RabbitMQ both work. The key is that the inventory service owns the truth, and everything else is a projection.

Buffer stock for marketplaces. Marketplace integrations have propagation delays. Amazon's inventory API can take minutes to reflect a change. A common practice is to list a quantity 5 to 10% lower than actual available stock on external channels to absorb the lag. This is a deliberate trade-off: you accept some phantom stock capacity in exchange for fewer oversells.

Idempotent consumers. Every consumer of your inventory events must handle duplicate messages without double-applying the change. Store the event ID and reject re-processed events. This is non-negotiable in any at-least-once message delivery system.

What Should Your Cycle Counting Strategy Cover?

A perpetual inventory system's accuracy degrades over time without physical verification. Cycle counting is the engineering-adjacent operations practice that keeps the data grounded in reality.

Rather than an annual full stocktake, cycle counting counts a rotating subset of SKUs continuously. High-velocity and high-value items should be counted weekly or even daily. Slow movers can be counted monthly or quarterly.

The system's job is to:

• Flag items for counting based on velocity, value, and days since last count
• Record the physical count against the system count
• Compute the variance and generate an adjustment transaction in the ledger
• Trigger a recount if variance exceeds a defined threshold (typically more than 2% by value)

Do not auto-approve adjustments above a threshold. Large variances need a human sign-off and an investigation before the ledger is corrected. Otherwise, you are just laundering bad data.

RFID and Barcode Trade-offs

Barcode scanning is cheap and accurate but requires deliberate scan actions. A picker who forgets to scan introduces silent errors.

RFID allows passive scanning at read points — goods move through a gate and are counted automatically. Accuracy rates in RFID-enabled warehouses are typically cited at 95 to 99%, compared to 65 to 75% for manual barcode processes (Auburn University RFID Lab, 2020). The trade-off is cost: RFID tags run $0.10 to $0.50 per unit, and reader infrastructure is significant. It makes sense for high-value items or high-throughput distribution centres, not for every use case.

Handling the Edge Cases That Break Systems

A few scenarios cause disproportionate pain:

Negative stock. If your system allows negative available quantities, you have a logic gap somewhere. Set a database constraint or application-level guard. Investigate every instance; do not just patch the number.

Multi-location inventory. Once you have multiple warehouses or stores, every stock query needs a location dimension. SKU X available at warehouse A is not interchangeable with SKU X available at warehouse B, depending on fulfilment routing. Model this from the start; retrofitting location awareness into a single-location model is painful.

Bundles and kits. If a bundle contains components A, B, and C, the bundle's available quantity is min(available(A), available(B), available(C)). Selling a bundle must decrement all three components atomically. This is a common source of oversell bugs.

Returns. A returned item may or may not be resaleable. Blind re-addition to on_hand on return creates phantom stock. Returns should enter a quarantine state and require an explicit inspection-and-receive step before going back to available.

Conclusion

Stock accuracy is an engineering and process problem in equal measure. The data model, the event architecture, and the physical counting procedures all have to work together. Getting the ledger right and making all writes idempotent solves the majority of software-caused discrepancies. The rest requires operational discipline.

If you are currently seeing persistent variances and are not sure where they originate, the first step is instrumenting your adjustment transactions with source and reason codes. That data tells you which category of inaccuracy dominates, and that tells you where to invest next.

FAQ

What is the difference between on-hand and available inventory? On-hand is the physical quantity in your warehouse. Available is on-hand minus any quantity reserved for open orders. Checkout logic should always read available, not on-hand. Reading on-hand is the single most common cause of overselling in early-stage commerce systems.

How often should cycle counts run? For high-velocity SKUs, weekly or daily. For low-velocity items, monthly to quarterly is usually sufficient. The goal is that every SKU gets counted at least once per quarter. Systems should schedule counts automatically based on velocity, value, and days since the last count rather than relying on manual scheduling.

Is RFID worth it for a mid-sized warehouse? Depends on your SKU value and throughput. RFID delivers 95 to 99% passive scan accuracy but carries meaningful tag and infrastructure costs. If you are handling high-value electronics or pharmaceutical goods and process thousands of picks per day, the ROI is often clear. For lower-value goods or lower volumes, barcode scanning with strong process controls is usually sufficient.

How do you prevent overselling across multiple sales channels? Maintain a single authoritative inventory service that all channels read from. Publish stock-change events rather than polling. Apply a buffer to external marketplace listings to absorb propagation delay. Never let individual channel integrations write directly to stock levels; they should only publish demand events that the inventory service processes.

What causes phantom stock in inventory systems? Phantom stock — the system showing units that do not physically exist — typically comes from unrecorded shrinkage, failed return inspections, duplicate message processing, or missing downward adjustments. An append-only ledger with source tracking makes the origin of discrepancies auditable and is the most effective tool for diagnosing phantom stock systematically.

Have a project in mind? Contact Sodio Technologies to discuss your requirements and explore the right technology solution for your business.