Why Supply Chain AI Fails: The Stock Truth Test

Why do supply chain AI projects fail? Far more often than not, they fail on data rather than on models. A demand forecast, a replenishment engine and a slotting optimiser all read the same inputs: what you hold, where it is, what a unit means, and when things happened. When any of those is wrong in a systematic way, the model learns the error faithfully and reproduces it with more confidence than the spreadsheet it replaced. The five checks below make up what we call the Stock Truth Test. Each one is answerable in an afternoon, none of them requires a vendor, and any that fails will cap the accuracy of every model you build on top of it.

This is written for operations and technology leaders who have either been burned by a planning project or are about to scope one.

Why the model is rarely the problem

This piece is about the five data checks specifically. For the fuller picture of where AI creates value in a supply chain and the sequence that gets a programme there, the practical guide to AI in supply chain management is the wider treatment this one sits under.

Forecasting and optimisation techniques are largely commoditised. The algorithms are in open-source libraries, the cloud vendors sell the compute, and the difference between a good model and a great one on clean data is usually smaller than the difference between clean and dirty data on the same model.

The reason data faults are so damaging is that they are rarely random. Random noise averages out and a model copes. Systematic faults do not. If receipts are keyed the morning after the truck arrives, every lead time in the system is inflated by a predictable amount, and the model learns that inflation as though it were physics. If one warehouse counts a case where another counts an each, demand for that item looks bimodal and the forecast splits the difference — a number that is wrong at both sites.

That is the pattern to look for: not "is our data messy" but "is our data wrong in a way that repeats."

The Stock Truth Test

Five checks. Run them against your own systems before anyone builds anything.

1. Does system on-hand match the shelf?

   Pull the last quarter of cycle-count adjustments and look at variance by item, not in aggregate. Aggregate accuracy hides the problem, because overs and unders cancel and produce a comfortable headline number.

   Then split by velocity. Fast-moving items with high variance are the ones that break replenishment, because those are the items the model is asked about most often. A high overall accuracy figure carried by thousands of slow-moving items that nobody touches tells you nothing about the SKUs that matter.

   **What it breaks:** safety stock, reorder points, and any promise made to a customer about availability.

2. Is a unit the same thing in every system?

   Take a dozen items and trace the unit of measure through the whole chain: supplier EDI, purchasing, the ERP, the warehouse system, the ecommerce catalogue. Look for the same item held as eaches in one system and cases in another, with a conversion factor maintained by hand in exactly one of them.

   Conversion errors are the single most common fault we see, and the most consequential, because they are silent. Nothing throws an exception. The number is simply wrong by a clean multiple, which is exactly the shape of error a forecast will absorb without complaint.

   **What it breaks:** demand aggregation, purchase order quantities, and every cost-per-unit figure downstream.

3. Does one product have exactly one identity?

   Search your item master for the same physical product under more than one code. Duplicates arrive through site-by-site rollouts, supplier changes, acquisitions, and the ordinary habit of creating a new code when nobody can find the existing one.

   Duplicates are worse than they look. Demand splits across the codes, so each one individually looks slower-moving than the product actually is, and the forecast under-orders both. The fix is a governed identity, which is what standardised product identification schemes such as the GS1 GTIN exist to provide.

   **What it breaks:** forecasting, supplier negotiation, and any attempt to measure true product performance.

4. Is "available" a number or an opinion?

   Ask three systems how many units of one item are available right now, and you will often get three answers. Each is applying different netting rules to allocated stock, reserved stock, goods in transit, quarantined or damaged units, and customer returns awaiting inspection.

   None of those answers is necessarily wrong. They answer different questions. The failure is that downstream consumers assume one shared definition, so a model trained on the warehouse view gets deployed against the commerce view and quietly mis-promises.

   **What it breaks:** availability promises, allocation logic, and trust in the system the first time a customer is told yes and then no.

