Inventory in Store and Online: How to Stop Selling an Item Already Sold at the Till

Overselling happens because the till and the website each hold their own picture of what is left, and the till writes first. Preventing it takes three things: one available-to-promise calculation, a reservation created when payment starts rather than when it clears, and a reconciliation job that compares movements instead of final quantities.

Why the till wins the race for the last unit

The till wins because an in-store sale is one atomic action while a web sale is a sequence of four steps, each taking time. Here is a worked case: SKU FR-2210-42, one unit at the Ramat Gan branch.

• 14:32:07 - the assistant scans the barcode. The record is written locally.
• 14:32:09 - a web customer clicks Pay on the same SKU. The page checked availability 40 seconds earlier.
• 14:32:11 - the gateway approves the charge. A web order now exists.
• 14:32:14 - the till transmits the sale movement to the ERP.
• 14:32:38 - the storefront pulls a stock feed and sets the quantity to 0, twenty-seven seconds late.

Two documents, one unit. Note that nothing malfunctioned. Every system did precisely what it was designed to do, and the whole failure lives between 14:32:07 and 14:32:38. Any fix that does not touch that window - a faster sync plugin, a new inventory system, a daily report - will not prevent the next occurrence.

What the word "available" actually means

Available is the output of a calculation, not a field anyone writes. The formula that holds up:

available = on hand - committed to unfulfilled orders - reserved for open carts - unavailable buckets - safety stock

Shopify's GraphQL Admin API documents eight distinct quantity states: incoming, on_hand, available, committed, reserved, damaged, safety_stock and quality_control, where on_hand is the sum of available, committed and unavailable. The documentation also states that quantities in the committed state cannot be adjusted or moved through the API, because they are derived from orders. WooCommerce works differently: an order arrives as pending, and stock is actually reduced when the order moves to processing or on-hold.

That last row causes a disproportionate share of gaps: a return taken at the till re-enters stock at once, while on the website it does not exist until somebody approves it.

Reservation or available-to-promise - which one do you need?

Reservation is right when the unit is identified; available-to-promise is right when units are interchangeable. They are not substitutes for one another:

• Reservation holds a specific unit or quantity for a specific order, with an expiry and an owner. Correct for a frame by serial number, a vehicle, a floor-model appliance.
• Available-to-promise computes how much can be promised right now without holding a specific unit. Correct for a shirt in size M, for screws, for anything counted rather than identified.
• The deciding rule: if returning a unit to stock requires a human action, you need a reservation with an expiry. If it happens anyway when an order is cancelled, a calculation is enough.

Where serial numbers exist the choice is already made - see serial inventory in an optical store.

How much sync latency can you actually afford?

A SKU's risk window equals sync latency multiplied by its sales rate, so the answer differs per SKU. The arithmetic: an item selling 10 times a day across a 10-hour trading day sells on average once every 60 minutes, so a 5-minute sync lag creates roughly an 8% chance of a double sale while one unit remains. The same lag on an item selling once a week is noise.

The design consequence is that you do not sync everything at the same cadence:

1. SKUs at one or two units move to push updates from the till, not a scheduled feed.
2. SKUs with deep stock stay on periodic sync, which is far cheaper in API call quota.
3. Any SKU crossing the threshold you set moves into group one automatically.
4. When the storefront API throttles you, tier the items rather than raise the frequency - covered in handling 429 rate limits in store sync.

What the site shows when sync goes down

When sync fails, the default is to stop promising rather than keep selling against a stale number. That decision is made in advance, in writing, per product group:

• Show "out of stock" for SKUs below your threshold instead of a quantity nobody can vouch for.
• Allow an order with an extended lead time and a staff check, instead of promising next-day delivery.
• Block serialised items outright, because a duplicate sale of an identified unit cannot be compensated easily.
• Record the outage window, so that day's reconciliation knows which interval to examine.
• Alert a person, not only a log. A sync that fails silently is the single largest source of drift.

In Shopify, whether a variant keeps selling at zero is controlled by inventoryPolicy at the variant level, with exactly two values: DENY and CONTINUE. That is a commercial decision recorded in code, not a default worth inheriting.

The reconciliation job that finds the cause, not just the gap

A reconciliation comparing final quantities tells you two units are missing and nothing else. A reconciliation comparing movements tells you exactly which movement was dropped. So every stock movement is stored as a record, not as an update to a quantity field:

With that structure the nightly job runs one query: the sum of qty_delta per SKU against the quantity each system reports. A gap is presented together with the movements that produced it, and the distance between occurred_at and synced_at immediately says whether the cause was slow sync or a movement that never arrived at all. The wider version of this layer against a central system is covered in connecting an online store to an ERP.

Sources

• Shopify - Manage inventory quantities and states
• Shopify - ProductVariantInventoryPolicy enum
• WooCommerce - Order statuses