I'll give you the verdict first: when order numbers don't line up across your systems, the integration is almost never broken. What's broken is the mapping table nobody owns.
Fall 2023: a 60,000-plus-square-foot apparel 3PL outside Ontario, California. The head of customer service called me in — her team was drowning in "where is my order" tickets. The storefront showed every order as shipped, but click the tracking number and you'd get "no such shipment" — or worse, someone else's package. IT spent a week in the logs and every interface was green — OMS, WMS, carrier APIs: zero errors.
Three months earlier, a WMS upgrade changed how child order numbers were generated after a split. Nobody told the OMS side, which kept assembling IDs the old way. When tracking numbers came back from the carrier, the write-back logic matched them to orders by guessing on the ID string — guess wrong, and a tracking number lands on the wrong order. The pipes were fine; the assumption — that an ID in one system means the same thing in another — was what broke.
I've seen this movie at least ten times in twenty years, and the discovery moment in Ontario shows why green logs lie. The IT lead pulled one problem order and we walked it together, screen by screen: OMS said order 88412, shipped, tracking number attached. WMS said order 88412 split into two child picks — but the children were numbered under the new scheme, 88412-A and 88412-B, while the OMS write-back still matched the old pattern, 88412-01 and 88412-02. The tracking numbers had come home just fine — hung on order numbers that no longer existed anywhere. Every API had done its job; the contract about what an ID looks like had been rewritten on one side and never re-signed on the other.
The chain breaks in three predictable places
An order's journey has four stops — parent order in the OMS, picks and parcels in the WMS, labels and tracking at the TMS and carrier, status write-back to the OMS — and three predictable seams.
Split shipments first. In the OMS, an order is one number. Inside the WMS it gets split across two waves and three parcels based on where inventory sits — and those child numbers live only in the WMS. The OMS has no idea the children exist. Tracking numbers come home addressed to the parent, and anyone searching by child number finds nothing. The nastier variant is the partial ship: three parcels, two carriers, the third short on stock. The OMS marks the whole parent "complete" — the customer gets two boxes, and the third tracking number becomes an orphan.
Second seam: the tracking write-back. The carrier issues the tracking number, the TMS captures it — and then the write-back points it at the wrong order. The classic: a label misprints, someone reprints it, the old tracking number never gets voided — now two live numbers point at one parcel. The customer and the CSR each track a different one. Everyone's right and everyone's wrong.
Third seam: batches and pallets, and this one belongs to the B2B crowd. Retailers require an 856 advance ship notice, and the SSCC-18 serial number on the physical pallet has to match the pack-level number in the ASN character for character — one digit off and the whole pallet gets rejected. I once watched a warehouse generate pallet IDs automatically in the WMS while the 945 shipping advice was typed in by hand. Those two numbers were never the same thing. It blew up three months later at reconciliation, and the chargebacks would have bought a decent forklift.
Integrations move data; mapping tables make data agree — and the second job is where the bodies are buried.
There's also a trap in the returns flow: a parcel gets received in the warehouse against an RMA number, but the refund in the OMS hangs off the original order number. With no RMA-to-order mapping, finance ends up with orphan refunds. The worst case I saw: hundreds of unmatched refunds in a single month, ops spending a full week matching them by hand.
Make the mapping table boring
My tracing method is one motion: walk the chain, no skipping. First figure out whether the ID is a parent or a child, and which system gave birth to it. Walk downstream one hop at a time; the hop where the ID stops connecting is your break. Nine times out of ten, you find it by the second hop.
Before you fix the data, ask three questions. Was this mapping written by a system or typed by a human? Did any rule change recently? How many more are broken the same way? Fixing one record is firefighting. Fixing the batch is troubleshooting. In that Ontario case we wrote a script that re-hung every mis-mapped tracking number from the prior three months — over four thousand orders in one pass. Clicking through one by one would have taken customer service into next year.
Then the hardening. Five rules, each paid for in tuition.
One canonical table. Order to child, child to parcel, parcel to label, label to tracking number, onward to batch and pallet — all of it in one mapping table, inside a system, with a named owner and a change log. Every mapping table I've seen rot had the same org chart problem: the OMS team thought the WMS team owned it, the WMS team thought the 3PL's EDI analyst owned it, and the analyst thought it was "just a reference." Put one name on it — someone who reviews the change log monthly and sits in on every upgrade, carrier onboarding, and retailer spec change. The Ontario incident happened because a WMS upgrade shipped with a release note nobody on the OMS side read — an owner would have caught it in a five-minute diff review.
Namespace your IDs. Prefix every ID with its source system so a WMS-born number can never collide with an OMS-born one. It sounds crude; it has saved me three times. Two systems both love plain auto-increment integers, and without prefixes they will collide — I once saw two 3PL clients' orders flow into one WMS, both starting at 10001, and the system hung client A's parcels on client B's orders. A full pallet shipped to the wrong customer.
Echo the parcel ID back. When a tracking number comes home, it must carry the parcel ID it went out with. A bare tracking string can't be traced backwards — reprint a label twice and good luck guessing which OMS order the tracking number belongs to. The 856 already has the structure for this — REF segments carrying the tracking number as the bill-of-lading reference alongside the carrier's own. Use it.
Reconcile daily. Run a scheduled job: shipped in the WMS, pending update in the OMS, has carrier tracking events. Diff the three sets — the fallout is what customer service will get yelled about tomorrow. Three buckets: shipped in the WMS but never updated in the OMS — lost write-back; updated in the OMS but no carrier events — label printed, freight never moved; carrier events with no record on either side — usually test labels or stale numbers from reprints. Classify first, then act.
Version your split logic: exercise every split-rule change against the mapping in a test environment first. A two-minute check, delayed three months.
One trade-off to settle up front: real-time carrier callbacks versus batch reconciliation for the tracking write-back. Real-time is fast, but costs more and callbacks get dropped. Batch is half a day late and rock solid. Small operations should run batch without shame and switch on real-time two weeks before peak season. What you save won't cover the overtime for the 2 a.m. firefight.
And one more "mismatch" that isn't an ID problem at all: time. The WMS stamps shipments in Pacific time, the OMS parses in UTC, and the same order lands a day apart on each side. CSRs search "today's shipments," find nothing, and assume the ID is lost. Warehouses spanning time zones step in this one constantly: check the clocks before you check the IDs.
So here's my question for you: go ask your IT team when someone last opened the ID mapping table. If the answer is "the last time something broke," the next break is already on its way.
