Bottom line first: when OMS and WMS inventory don't match, it's almost never a system bug. This OMS WMS inventory mismatch lives in one of five places. Check all five before you start questioning your life choices. I've done 30+ go-lives, and I've seen this exact pit three times — every time the client blamed the software first, and every time the root cause turned out to be process or configuration.
Why do these two systems disagree so often? Because they're not counting the same thing. OMS counts "sellable stock" — what you can promise a customer. WMS counts "physical stock" — what's actually sitting in a bin location. One manages sales commitments, the other manages physical reality, and between them sit orders, in-transit goods, returns, and unit conversions. Any misalignment in that chain splits the numbers.
Here are the five checkpoints, in the order I investigate them. Each comes with "how to verify" and "how to fix." Follow the steps.
Category One: Timing — Sync Lag and Unposted In-Transit
Checkpoint 1: sync lag. In most projects, OMS-to-WMS data sync is not real time — it's a scheduled job, commonly every 15 minutes, 30 minutes, or even an hour. During a peak sale, WMS has already shipped 200 units while OMS is still waiting for the next sync run. Of course the numbers disagree.
How to verify: pick an order that just shipped. Compare the timestamp of the inventory change in OMS with the ship-confirm timestamp in WMS. If the gap equals your sync interval, that's your culprit.
How to fix: short term, shrink the sync interval (during peak periods I usually recommend under five minutes). Long term, push critical events like ship-confirms and receipts in real time instead of relying on batch jobs. Note: shorter intervals add system load — clear it with IT first.
Checkpoint 2: in-transit never deducted. Goods are picked, loaded, and gone — but OMS never updated the in-transit status, or the WMS ship-confirm lagged a step. The inventory falls into a no-man's-land where neither system claims it. I've seen this pit three times, and it always explodes the night before a big sale.
How to verify: in WMS, pull "allocated but not shipped" and "shipped but not confirmed" documents and look for backlogs. Then check OMS's available-to-promise logic for the same window — whether in-transit is deducted will be obvious.
How to fix: lock down the WMS ship-confirm step. Once the truck is scanned out, confirmation must happen the same day — "we'll do it tomorrow" is banned. On the OMS side, the available-to-promise formula must explicitly deduct in-transit, written into the requirements document, not agreed verbally.
Category Two: Process — Returns Never Put Away and Unit Conversions
Checkpoint 3: returns never put away. Last year, an apparel client showed 2,000 units of a hot SKU in OMS the night before a major sale — while WMS showed zero. Marketing nearly pulled the product page. The root cause: returned goods had been sitting in the receiving area for three days, QC untouched, still "pending" in WMS, while OMS had already added the return quantities back to sellable stock. a textbook OMS WMS inventory mismatch pattern.
How to verify: pull the "receiving area pending" report in WMS and see how many returns are piled up. Then check when OMS adds returns back — if OMS restores sellable quantity the moment the customer ships the return back, the definition is wrong.
How to fix: returns must complete the full "receive, inspect, put away" flow. OMS may only restore sellable stock after WMS confirms putaway. Any receiving-area backlog older than 24 hours triggers an alert — write that rule into the SOP.
Checkpoint 4: unit conversion. The dumbest and most common one. OMS sells in "cases," WMS tracks in "eaches" — 12 units per case. Get the conversion factor wrong and inventory is off by an order of magnitude. I watched one project inflate its entire inventory twelvefold in the first week of go-live because the factor was set to 1.
How to verify: pick any SKU, check the stock unit in OMS and in WMS, then check the conversion factor in the interface. Line up all three — the error jumps out.
How to fix: audit conversion factors for every SKU once, completely. For new items, make "sales unit, stock unit, conversion factor" a mandatory trio at item setup — missing one, no item created.
Category Three: Configuration — Wrong Multi-Warehouse Mapping, and the Real OMS WMS Inventory Mismatch
Checkpoint 5: wrong warehouse mapping. "East China DC" in OMS might be two physical buildings — "Shanghai WH-1" plus "Shanghai WH-2" — in WMS. Map one of them wrong and the OMS number will never reconcile with WMS. This one stings the most, because both systems are individually correct.
How to verify: list every logical warehouse in OMS and the physical warehouses it maps to in WMS, then check them one by one. Any new, merged, or renamed warehouse — check the mapping table first.
How to fix: maintain the warehouse mapping table separately. Any new, merged, or renamed warehouse must update the mapping table before go-live. Review the mapping table monthly.
The counterintuitive truth: both sides are "right" — the reconciliation definition itself is wrong. Many investigations end here: OMS is right, WMS is right, but the two systems define "inventory" differently. Available-to-promise equals physical stock minus allocated minus in-transit minus QC-hold minus safety stock — both sides must use the same formula. If the definitions don't align, you'll reconcile ten thousand times and never match. Unify the formula before you reconcile anything.
Go-Live Night Checklist: Preventing the Next OMS WMS Inventory Mismatch
Every go-live night, I make the client walk this list and sign it before anyone sleeps:
- Sync job interval and monitoring alerts — configured?
- Ship-confirm and return-putaway time limits — written into the SOP?
- All-SKU unit conversion factors — audited?
- Warehouse mapping table — the latest version?
- Available-to-promise formula — identical on both sides?
All five checked, and the odds of an OMS WMS inventory mismatch drop to a minimum. And a sixth item: keep one person on site who understands both the business and the systems. When something breaks, find the person first — don't reboot the server first.
By Lin Xiao, WMS Implementation Consultant
