The Reconciliation Problem That Eats Optimization Budgets

Ask most supply chain optimization projects what they actually spent their first six months building, and the honest answer is rarely a solver. It's a reconciliation layer — code whose entire job is getting the ERP, the WMS, and the TMS to agree on how much inventory is in a given location, what's actually in transit versus what's still showing as on-order, and which lead time is the real one when three systems each have their own. That work doesn't show up in the pitch deck. It's not what the optimization vendor demos. But it's routinely 60 to 70% of the calendar time and budget on a network-level project, and skipping it isn't an option, because a routing or inventory model built on three disagreeing positions doesn't fail loudly — it fails quietly, by producing confident, well-optimized answers to a slightly wrong question.

Where the disagreement actually comes from

It's rarely one dramatic data quality issue. It's a dozen small definitional mismatches compounding. The WMS marks a pallet received the moment it clears dock scanning; the ERP doesn't post it to inventory until the putaway transaction closes, which can lag by a shift. The TMS considers a shipment delivered on proof-of-delivery scan; the ERP won't relieve in-transit inventory until the invoice matches against the PO, sometimes days later. Lead time in the planning system is a static master-data field, updated quarterly if at all; the actual lead time, observed from the TMS's own transit history, has been drifting for two months because a carrier quietly changed a route. None of these systems is malfunctioning. Each is internally correct according to its own definition of the event it's recording. The disagreement lives entirely in the gaps between those definitions, and nobody owns the gaps because no single system's team believes it's their job to close them.

Why this eats the optimization budget specifically

A routing or inventory optimization model is unusually unforgiving of this kind of noise, because it doesn't just report the disagreement — it acts on it, confidently, at scale. Feed a network optimization model an inventory position that's a day stale in one region and current in another, and it will route around a shortage that doesn't exist, or miss one that does, and present the answer with the same certainty either way. The project team then spends weeks debugging a routing model that isn't actually broken, because the instinct is to assume the optimization logic is wrong before anyone suspects the inputs disagree. We've watched this cycle burn a full quarter on a project before the team traced the bad recommendations back to a lead-time field nobody had reconciled since a supplier's shipping lane changed.

What actually gets budgeted for, and what should

Most RFPs and project plans for supply chain optimization allocate the bulk of the budget to the modeling and solver work, with a comparatively small line item for "data integration," as though that's a preparatory task rather than the majority of the engineering effort. We've started pushing clients to flip that ratio explicitly before the project starts: treat reconciliation as its own workstream with its own success criteria — a documented, tested mapping of what "in stock," "in transit," and "lead time" mean across every system in play, and a shared position that all three systems' numbers roll up to without manual adjustment. That work is genuinely less interesting than building an optimization model, and it's also the difference between a model that's right and a model that's confidently wrong. Budget for it as the foundation it actually is, not the afterthought it's usually treated as, and the optimization work that follows takes a fraction of the time everyone expected it to.