The system shows 500 units on hand. Customer service will only sell 300. Then a promotion launches, the storefront says "in stock," the warehouse says "we don't have it," and oversell penalties start landing. Nine out of ten OMS implementations I've seen start with a broken inventory model. The system isn't the problem — the problem is that "inventory" is treated as one number when it's really four waterlines.
On-hand is not available-to-sell
The first waterline is on-hand inventory: the total count for a SKU in the WMS. Plenty of companies push this number straight to the storefront as the sellable quantity. That's oversell source number one. Mixed into that on-hand total are several kinds of unsellable stock: units in QA hold, damaged units awaiting disposition, units locked for cycle count, and customer returns that haven't been graded for resale yet.
The fix: the OMS should only recognize "available on-hand" — the total minus every frozen, QA-held, and damaged unit. This filtering belongs in the WMS-to-OMS interface, hardcoded by inventory status, not in a daily manual reconciliation. I worked with a beauty e-commerce company whose returns had a 60% resale rate but sat in "pending grading" for an average of four days. Count those four days as sellable and overselling is guaranteed.
Reservations: inventory that already has an owner
The second waterline is allocated inventory. The moment an order drops, the OMS bites off the corresponding stock. It's still sitting on the shelf, but it's spoken for. Reservations come in two flavors: hard allocation, tied to specific lots and locations that nobody else can touch, and soft allocation, which holds quantity while the exact pick location gets decided later.
The trap is in releasing reservations. Order cancelled, partial stockout, payment timeout — does the reservation release immediately? Release too early and another order for the same SKU grabs it; release too late and zombie orders squat on stock the storefront can't sell. My defaults: payment-timeout reservations auto-release after 30 minutes; agent-cancelled orders release in real time; partially shorted orders release the shorted lines and keep the confirmed ones. Encode these as policies in the OMS, not as clicks for the service team.
In-transit and QA hold: selling the future
The third waterline is in-transit inventory: ordered, not yet received. A good OMS segments in-transit by expected arrival date. Arriving within three days? You can pre-sell a portion of it. Fifteen days out? Show it as out of stock and mean it. The pre-sell ratio should follow the supplier's historical on-time rate — above 95%, pre-selling 80% is defensible; chronically late, pre-sell nothing.
QA hold is the sibling problem. Goods arrive, sit in the inspection zone, and the WMS hasn't put them away yet. During that window the OMS should show "in transit / under inspection," not add them to sellable stock. For categories with long inspection cycles — food, cosmetics, consumer electronics — QA can run two days to a week, and that inventory state has to be visible or customer service and the warehouse will fight daily.
Safety stock: the buffer everyone raids
The fourth waterline is safety stock, the cushion against uncertainty: late suppliers, demand spikes, count variances. It isn't guesswork — the math is straightforward: take the SKU's average daily sales and variability over the last 90 days, combine with replenishment lead-time variability, and the wilder both are, the thicker the cushion. ABC classification earns its keep here: A-items get safety stock calculated to the day; C-items can be rough, since they're cheap anyway.
Safety stock's worst enemy is "borrowing." A promotion launches, operations sees units sitting in the buffer, and sells them. Then everyday orders stock out. Make the rule ironclad: touching safety stock requires approval, and touching it triggers a replenishment. Put that in the SOP — it outperforms any software.
Multi-warehouse: split the waterlines per building
Everything above is single-warehouse thinking. Multi-warehouse companies must compute the waterlines per facility, then aggregate. Why? Because "in stock" at warehouse A means nothing to a customer served by warehouse B three days of transit away.
The standard pattern is closest-fulfillment plus per-warehouse ATP. Each building computes its own four waterlines; order routing prefers the nearest building with sellable stock. Only when every building's sellable quantity is zero should cross-warehouse transfer fulfillment be allowed — and the transfer transit time goes into the promised delivery date. Some companies aggregate network inventory into one pretty "in stock" badge, then route orders to empty buildings and watch SLAs collapse in a flurry of internal transfers. Remember: the aggregate number is for management dashboards; fulfillment runs on per-building numbers.
Transfers themselves belong in the model. The moment a transfer order is confirmed, the shipping building's sellable quantity drops immediately and the receiving building's in-transit gains an expected arrival date. Too many companies run transfers through a group chat with no system document, and the books never reconcile. Transfers must be system transactions. Non-negotiable.
One formula to tie it together
Available to promise = available on-hand − reservations − safety stock + confirmed in-transit (time-phased and discounted).
The formula is easy; data quality is the hard part. When you oversell, don't yell at the system — walk this debug chain. One: is on-hand accurate? Count first; if the books don't match the floor, nothing else matters. Pay special attention to the QA and returns zones, where variances love to hide. Two: are reservations releasing on time? Pull a report on zombie reservations held by dead orders — if they exceed five percent of sellable stock, change the rules. Three: are in-transit dates honest? Score suppliers on six months of on-time arrivals; habitual optimists get a zero pre-sell ratio. Four: was safety stock raided? Check promotion-period movements — if it moved without approval, fix the process before restocking.
That chain finds the root cause nine times out of ten. The tenth is usually interface latency: if WMS-to-OMS sync runs on a 15-minute batch, peak season sells and receives plenty inside that blind window. During promotions, push sync to real time or one-minute intervals. The extra server cost is cheaper than oversell penalties.
Final verdict: there's no silver bullet in OMS inventory modeling, just one iron rule — the finer your inventory states, the fewer your oversells. Companies too lazy to split their states will pay the tuition in penalty fees. Get the four waterlines straight, and the number service dares to sell will finally match what the warehouse actually has.
