Jonas Wehr has been building demand forecasting models for supply chain applications for years, and he says the most common mistake planners make is not in the model they choose. It is in the data they feed it. A sophisticated ML model trained on dirty ERP data will produce sophisticated-looking wrong answers. The garbage-in problem in demand planning is real, it is widespread, and almost no one talks about it directly.
This piece covers the specific data quality problems that distort demand forecasting downstream, why they are more common than most distribution operations teams acknowledge, and the practical choices between fixing them at the source or compensating in the model.
The Most Common ERP Data Problems in Demand Planning
Backdated transactions. When a shipment is recorded in the ERP on the date the invoice was processed rather than the date goods left the warehouse, the time-series data misrepresents when demand actually occurred. In companies where invoicing runs 3-10 days behind shipment, a significant percentage of transactions appear in the wrong week. A model trained on this data will misidentify seasonality and produce lag artifacts in its forecasts.
Inconsistent SKU handling. Product rationalization happens in every distribution company. Items get discontinued, merged, relabeled, or replaced by a successor SKU. When this happens without a clean transition in the ERP, the new SKU appears to have zero history while the old SKU appears to have ongoing demand even after the transition. The model sees a new item with no demand signal and a discontinued item with demand that has mysteriously continued. Both result in poor forecasts.
Customer return misclassification. Returns processed as negative sales in the demand history corrupt the demand signal. A single large return in a low-volume week can make demand appear negative for a period, which a time-series model will interpret as a steep decline followed by a recovery. If returns are not stripped from the demand series before modeling, they introduce false patterns that no amount of model sophistication can compensate for.
Promotional and contract order noise. When a distributor runs a promotional campaign or fulfills a one-time contract order, the resulting demand spike is real but non-recurring. If the model treats it as a regular demand pattern, it will forecast a similar spike in the next period. This is a structural problem in seasonal adjustment: the model cannot distinguish between a sustainable demand level and a one-time event unless that distinction is encoded in the data or handled through event flagging.
Location assignment errors. In multi-DC operations, ship-from location is sometimes recorded at the billing location rather than the fulfillment location. This is a common ERP configuration issue that causes location-level demand data to look sparse at the fulfillment DC and inflated at the billing location. When you attempt to build per-DC forecasts, you are working with data that does not reflect where the actual demand is occurring.
Fixing at the Source vs. Compensating in the Model
There are two schools of thought on ERP data quality in forecasting. The first argues that you should fix the data at the source - correct the ERP configuration, enforce clean data entry practices, and build a pre-processing pipeline that normalizes the data before it reaches the model. The second argues that attempting to fix legacy ERP data is an organizational project that will take years, and that a well-designed model should be robust to common data quality issues.
Both positions are partially correct, and the practical answer depends on which type of problem you are dealing with.
Structural configuration problems (backdated transactions, location assignment, SKU transition handling) are best fixed at the source. These are not noise; they are systematic biases that affect every forecast built on that data. No model technique compensates well for systematic bias. Fixing the ERP configuration or adding a pre-processing normalization step that remaps transactions to the correct time and location is the right call, even though it requires IT involvement and is rarely fast.
Event-based noise (promotional spikes, contract orders, large returns) is best handled through model-level flags rather than ERP cleanup. The reason is that these events are correctly recorded in the ERP - the data is accurate, the problem is that the model should not learn from them as regular demand. Adding an event flag field to the demand history (1 = promotional, 0 = baseline) allows the model to exclude flagged periods from the demand signal while still retaining the data for reference. This is achievable without changing ERP configuration.
SKU consistency falls in the middle. If a company is actively rationalizing its catalog, maintaining a SKU crosswalk table that links successors to predecessors allows the model to chain demand histories across transitions. This is a data engineering task rather than an ERP fix, and it produces significantly better cold-start forecasts for new SKUs than treating them as items with zero history.
A Practical Audit of Your Demand History
Before investing in a more sophisticated forecasting approach, a targeted data quality audit is worth the few hours it takes. The audit does not need to be comprehensive. It needs to check for the specific problems that most commonly corrupt demand models.
Pull 24 months of order-line history. Check whether transaction dates cluster suspiciously at the end of weeks or months, which would indicate batch invoicing backdating. Look at your ten highest-volume SKU-location pairs and verify that demand history shows plausible continuity - no sudden drops to zero followed by restarts, no obvious sign of SKU splits that were not crosswalked. Check whether any negative demand values exist in the data and trace their source. Look at your top ten one-time customer orders in the period and verify they are flagged or isolated in the history.
This audit will typically surface two or three structural issues and five to ten event-noise instances. Addressing the structural issues before building or tuning a forecast model produces better results than any model improvement applied to dirty data.
The Model Cannot Fix What the Data Does Not Know
There is a persistent belief in demand planning that better algorithms compensate for data problems. This is true at the margins. A robust model is less sensitive to individual noisy data points than a naive one. But no algorithm compensates for systematic bias, because the model learns from the bias and replicates it in its forecasts.
If your ERP records transactions three days after the fact, your model will learn that demand peaks three days after it actually does. If your location data mixes fulfillment and billing locations, your model will produce forecasts for locations that do not reflect actual demand. The model is correct given what it has been told. What it has been told is wrong.
Data quality work is unglamorous. It does not feel like machine learning. But in practice, cleaning the demand history before model training reliably produces larger forecast accuracy improvements than algorithm upgrades. The planners we talk to who report the best results from forecasting tools are, almost without exception, the ones who spent time on their data before their model.
