Every business that holds physical stock eventually sends the email: “We’re sorry — the item you ordered is actually out of stock.” It reads like an apology for carelessness. It almost never is. Overselling is not a diligence problem; it is an architecture problem, and it has a precise, boring, hundred-percent-effective fix.
This post explains the mechanism — what “available” actually means, what a reservation is, and why the fix cannot live in a spreadsheet no matter how disciplined you are.
Three numbers that get called “stock”
Confusion starts with vocabulary. “How many do we have?” is three different questions:
On-hand — physical units on the shelf. What a warehouse count verifies.
Reserved — units committed to orders that have not shipped yet. Still on the shelf, still counted on-hand, but spoken for.
Available (available-to-promise, ATP) — what you can still sell:
available = on-hand − reserved
That subtraction is the entire subject. Every overselling incident, traced to its root, is a promise made from on-hand when it should have been made from available.
The anatomy of an oversell
Say you hold 5 units. Two orders for 3 arrive — a webshop order at 2:14 p.m. and a chat-assisted order at 2:16 p.m.
If your system checks on-hand: order one passes (5 ≥ 3). Nothing was recorded as committed, so two minutes later order two also passes (5 ≥ 3). You have now promised 6 of your 5 units, and both customers got a confirmation email. You will discover it at pick time, days later, and choose which customer to disappoint.
If your system reserves: order one checks available (5), passes, and reserves 3 in the same atomic operation. Available is now 2. Order two checks available (2 < 3) and is told the truth at 2:16 p.m. — when the customer can still decide, substitute or backorder — instead of being lied to and corrected next Tuesday.
Notice what did not cause the incident: nobody was careless, no count was wrong, no one forgot to update anything. The system answered the question it was asked. It was asked the wrong question.
Why the fix has to be atomic, and why the spreadsheet cannot do it
There is a subtler version of the failure that catches even teams who understand ATP: the check and the reservation happen as two separate steps. Two orders arrive in the same second; both check available (both see 5); both then reserve. The check passed for both because neither reservation existed yet at check time. This is a textbook race condition, and it does not care how rare “same second” is — at Black Friday volume, rare becomes routine.
The fix is that check-and-reserve must be one atomic operation at the data layer: verify availability and commit the reservation in a single step no concurrent order can interleave. In Oneop’s inventory module this is the core enforced invariant — available equals on-hand minus reserved and cannot go negative — so a sales order that would oversell committed stock is refused by the system itself, not by a process someone remembers to follow.
This is also the argument against stock truth in a spreadsheet, or split across a store, a marketplace and an ERP reconciled by sync jobs. A copy updated on a schedule cannot participate in an atomic check — by definition it answers with the state as of the last sync. Every sync window is an overselling window. (This is a special case of a general principle we keep returning to: handoffs between systems are where numbers change.)
The lifecycle of a promise
Reservations are one stage of a pipeline, and each transition has a job:
- Order placed → stock reserved. The promise becomes a durable record. Available drops; on-hand does not.
- Picking → shipment. The reservation converts to a physical movement. On-hand drops; the reservation is consumed. In Oneop this flows through sales orders, reservations, picking and shipment as connected stages, with labels and tracking bought from nine integrated carriers.
- Cancellation or void → release. The often-forgotten path: when an order dies, its reservation must die with it, or you get undersell — real stock you cannot sell because a ghost order holds it. Phantom reservations are the mirror image of overselling and just as expensive; they simply fail silently. (In Oneop, voiding an invoice releases the stock it had reserved as part of the same operation.)
- Return → RMA → restock. Returned units re-enter on-hand through an inspection step, not by someone typing a new number.
When every transition is a state change in one system, the ledger of promises always matches the ledger of stuff — for the same reason double-entry accounting always balances: the invariant is enforced where the data lives, not reconstructed afterwards.
Multi-warehouse: the same rule, per location
With two or more locations, availability must be computed per warehouse — 10 units in Lahore and 0 in Dubai is not “10 available” for an order shipping tomorrow from Dubai. The mechanics stay identical; the scope narrows: reservations are held against a specific warehouse (and bin and lot, where you track those), and transfers between sites move stock through the same reserved-in-transit logic rather than a delete-here-add-there edit that briefly double-counts.
What about forecasting?
ATP answers “can I promise this order?” A different question — “how much should I reorder?” — is where statistics (not promises) belong. Demand forecasting over historical movements, ABC classification, dead-stock detection: useful, and in Oneop genuinely quantitative — the demand forecast uses Holt’s double exponential smoothing over real issue history. We are precise about what that is: statistical forecasting, not AI. A forecast informs a purchase order; it should never inflate the availability number a customer-facing promise is made from. Promises come from arithmetic, forecasts from models, and a system that blurs the two will eventually promise a prediction.
The checklist
Run your current setup against five questions:
- Does every order-taking surface check available, not on-hand?
- Is check-and-reserve atomic — provably safe against two simultaneous orders?
- Do cancellations and voids release reservations automatically?
- Is availability computed per warehouse?
- Is there exactly one system of record for stock, or a sync schedule you are hoping stays lucky?
If any answer is no, you do not have an overselling risk — you have an overselling schedule, and volume decides the date.
Oneop’s inventory and warehouse module — reservations, per-warehouse availability, lot and bin tracking, purchase orders, RMAs and carrier shipping — is part of the platform, with the no-negative-availability invariant enforced in code, and the free plan covers 20 products in one warehouse. Enough to watch the arithmetic hold before your next busy season tests it.