The question planners most often ask before adopting a demand forecasting tool is not "what algorithm does it use" or "what reporting does it offer." It is "what do I need to do to get my ERP data into it." The integration question is almost always the deciding factor in whether a planning tool gets adopted or stalls in evaluation.
This guide covers the specific data fields that matter for accurate demand forecasting, the data quality issues that routinely appear in distributor ERP systems, and how to clean them up - without requiring a data engineering team to do it.
The Data Fields That Actually Matter
Demand forecasting models need a surprisingly limited set of fields from the ERP. The complexity is not in the breadth of data - it is in the quality and consistency of a few specific fields.
Transaction date (not invoice date). This is the most important field and the most commonly wrong. You need the date goods shipped or were picked from the warehouse, not the date the invoice was processed. In many ERP configurations, the date recorded in the demand history is the invoicing date, which can lag shipment by 3-10 days. For weekly forecasting, this lag corrupts the time-series data. Check your ERP's date fields carefully - "shipped date," "fulfillment date," or "pick date" is the right field. "Invoice date" or "billing date" is not.
Ship-from location. For multi-location operations, the demand history must be tied to the fulfillment location, not the billing location. If your ERP bills centrally but ships from regional DCs, and the ship-from location is not recorded at the order line level, you cannot build per-DC forecasts. Verify this in your ERP before starting any forecasting project. Retrofitting location attribution to historical data is possible but requires significant effort.
Item identifier (SKU) with unit of measure. The SKU field should be consistent - the same physical product should always carry the same SKU code. Cross-reference changes, product merges, and unit-of-measure changes over time create discontinuities in the demand history that distort model training. If your ERP has a SKU history or product crosswalk table, pull it alongside the transaction history.
Quantity shipped (not quantity ordered). Use shipped quantity, not ordered quantity. Ordered quantity includes backorders and items that were never fulfilled, which inflates apparent demand. Shipped quantity is the true consumption signal.
Customer type or channel code. Not required for basic forecasting, but useful for models that want to distinguish demand from different customer segments. A distributor selling to both retail accounts and industrial accounts may have fundamentally different demand patterns from each channel. If this distinction exists in your ERP and matters to how you plan inventory, include it in the data extract.
Common Data Quality Problems and How to Fix Them
Backdated transactions. Look at your transaction data and check whether invoice dates cluster at the end of weeks or months. If transactions are being backdated to align with billing cycles, your demand history will show demand spiking at period ends - an artifact of the billing process, not real demand timing. Fix at the source by using the correct date field, or add a preprocessing step that redistributes backdated transactions to their actual shipment date using a fixed offset (if your billing lag is consistently 5 days, offset all transactions by -5 days).
SKU proliferation from discontinued and successor items. When a product is discontinued and replaced by a successor SKU, the demand history splits between two item codes at the transition point. The successor appears to have zero history; the original appears to have demand that stopped. Build a crosswalk table linking successor SKUs to their predecessors, and chain the demand history through the transition. This is a one-time data task that produces significantly better cold-start forecasts for items with a product history under a different SKU.
Returns processing. Customer returns recorded as negative demand transactions distort the time series. Returns represent fulfilled demand that was reversed - they are not a demand signal. Strip returns from the demand history before model training, or record them in a separate table and exclude them from the training dataset. This is especially important for seasonal items where returns often cluster at the end of a season, creating false negative demand patterns at precisely the time when the seasonal model needs clean data.
Contract and promotional orders. Large one-time orders - a single customer buying 1,000 units of an item that normally sells 50 per week - are real demand events, but they are not indicative of future demand. A model trained to replicate them will forecast a similar spike in the equivalent future period. Add a flag field to the transaction data to mark promotional or contract orders, and either exclude these transactions from model training or weight them differently.
Unit of measure inconsistencies. In some ERPs, the same physical item has been ordered and sold in different units of measure at different points in history - cases versus each, pallets versus cases, different pack sizes. Normalizing the quantity field to a consistent unit of measure before training is essential. If your product team cannot supply a definitive UOM mapping, pull a sample of high-variance weeks for affected SKUs and verify the transaction quantities by hand before scaling the normalization.
The Minimum Viable Data Set
For a mid-market distributor getting started with demand forecasting, the minimum viable data set for reasonable forecast quality is 18-24 months of clean order-line history with: correct transaction dates, ship-from location, SKU codes, and shipped quantities. Returns removed. Promotional orders flagged. Unit of measure normalized.
Eighteen months captures at least one full seasonal cycle, which is the minimum for any seasonal adjustment approach. Twenty-four months provides a baseline comparison for the current year. Less than 18 months produces forecasts with poor seasonal adjustment and high initial error rates.
The data cleaning work required to get to this minimum typically takes a team of one with ERP access two to four weeks, depending on how well the ERP was maintained during the period in question. Companies whose ERP was migrated, upgraded, or restructured during the 24-month window will have additional data reconciliation work.
What to Do Without a Data Team
Most mid-market distributors do not have a data engineering team. The planner, possibly with the IT person who manages the ERP, is doing this work. The practical approach is to start with the highest-value subset: the top 20% of SKUs by annual demand, at the DC or DCs that account for most volume. Clean the data for this subset, build an initial model, and validate the forecast quality before expanding to the full catalog.
This approach concentrates the data quality effort where it produces the most value, and it creates a proof-of-concept forecast that can be evaluated against actual demand before committing to the full integration project. Once the high-value subset is working, extending to the broader catalog is incremental rather than requiring another full data cleanup pass.
