The phone rang at 2:30 in the morning. It was customer service, and the rep sounded like she was about to cry. "A customer placed an order, the OMS shows 40 units available, the picker went to the slot and found — nothing. Not even a corner of a carton on the rack."
I have taken that call more than once. Every incident plays out the same way: IT says the interface logs are clean, operations says the books are clean, and both sides spend the meeting blaming each other. The warehouse crew takes the heat. Overselling does not just cost you that one order — marketplace penalties, seller rating hits, bad reviews. The full combo costs far more than those 40 units ever would.
After enough of these, I have learned that OMS-WMS inventory mismatches come down to the same five root causes, every time. And there is a fixed sequence for finding which one you are dealing with. Work it in order and most incidents get located within half an hour.
When the Numbers Disagree, It Is One of Five Things
Assign the blame correctly before anyone starts arguing. Arguing first is the most expensive way to spend an incident.
First, sync lag. Most OMS-WMS integrations sync on a schedule, not in real time. Inside the sync window, the two systems are supposed to disagree — that is by design, not a bug. A surprising number of "mismatches" turn out to be someone comparing the OMS number from five minutes ago against the WMS number right now. Compare timestamps before you compare quantities.
Second, in-transit stock never deducted. Orders allocated, picks in progress, staged for shipment — the WMS has already pulled those units out of "available," but the OMS still shows them sitting in on-hand. During peak season, with thousands of orders a day, in-transit volume alone can open a gap of several hundred units between the two systems.
Third, returns received but never posted back. The WMS received the return and put it away; the physical goods are back. But the message posting that return to the OMS got lost or failed. The OMS still thinks those units were sold, so available-to-promise runs permanently low, and the gap keeps growing.
Fourth, cycle count adjustments never synced. The WMS ran counts, booked the gains and losses, and the adjustment never made it to the OMS. Over time the two sides drift further apart, and the drift looks random, which makes it miserable to investigate.
Fifth, broken multi-warehouse mapping. The OMS "Los Angeles DC" maps to two physical buildings in the WMS, or a new fulfillment site was created in the OMS but never added to the WMS mapping table. This one is the sneakiest: each system is internally consistent, and everything looks wrong only when you compare them.
Here is the rule of thumb I use: when each system looks right on its own and wrong only in comparison, suspect mapping or sync definitions. When the gap keeps growing over time, suspect returns or count adjustments that stopped flowing.
A real example. Last year, a home-goods e-commerce warehouse showed a gap of two to three hundred units every Monday morning, clean the rest of the week. We worked the sequence — timestamps, in-transit, returns, counts all checked out. It turned out the weekend night shift had done slot moves in the WMS using an old building code. The mapping table had no entry for that code, so the whole batch of adjustments was silently dropped on the way to the OMS. Monday morning showed the biggest gap, and normal weekday shipping gradually "diluted" it, producing a perfect weekly cycle. When a discrepancy has a rhythm, watch the pattern, not just the numbers.
When It Breaks, Work the Steps Before the Blame
Do not call a meeting and do not assign fault until the root cause type is identified. One person, one laptop, in this order.
Start by aligning timestamps. Pull both numbers to the same point in time before comparing, to rule out sync-window noise. This step alone filters out at least a third of false alarms. Plenty of people skip it, burn two hours investigating, and then discover they were comparing different moments.
If the gap survives timestamp alignment, check in-transit. In the WMS, total up allocated-not-yet-picked, in-picking, and staged-for-shipment, and reconcile that against the gap. If it matches, you have a definitions problem: either the OMS available formula needs to deduct in-transit, or operations needs to understand that on-hand is not the same as sellable.
If in-transit does not explain it, check returns. Pull the last week of return receipts in the WMS and match them line by line against return postings in the OMS. Pay special attention to the failed-retry queue. Plenty of integrations are fire-and-forget — a dropped message sits in a queue nobody monitors.
If returns are clean, check cycle counts. Export recent WMS count adjustments and verify each one has a matching sync record into the OMS. Count adjustments are low-frequency but high-impact; one missed push can leave a discrepancy hanging for months.
Finally, check the mapping. Put the OMS warehouse list and the WMS physical building list side by side and walk the mapping entries one by one. New buildings, temporary peak-season forward stocking locations, and third-party drop-ship sites are where mappings go missing. If the mapping is wrong, the first four steps were wasted effort — the foundation itself is crooked.
Those five steps locate the failing link in roughly nine cases out of ten. Only then talk about ownership: sync lag is an architecture decision, so IT owns it. Failed return postings are an integration problem, IT again. Counts never pushed is a process problem, operations. Broken mapping usually means the two sides never aligned when the building opened, so split that one down the middle. My recommendation is to write the division of labor down and keep it: operations owns daily reconciliation, IT owns interfaces and jobs. When something breaks, work the steps in order, and nobody gets to cry foul first.
Stop Waiting for the Next 2 A.M. Call
Troubleshooting is firefighting. Fire prevention is three mechanisms, none of them expensive.
First, run a daily reconciliation job. Compare OMS available against WMS available by SKU, and alert automatically past a threshold. Do not set the threshold too tight — I usually suggest something like more than 5 units or 2% of a SKU's sellable quantity, otherwise alert fatigue kills the whole thing within a week. Send alerts to the working group chat, not just email. Nobody reads those emails.
Second, push count adjustments to the OMS in real time. Plenty of companies still batch them at month-end, which means the two systems are simply wrong relative to each other for a few days every month. Change it to push-on-adjust. Technically it is one more API call.
Third, make in-transit visible in the OMS. Let customer service and operations see in-transit and staged quantities next to on-hand, not one lonely on-hand number. When the oversell call comes in, the rep can tell whether it is truly out of stock or just on a cart somewhere — and nobody has to wake anyone up at half past two.
Do those three and the discrepancies will not hit zero, but the 2:30 a.m. calls should drop by half.
One last question for you: what is your OMS-WMS inventory accuracy right now? Before you answer, think about where you would look that number up, how often anyone checks it, and what size of gap triggers action. If you cannot answer all three, that phone call at half past two is going to ring again. It is only a matter of when.
