Before we write a single line about forecasting methodology, there is a prerequisite conversation that most demand planning discussions skip: the data going into the model. We hear a lot about model selection, about whether exponential smoothing is better than ARIMA for your particular demand pattern, about the right training window length. We hear much less about whether the demand history extracted from the ERP is actually a reliable record of what customers ordered.
The uncomfortable reality is that many ERP demand histories have meaningful data quality problems that invalidate the forecasts built on top of them. Not because the ERP is a bad system, but because ERP data entry and maintenance habits accumulate errors that nobody has a strong incentive to clean up until there is a specific reason to look. Demand forecasting gives you that reason.
The Three Problems We See Most Often
When we work through demand history with a new customer during pilot setup, the same categories of problems show up repeatedly. The specific numbers vary, but the patterns are consistent.
Missing Orders
Missing orders are the hardest data quality problem to detect because you are looking for absence rather than presence. If an order was taken by phone and never entered in the ERP, or was entered under the wrong SKU code and then corrected by creating a new order rather than editing the original, the demand history has a gap. The model sees lower demand than actually occurred. The safety stock calculation that follows will underestimate the buffer needed for that SKU.
Missing orders are most common in two scenarios: manual order entry workflows where the person entering the order is not the same person responsible for inventory accuracy, and ERP migration events where historical order data was carried forward incompletely. If your team migrated to the current ERP within the last three years, it is worth auditing whether the migrated demand history has consistent SKU-level coverage going back as far as you are using it in the model.
Duplicate Entries
Duplicates drive forecast inflation. An order entered twice because a confirmation email triggered a second entry, or a bulk import that ran twice against the same file, creates phantom demand that pushes the forecast upward. The demand planner setting reorder parameters against an inflated history will carry more inventory than the actual demand pattern justifies.
Duplicates are easier to detect than missing orders because they show up as anomalous spikes in the demand history for specific date ranges. A week where demand for a specific SKU is 4x the rolling average, followed by a return to average the following week, is a classic duplicate signature. The spike looks like a demand event, but it is actually a data entry artifact.
Returns Not Coded as Returns
This is the subtlest problem and the one most likely to persist undetected for years. When a customer returns product and the return is processed in the ERP as a credit memo without a corresponding negative demand adjustment, the original sale remains in the demand history. The forecast model sees demand that was actually reversed. For SKUs with significant return rates, this can meaningfully overstate the baseline demand the model is trained on.
The ERP typically has a mechanism to code returns correctly, but using it requires a process discipline that not every company maintains consistently. Returns handled by the customer service team may not follow the same coding workflow as returns handled by the warehouse. Over time, the inconsistency compounds.
How Bad Data Propagates Through the Forecast
Consider a mid-size industrial distributor running an 18-month demand history for a fastener SKU. The history contains three months where demand was entered twice due to a migration cutover issue at the beginning of the period. The duplicate entries inflate that three-month window by roughly 40%. The demand model, trained on the full 18-month history, calibrates its baseline using the inflated period as part of the normal variation it models around. The reorder point for the SKU ends up 8-12% higher than the actual demand pattern justifies. Over a catalog of several thousand SKUs, that kind of systematic inflation accumulates into a meaningful excess inventory position.
The opposite problem, where a stockout during a disruption period was never captured because backorders were handled manually outside the system, depresses the apparent demand for that SKU during the disruption window. The model learns that demand dropped during that period and adjusts its baseline downward. The actual demand was constrained by supply, not by reduced customer need. The model is learning the wrong signal.
Data Audit Before Model Selection
When we set up demand forecasting with a new customer, we run a data quality audit before selecting any model parameters. The audit looks for four things: anomalous demand spikes that fall outside three standard deviations of the trailing average for a given SKU; demand gaps where recorded orders drop to zero for periods longer than the typical order interval; SKUs with return-to-sale ratios that are inconsistent with the product category norms; and SKU-level demand patterns that break sharply at an ERP migration date.
We are not saying you need a full data warehouse audit before you can build a forecast. The goal is not perfection; it is identifying the data quality problems large enough to meaningfully distort the model output. A handful of SKUs with duplicate-inflated histories in a 5,000 SKU catalog will not materially affect the aggregate forecast. Those same duplicates affecting your top 20 revenue SKUs will.
Stockout Periods Require Special Handling
One category of demand history distortion deserves its own treatment: periods where you ran out of stock. Demand during a stockout period is constrained demand, not actual demand. The ERP records what shipped, which was limited by what was available. The actual market demand during that period was higher, by an unknown amount.
Models that train on constrained demand without adjustment will systematically underestimate the demand for SKUs that have experienced stockouts. The error compounds when those same SKUs have safety stock parameters derived from the understated demand baseline. You carry less safety stock for the SKUs most likely to stock out.
Correcting for stockout periods requires a judgment call: estimating what demand would have been if supply had been unconstrained. Common approaches include carrying forward the pre-stockout trend, interpolating from comparable periods in adjacent weeks, or using demand signals from downstream customers if you have order data that reflects backorder requests rather than filled orders. None of these is a perfect reconstruction, but any correction is better than treating constrained shipment data as unconstrained demand.
The ERP Is Not the Problem; the Process Around It Is
This is worth being direct about: most ERP data quality problems are process problems, not system problems. The ERP will accurately record whatever it is told to record. If the process for entering orders, coding returns, and correcting errors is consistent and well-maintained, the demand history will be clean enough to build a reliable forecast on. If the process has gaps, the history accumulates those gaps.
Fixing data quality for forecasting purposes is partly a one-time remediation of historical problems and partly a process change to prevent new ones from accumulating. The one-time work is a project. The process change is a longer-term discipline. The organizations that maintain the cleanest demand histories are typically the ones that treat data entry accuracy as a measurable process outcome, not just a byproduct of daily operations.
What This Means for Your Forecast Build
If you are building or rebuilding your demand forecast and you have not recently audited your demand history, that audit belongs in the project plan before model selection. The sequence matters: data quality first, then model parameters, then forecast validation. Running the sequence in the wrong order means you may spend significant time tuning model parameters to reduce forecast error that is actually driven by data noise, not model choice.
For Supplyverde, every pilot starts with a review of the uploaded demand history. We surface the anomalies and flag them for the planning team to review before we build the first forecast run. Some teams find problems they were unaware of. Others have already done this work and upload clean data. Either way, the audit step costs less than the alternative: building a forecast model on data that will mislead it from the first run.
Forecast error has many parents. Model choice is one. Training window length is another. But the one that is easiest to improve and often most impactful is the quality of the input data. Garbage in, as the saying goes. The forecast will faithfully model whatever pattern exists in the history you give it, including the artifacts you did not intend to include.