5. Do your timestamps record events or keystrokes?

   Compare the timestamp on a sample of receipts and dispatches with when the event physically happened. Look for clustering: everything landing at the start of a shift, or in a nightly batch, or never on weekends.

   If timestamps record data entry rather than physical events, every duration derived from them is wrong — and wrong in a patterned way that a model will learn as real. Lead time models are the obvious casualty; demand sensing is the subtler one, because a model can end up predicting your data-entry schedule rather than your customers. Storing times in an unambiguous, offset-aware format such as RFC 3339 removes a related class of error, though it does not fix the underlying capture problem.

   **What it breaks:** lead times, service-level reporting, and anything described as real time.

What these faults actually cost

The cost is rarely a visible failure. It is a project that lands, produces recommendations nobody quite believes, and is quietly worked around within two quarters. Planners keep their own spreadsheets. The system becomes a reporting layer over decisions made elsewhere, and the investment is written off as "the model was not accurate enough."

That post-mortem is almost always wrong, and it is expensive precisely because it points at the wrong culprit. The next project starts by shopping for a better model.

Fix in this order

Not everything has to be fixed, and not at once. Sequence by how much each fault contaminates the others.

• **Identity first.** Duplicate items corrupt every measurement you would use to judge the other four. Nothing downstream is trustworthy until one product means one thing.
• **Units second.** Conversion errors distort quantities everywhere and are usually fixable in a bounded piece of work, because the number of conversion paths is small even when the item count is large.
• **Definitions third.** Write down what "available" means, per system, and make the differences explicit rather than accidental. This is documentation and governance more than engineering.
• **Timestamps fourth.** Often a process change at the point of capture rather than a software change.
• **Count accuracy last, and continuously.** It is the one that never finishes, which is why it belongs in operations rather than in a project plan.

Teams that invert this order — starting with a counting programme because it feels tangible — end up counting duplicated items in ambiguous units and measuring the wrong thing precisely. The wider version of this argument, beyond inventory specifically, is set out in our guide to building an AI-ready data strategy.

When not to fix the data

Sometimes the right call is to work around a fault rather than repair it.

If a fault is confined to a category that the use case does not touch, scope it out and say so explicitly in the project definition. If a conversion error is stable and well understood, a correction applied at ingestion can be honest and cheap, provided it is documented and owned rather than buried in a transformation script that outlives the person who wrote it.

What does not work is treating a systematic fault as noise and hoping the model absorbs it. It will absorb it. That is the problem.

The same discipline applies to choosing the technique in the first place: some questions are not forecasting questions at all, an argument we make in detail in when retrieval is the wrong answer.

Frequently asked questions

How long does the Stock Truth Test take?

Each check is an afternoon of querying against systems you already have, so a small team can complete all five inside a week. That is deliberate. If assessing your readiness requires a lengthy paid discovery, the assessment has become the project.

Do we need to fix everything before starting an AI project?

No, and waiting for perfect data is its own failure mode. You need to know which faults exist, which ones touch your use case, and which you are choosing to live with. A named, owned decision to defer a fix is fine. Discovering the fault after go-live is not.

Our ERP vendor says their AI module handles this. Does it?

A module inside your ERP reads the same tables as everything else, so it inherits the same faults. Vendor tooling can help with detection, particularly for duplicates. It cannot decide what "available" should mean at your company, because that is a business rule rather than a data problem.

Which of the five is most commonly wrong?

Unit of measure, in our experience, and it is also the one teams are most surprised by — because unlike a bad count, nothing about it looks broken. The number is clean, plausible, and wrong by a factor.

Is this only relevant to warehousing?

No. The same five faults appear anywhere physical goods are tracked, including manufacturing and field service. The vocabulary changes; the failure mechanisms do not. Our broader work in this area is described on our supply chain industry page.

Where to start

If you are scoping a forecasting, replenishment or planning build, run the five checks first and let the results shape the scope. It is the cheapest week in the whole programme, and it occasionally changes the answer from "build a model" to "fix an identity problem and revisit in a quarter."

If you would rather have a second pair of eyes on the results, our AI and ML development team runs this assessment as a fixed-scope engagement and will tell you plainly when the honest recommendation is to fix the data and not to build anything yet. Start a conversation and bring your item master.