Common Issues and Solutions

Most commonly caused by composite key collisions — if two records share the same unique identifier, one overwrites the other.

Can also occur if filter criteria in the data mapping exclude records you expect to see.

Orders fulfilled or removed between report runs will disappear from the next refresh but may still appear in exceptions generated from the previous day's data.

Newly created orders won't appear until the next data refresh.

The system will filter to the product master automatically. Only products present in your product master file will be included in the forecast. However, if a large percentage of your input file is out of scope (e.g., 50%+ of rows), this indicates the source export needs tightening.

Check your product coverage rate regularly. After each data load, verify what percentage of products in your sales and forecast input files match the product master. If coverage drops below 80%, investigate whether the source export scope has changed or the product master needs updating.

Out-of-scope products in plan inputs can cause inflated totals. If your EDI or SIOP files include products from other plants, the aggregate forecast signal will be higher than it should be. Ensure plan input files are filtered to the same product scope as your product master before loading.

Check the timestamp on the exception — if it's more than a day old, the recommendation may be stale.

If the recommendation is clearly wrong (e.g., ignores a large order visible in the chart), provide feedback using thumbs down and report the specific exception to your support team.

The impact date shows when the inventory issue begins (e.g., when stockout starts or excess exceeds threshold).

The "Act By" date should account for lead time so you have time to act before the issue materializes. If Act By equals the impact date, lead time may not be incorporated — report this to your support team.

Too many low-volume/inactive products in scope. Products with sparse, intermittent demand are hard for any model to beat a simple average on. Use a preprocessing rule to scope the forecast to products with meaningful demand history (e.g., at least 6 months of non-zero demand).

Training on stale or contaminated history. If your order history goes back many years, old demand patterns may not reflect current reality. Consider a preprocessing rule to limit training history to the most recent 3–5 years, or to replace anomalous periods (e.g., COVID) with normalized values.

Demand spikes from one-time orders. A single large bulk order can create a false upward trend in the training data. Use a preprocessing rule to cap anomalous monthly demand values at a multiple of the trailing average (e.g., 5x).

Consensus rules applied in wrong direction. The LLM agent can misinterpret rule language. "Decrease by 27%" may be applied as an increase. Always validate consensus output against baseline by comparing specific products and months. Use explicit multiplication language ("multiply by 0.725") rather than directional language ("decrease by 27.5%").

The model is trained on a growth period. If recent years showed growth that isn't continuing, the model extrapolates a trend that no longer exists.

Consensus rules are stacking upward adjustments. Multiple rules that each increase the forecast (stockout bias, trend boost, seasonal uplift) can compound. Review which rules are active and check if they're all applying to the same products.

Deleted/discontinued products still in scope. Products with trailing-off demand that are still being forecast will show systematic over-forecasting.

External forecast signals not being incorporated. If you have plan inputs (e.g., EDI customer forecasts, SIOP production plans) loaded but your consensus rules aren't applying them, the forecast defaults to the statistical baseline — which may not capture demand signals your planners see. Verify that consensus rules are actually modifying the output by comparing the ConsensusForecast export against the Forecast (baseline) export. If they're identical, the rules aren't firing.

Sparse product×site combinations pulling the aggregate down. If you forecast at product×site granularity but many combinations have zero or near-zero demand, the model produces small non-zero forecasts for inactive combinations. These don't add up to much individually but collectively drag the total forecast below actuals. Use a preprocessing rule to exclude combinations with insufficient demand history, or use conditional zero-filling in your plan inputs to explicitly signal "no demand expected" for inactive combinations.

The model hasn't captured a recent growth trend. Statistical models weight historical data. If your business has grown significantly in recent months but the model has years of lower-volume history, it will lag the trend. This typically improves over time as the model accumulates more recent data. In the interim, consider a consensus rule that uses a trailing average of recent actuals as a floor for outer forecast weeks.

Year-over-year seasonality mismatch. If this year's demand pattern differs from prior years (e.g., earlier seasonal ramp, new product launches), the model may under-forecast during the divergent period. Check whether the under-bias is concentrated in specific weeks or months that differ from the prior year pattern.

External signals only help near-term. If you have consensus rules that incorporate customer forecasts (EDI) for the first few weeks, accuracy will be noticeably better near-term and drop off when the rules stop applying. This is expected — consider extending the rules to cover more weeks with a blended approach (e.g., 50/50 blend of external signal and baseline for medium-term weeks).

