It's 3:18 p.m. at a regional DC in central Pennsylvania. The WMS shows 1,840 units of SKU 44102 on hand. The ERP shows 2,210. The replenishment buyer needs to commit a promo allocation to a customer DC in the next twenty minutes. Both numbers came from systems the company spent eight figures implementing. Neither one is wrong, exactly. They're just measuring different things, on different cadences, against different rules.
This is what a supply chain visibility gap actually looks like. Not a missing data source. A reconciliation problem buried in plain sight.
Every enterprise supply chain organization deals with this. The warehouse management system knows what's inside its walls in real time. The transportation management system knows what's on the truck on its own cadence. The ERP holds the master record, updated overnight. Each system is doing its job. The gap is between them — and that gap is where logistics system visibility breaks down.
Why visibility gaps happen across WMS and logistics systems
Three structural reasons, in roughly this order:
Different cadences. A WMS goods-receipt scan posts within minutes — sometimes seconds. A TMS milestone event comes from the carrier, which may post via EDI in 15 minutes or via portal scrape overnight. The ERP reconciles in nightly batches because that's how the financial close works. Each system is internally consistent at its own cadence; combined, they're showing three different versions of "now."
Different units of measure. A SKU in the article master is pieces. The WMS is tracking cases. The TMS is tracking pallets. The receiving scan is tracking layers. Conversion factors exist somewhere — usually in the ERP — but they're incomplete on the long tail. A planner asking "how much do I have?" gets four different answers, and they're all correct under different assumptions.
Different keys. The article master in the ERP is "SKU-44102." The WMS strips the prefix and stores "44102." The carrier portal has whatever the BOL clerk typed. Joins between systems silently drop rows where the key formatting differs. Nobody flags it because the dashboards above the joins keep rendering — they just render with a 14% data loss the operator doesn't see.
We've gone deeper on the data-key version of this problem in why WMS, TMS, and ERP data silos break visibility. The short version: the systems disagree because nothing in the stack is reconciling them.
The temptation to build another silo
The intuitive fix — and the one most consulting decks recommend — is to build a "data lake" or BI middleware layer that pulls from all three systems and produces a unified view.
This works in theory. In practice, it creates a fourth silo. Here's why:
The data lake is downstream of the source systems. It inherits their schemas, their cadences, and their key inconsistencies. The data engineering team builds extract pipelines, normalizes the obvious mismatches, ships the first dashboards. Six months later, the source systems change — a new TMS, a renamed ERP module, a SKU master cleanup — and the pipelines silently break. The dashboards keep rendering. The data behind them is wrong.
You haven't solved the visibility problem. You've added a new system that needs to be kept in sync with the three you already had.
The fix isn't another layer beside the others. It's a layer that sits above them with the explicit job of reconciliation.
What an integration layer should actually do
A real integration layer differs from middleware in three ways:
It reconciles, it doesn't just move data. Middleware passes records from one system to another in their original format. An integration layer reads from all of them, normalizes the schemas at load time, resolves the joins between mismatched keys, applies conversion factors against the article master, and produces one operational record per SKU, per location, per shipment. The downstream dashboards, AI agents, and exception workflows all read from that record — not from the underlying systems.
It surfaces the coverage footprint. When a source system has incomplete data — missing conversion factors, missing primary keys, partial telematics — the gap is visible on every KPI the data contributed to. Buyers and planners trust numbers when they can see what's behind them. No silent drops.
It acts on what it sees. An integration layer doesn't stop at "here's the unified data." It runs the workflows that act on the data — exception detection, owner assignment, AI agents that resolve routine cases, an audit trail for everything else. The decision happens in the integration layer; the execution happens in the underlying systems.
This is the architectural pattern behind the orchestration approach. Same logic we cover in detail in why connecting ERP, TMS, and WMS beats replacing them.
A five-step approach to real-time inventory tracking
Here's the pattern that works for enterprise teams:
Step 1 — Connect WMS, TMS, and ERP through pre-built integrations. No custom EDI maps, no bespoke pipelines. Standard connectors that read the operational data as the source systems produce it — minutes-level on the WMS, milestone-level on the TMS, daily on the ERP. Pre-built connectors should cover the major warehouse management systems out of the box.
Step 2 — Reconcile at the substrate. SKU keys normalize once, in the integration layer. Date formats unify. Conversion factors resolve from the article master and apply across cases, layers, and pallets. Country codes uppercase. Warehouse IDs unpadded. The substrate is built once; the dashboards downstream stop arguing.
Step 3 — Expose one operational record per SKU, per location. On-hand, in-transit, allocated, at-risk, and forward-cover — all on the same record. Buyers and planners read one screen, not three. The record updates as the source events fire. This is the inventory truth substrate that AI allocation models, RFID rollouts, and ship-from-store programs all depend on.
Step 4 — Surface anomalies and exceptions in real time. OOS predicted hours before it lands. ETA slips flagged at the milestone. Goods-receipt gaps caught when the WMS reports a short receipt against the expected ASN. The integration layer fires these to named owners with SLAs, not to a shared inbox nobody reads.
Step 5 — Show coverage on every KPI. Every metric — OTIF, on-hand, stock range, days-of-cover — carries the percentage of source rows that contributed to it. Your team trusts the numbers and the gaps get a roadmap. This is the same principle behind why most supply chain dashboards lie — and how to make them tell the truth.
How to avoid creating new silos
The risk of any systems integration project is that the new layer becomes its own silo. Three rules keep that from happening:
The integration layer reads, it doesn't store the master. The ERP keeps the master inventory record. The WMS keeps the master pick and put-away record. The integration layer reads, reconciles, and surfaces — but doesn't become a new source of truth that needs to be reconciled to the original ones.
Connectors swap independently. If you upgrade your TMS in three years, the integration with the new TMS swaps without rebuilding the reconciliation logic. The orchestration above the layer stays put. This is the structural argument behind the 18-month replatform that didn't have to happen.
Coverage is exposed, not hidden. If a source system has gaps, those gaps are visible on every KPI. You don't get to silently "fix" data quality issues at the integration layer — you surface them and create a roadmap to fix them at source.
This is the structural difference between an integration layer and a data lake. We've explored the broader argument in eliminating visibility gaps across WMS and logistics systems.
How Orkestra fits
Orkestra is the integration layer this article describes. The platform connects 200+ ERP, TMS, WMS, carrier, supplier portal, and POS systems through pre-built integrations, reconciles operational data into one record per SKU, per location, per shipment, and runs the exception workflows and AI agents on top — without storing a duplicate master inventory record.
A grocery store supplier used the same architecture to deliver first-ever carton-level traceability across its supply chain and a 15% cost saving. DBW Advanced Fiber moved from spreadsheets to a real-time end-to-end view across EU→NA lanes and cut supply chain cost by 18%. A global tire manufacturer surfaces $11.6K in weekly savings through data normalization and customizable alerts.
The pattern is consistent: connect the systems you already run, reconcile at the substrate, and let the dashboards downstream finally agree with operational reality. No replatform required.
See how the integration architecture works · Book a 30-minute walkthrough
Further reading
- Eliminate visibility gaps across WMS and logistics systems
- Why WMS, TMS, and ERP data silos break visibility in 2026
- Why connecting ERP, TMS, and WMS beats replacing them
And if you'd rather see the architecture in product form: unify ERP, TMS, and WMS without replacing any of them.