The baseline reverts to a long-term average at longer horizons. Statistical models become less confident at longer horizons and tend toward the historical mean. If recent demand is above the historical mean, the outer weeks will appear under-biased. This is a model behavior, not a configuration issue.

Demand volatility makes longer horizons inherently harder. If your demand has high week-to-week variability (coefficient of variation > 0.5), even a perfect model will show high error at longer horizons. Focus accuracy evaluation on the first 3–4 weeks, which is the actionable planning window for most operations.

The external signal may not cover enough products. EDI or customer forecasts typically only cover a subset of your product catalog (often 30–50%). Products without external signal still use the baseline. Check your coverage rate — if it's below 50%, the impact on aggregate accuracy will be limited.

The external signal may not be accurate enough to help. Measure the external forecast's accuracy independently before using it in rules. If its WAPE is worse than the baseline, incorporating it will hurt rather than help. Consider limiting the rule to specific sites or products where the external signal is demonstrably better (e.g., volume-weighted WAPE below 50%).

The external signal doesn't report zeros. Many EDI systems only send records for products with active orders — they omit products with zero demand rather than explicitly reporting zero. If your consensus rule says "when EDI = 0, set forecast to 0," it will never fire because there are no zero records. You need to generate synthetic zero records in preprocessing for product×site combinations that have no external signal AND no recent sales history.

The external signal accuracy varies by horizon. Customer forecasts are typically most accurate for the immediate next week (essentially confirmed orders) and degrade rapidly. A rule that uses the external signal directly for all weeks may hurt accuracy at longer horizons. Consider a tiered approach: direct replacement for weeks 1–3, blended for weeks 4–6, baseline only for weeks 7+.

The rule may have been overridden by a higher-priority rule. Rules are applied in priority order. A later rule can undo an earlier one. Check the rule ordering.

The rule condition may not match any products. If the rule references a product attribute (e.g., product_group_id) that isn't in the item metadata, it will silently match nothing.

The rule language was misinterpreted. The LLM agent generates code from natural language. Ambiguous phrasing can produce unexpected results. Be as specific and literal as possible. Use exact field names, explicit multipliers, and clear conditions.

Dimension mismatch in the join. The consensus engine joins plan inputs to the baseline on dimension columns (product ID, site ID, date). If the column names differ between the baseline and the plan inputs (e.g., baseline uses item_id while EDI uses product_id), the join produces no matches and all rules fall through to the baseline default. Verify that the dimension mapping in your data flow configuration correctly maps between the two schemas.

Date format mismatch. The baseline may store dates as 2026-03-02 while plan inputs store them as 2026-03-02T00:00:00.000Z. If the join requires exact match, timezone-aware and timezone-naive dates won't match. Check that date columns are converted to the same format before joining.

Plan inputs not loaded. Verify that your plan input files (EDI, SIOP, etc.) were successfully ingested. Check the record counts in the system — if they show zero rows for a plan input, the file may have failed to load.

The consensus forecast_id matches the baseline forecast_id. If both exports share the same forecast_id, the consensus engine produced a direct copy of the baseline without processing. This indicates a system-level issue — contact your support team with the forecast_id and demand_plan_run_id.

The site/product filter condition may reference the wrong column. If your rule says "apply to sites in [list]" but the generated code checks a column that doesn't exist or has different values, the filter may silently pass all rows. Verify by spot-checking a few specific products that should NOT be affected by the rule.

Rule priority order may be inverted. Rules are applied as a chain where later rules override earlier ones. If a broad rule (e.g., "use baseline for everything") is applied after a specific rule (e.g., "use EDI for these 50 sites"), the broad rule will undo the specific one. Ensure your rule descriptions clearly state the priority order.

Add a rounding rule as the final consensus step. A simple "round to nearest integer" rule applied after all other consensus rules will clean up fractional values. Values below 0.5 will round to zero, which is appropriate for very low-demand combinations.

Consider rounding to operational quantities. If your products ship in standard pack sizes (e.g., cases of 12, pallets of 48), rounding to the nearest valid pack size may improve both the usability and accuracy of the forecast. This requires pack size data in your product master. Share your MOQ or pack size data with your support team to explore this option.

Check the granularity. A product may have 52 weeks of demand at the product level but only 3 weeks at any individual product×site combination. A minimum history threshold applied at product×site level will exclude most combinations. Consider applying the threshold at product level instead, or lowering the threshold significantly.

Test before deploying. Before activating a preprocessing rule, count how many product×site combinations pass the filter vs. your current total. If more than 20% are excluded, the rule is likely too aggressive. Start with a lenient threshold and tighten gradually.