Forecasting plus a reason why
AI Demand Forecasting for Manufacturers: Better Numbers and an Explanation Planners Can Trust
Short answer
AI-assisted demand forecasting layers a statistical or machine learning forecast on top of your ERP's own demand history, whether that is SAP IBP/APO, SyteLine MRP, Infor M3 MEC, or Oracle demand planning, then uses an LLM to explain the forecast in plain language: what drove the change, which SKUs are outliers, and what assumptions were used. The forecast still runs against your data on your infrastructure. Netray builds this as a use case within ERPray or a custom build, not as a replacement for your planning engine.
- ERP
- SAP S/4HANA, Infor M3, Infor SyteLine, Oracle Fusion Cloud ERP, Dynamics 365 Supply Chain Management
- Industries
- Manufacturing, Distribution, Electronics, Automotive
- Written for
- Supply Chain Director
If you own demand forecast accuracy for a manufacturer, you already know the statistical forecast in your ERP is only half the story. Planners spend hours in a spreadsheet adjusting the system forecast because they do not fully trust it or cannot quickly explain why it moved, and MRP keeps running against whatever number ends up in the system, override logic included, none of it written down anywhere.
Standalone AI forecasting tools sold as SaaS often produce a better statistical number, but the planner still cannot explain it to a plant manager or a CFO, and the tool usually lives outside the ERP, which means someone is re-keying its output or reconciling two versions of demand every planning cycle.
A grounded AI layer changes two things without replacing your planning engine. It sits beside SyteLine's, M3's, or SAP's own forecast and adds a narrative for every material change, plus the ability to ask a follow-up question in plain language, such as why a specific SKU's forecast jumped, and get an answer traced back to the actual sales and order history behind it.
In the target state, a planner gets the weekly forecast plus a short written explanation of the biggest movers, and can ask a follow-up question instead of hunting through history tables across plants to reconstruct the reasoning by hand.
What usually gets in the way
The problems we hear most from supply chain director teams running SAP S/4HANA.
Excel shadow forecasting
Planners override the ERP's statistical forecast in a spreadsheet because they do not trust or understand it, and the override logic is not documented anywhere the next planner can find.
No explanation for big swings
When a forecast jumps sharply for a SKU, nobody can quickly say whether it is a real demand signal, a data entry error, or a one-time order being read as a trend.
New product and short-history items
Statistical forecasting methods struggle with SKUs that have limited sales history, which is common with fast-moving electronics and custom-configured items.
Disconnected external signals
The ERP forecast does not see the customer's own forecast or EDI 830, a known program ramp, or a market indicator the sales team already knows about.
Planner time on data prep, not decisions
A large share of a planner's week goes into pulling and reconciling history from multiple ERP tables and plants before the forecast conversation can even start.
Where AI earns its place in SAP S/4HANA
Each use case names the ERP objects it reads or writes, so your ERP team can judge the integration effort before anyone commits budget.
Forecast exception triage
Planners review a short list of flagged SKUs instead of scanning every forecast line by hand.
Touches: SAP IBP/APO or S/4 PP/DS forecast tables, SyteLine forecast_detail, Infor M3 MEC022/MEC023
Outcome: Planners work from a written reason for each flagged change instead of scanning the full forecast report.
New-SKU forecast assist using analog items
The system proposes an analog item comparison for SKUs with under six months of sales history.
Touches: Item master, BOM similarity, sales history tables
Outcome: Reduces the manual analog-item lookup planners currently do by hand for short-history items.
Forecast narrative for S&OP
S&OP starts from a written summary of what moved and why, tied back to revenue.
Touches: Forecast tables plus GL/CO-PA data for revenue tie-out
Outcome: The S&OP meeting opens with a read summary instead of a raw forecast report nobody has reviewed yet.
Safety stock and MRP exception explanation
A planner gets a plain-language reason for an MRP-recommended expedite or reschedule.
Touches: SyteLine MRP action messages, SAP MD04, Infor LN whinh
Outcome: Planners get an explanation without re-deriving the pegging chain by hand.
Customer EDI 830 reconciliation against internal forecast
Flags where a customer's own forecast diverges materially from the internal ERP forecast.
Touches: EDI inbound tables, sales order history
Outcome: Surfaces a diverging customer signal before it becomes a stockout or an overbuild.
Seasonal and promotional pattern explanation
Distinguishes a genuine seasonal pattern from a one-time spike using the same history the forecast engine already has.
Touches: Sales history, item master attributes
Outcome: Gives planners the reasoning behind a seasonal call instead of a number with no context.
Multi-plant demand consolidation narrative
Consolidates demand changes for a shared component across plants into one written summary.
Touches: Cross-plant sales order and forecast tables
Outcome: One summary across plants instead of stitching together separate site-level reports.
Reference architecture
The numeric forecast can stay in the ERP's own planning engine; the AI layer reads that forecast plus underlying history, adds a narrative and Q&A layer, and, where useful, supplements the forecast for item classes the native engine handles poorly.
- 1
ERP connectors
Reads sales order history, forecast tables, and item master data from SAP IBP/APO, SyteLine, Infor M3 MEC, or Oracle demand planning without altering the planning engine's own calculations.
- 2
Data and semantic layer
Normalizes item, plant, and customer hierarchies across sources so a SKU means the same thing whether it is pulled from the ERP or an EDI feed.
- 3
Model serving
An open-weight LLM handles the narrative and Q&A layer, served on customer GPUs or a private cloud; a separate forecasting model can run alongside it for item classes that need extra support.
- 4
Retrieval and agents
Answers a planner's question about a specific SKU's forecast history and drivers, and can be extended to an agent that drafts, but does not submit, a forecast override for planner review.
- 5
Governance and audit
Every narrative and suggested override is logged against the source data and the planner who reviewed it, so a forecast change is always traceable.
Integration notes for your ERP team
- SAP: reads from IBP time series or the APO planning book, or S/4 PP/DS, via OData or CDS views, and does not write back to the live forecast unless explicitly enabled.
- SyteLine: forecast_detail and demand history read via IDO access; MRP action messages are read from the planning tables, not regenerated by the AI layer.
- Infor M3: MEC forecasting data read via M3 API or MI programs, respecting existing M3 security groups.
- Oracle: demand planning tables or Fusion Supply Chain Planning data read via REST APIs.
- EDI 830/862 inbound data is matched to internal item numbers using the same cross-reference tables the ERP already relies on.
- No forecast override writes back automatically; every suggested change is queued for planner approval inside the existing ERP workflow.
Deployment options
Air-gapped on-prem
Manufacturers whose demand data reveals customer program volumes they are contractually or competitively obligated to keep internal, common in defense and automotive supply chains.
Model serving, the semantic layer, and history run entirely inside the customer's data center, with no outbound calls to a forecasting API.
Private or sovereign cloud
Teams wanting to move faster on a pilot without a GPU purchase, while staying single-tenant.
The same architecture runs inside the customer's own cloud tenant, isolated from other customers.
Hybrid
Teams running the narrative and Q&A layer in cloud during the pilot, then moving on-prem once forecast data volume or customer contract terms require it.
A staged path from private-cloud pilot to on-prem production without re-architecting the semantic layer.
Compliance and data control
How the architecture supports your obligations. Certification and accountability stay with your organisation; the design keeps the evidence straightforward.
Customer NDA and data-sharing terms
Forecast and EDI data shared under a customer NDA stays inside the customer's own network or single-tenant cloud, never processed by a shared third-party service.
ITAR/EAR export control
Where program demand data ties to controlled technical data, on-prem deployment keeps that signal inside the customer's existing controlled environment rather than sending it to an external forecasting service.
SOX
Where forecast data feeds revenue commentary, every narrative and suggested override is logged against its source data, giving auditors a traceable record.
Data residency
In-region private cloud or on-prem deployment keeps demand and customer data within the jurisdiction the customer's own policy requires.
Where Netray fits
ERPray
ERPray provides the narrative and natural-language Q&A layer over forecast and order history, grounded in the same data your planners already work with.
Custom build
A custom build fits when the forecasting model itself needs training on the customer's own item and demand data, beyond what the ERP's native engine covers.
How an engagement runs
Phase 1 . 2-3 weeks
Discovery
- -Audit of current forecast accuracy (bias and MAPE) by item class
- -Review of planner override patterns and shadow spreadsheets
- -Inventory of external signals available, such as EDI and sales pipeline data
- -Data quality pass on item and plant hierarchies
Phase 2 . 6-8 weeks
Pilot
- -Narrative layer stood up for one product family or plant
- -Planner Q&A interface live
- -Side-by-side comparison of forecast-with-narrative against the current process for one planning cycle
- -Planner feedback loop
Phase 3 . Ongoing
Production
- -Rollout across remaining product families or plants
- -Override suggestions routed into the existing MRP or planning workflow with an approval gate
- -Accuracy tracking dashboard
Phase 4 . Ongoing
Scale
- -S&OP narrative rollup across plants
- -Agent-assisted forecast override drafting
- -Integration of additional external signals, such as customer EDI or market data feeds
Questions to ask any vendor, including us
A short list that separates real SAP S/4HANA AI work from a chatbot demo.
- Does the AI replace our existing statistical or ML forecast engine, or explain and supplement it?
- Can every forecast narrative be traced back to the source sales and forecast data it used?
- Where does our sales and customer demand data go, and does it leave our network?
- How does the system handle SKUs with under six months of history?
- Can planners override a suggested forecast change, and is that override logged?
- How is forecast accuracy, bias, and MAPE measured before and after, and who owns that measurement?
- Does the forecasting model need to be retrained as our product mix changes, and who does that?
- What happens to the narrative layer if we change ERPs or add a second one after an acquisition?
Frequently asked questions
Does AI demand forecasting replace SyteLine's, M3's, or SAP's own forecast engine?
Not necessarily. Most deployments sit beside the ERP's own statistical or ML forecast and add a narrative and Q&A layer explaining what changed and why. Some engagements add a supplementary forecasting model for item classes the ERP's native engine handles poorly, such as short-history SKUs, but the ERP's forecast usually remains the system of record for MRP.
How accurate is AI-assisted forecasting compared to what we have now?
It depends heavily on data quality and item mix, so treat any vendor's blanket accuracy claim with skepticism. A realistic pilot measures MAPE or bias by item class before and after on your own data over at least one full planning cycle, not a vendor benchmark from a different industry.
Can the AI layer see our customers' EDI forecasts and reconcile them automatically?
Yes, where EDI 830/862 data is already flowing into the ERP or a data warehouse, the same connectors used for ERP data can read it and flag material divergence from the internal forecast for planner review.
Will this stop planners from overriding the forecast in Excel?
Only if the narrative and Q&A layer is faster and more trustworthy than the spreadsheet habit it is replacing. The realistic goal in a pilot is to show planners the reasoning behind a number quickly enough that rebuilding it in Excel stops being the path of least resistance.
Is our demand data sensitive enough to need on-prem deployment?
For manufacturers whose demand signals reveal a customer's program volumes, particularly in defense and automotive supply chains, that is usually treated as sensitive under NDA or contract terms and is a strong argument for on-prem or private-cloud deployment rather than a public forecasting SaaS tool.
How long does a forecasting AI pilot take to show results?
Plan for one full planning cycle at minimum, typically 6-8 weeks for the narrative and Q&A layer to be live, plus however long your normal forecast review cycle runs, weekly or monthly, to gather enough before-and-after data points.
Does this work if we are multi-plant or multi-ERP after an acquisition?
Yes, the data and semantic layer is built to normalize item and plant hierarchies across sources, which is the same mechanism that lets it work across a SAP plant and an acquired company's SyteLine or M3 instance.
Related guides
A Private LLM Grounded on Your ERP Data
How a private LLM answers questions on your ERP data: RAG plus text-to-SQL, role-based permissions inherited from the ERP, and where each fits.
Agents + approval gatesAI Agents for ERP, Running On-Prem
A practical guide to on-prem AI agents for ERP: what they can safely automate, where human approval belongs, and how to design the guardrails.
PO follow-up that does not wait on a personAI Purchase Order Automation: Supplier Follow-Up and Expedite Without a Buyer Chasing Email
AI drafts routine PO confirmation and expedite messages from open ERP order data, with a buyer approving every message and change before it goes out.
ERP AI business caseBuilding the ROI Business Case for ERP AI in Manufacturing
How to build a defensible ERP AI business case: benefit mechanisms instead of vague productivity claims, cost structure, payback period, and sensitivity analysis.
Infor M3 + AIAI for Infor M3: A Practical Path from MI Programs to a Private Assistant
Add grounded AI to Infor M3: natural-language answers over MI programs and MEC, agents for distribution and manufacturing, on-prem or private cloud in Europe.
EMS / PCBA + on-prem AIAI for EMS and PCBA Manufacturers Running SyteLine, Epicor, or NetSuite
AI for EMS and PCBA manufacturers on SyteLine, Epicor, or NetSuite: automate BOM scrubbing, AVL checks, and obsolescence alerts, grounded in your own ERP data on-prem.
Plan it with numbers
AI Demand Forecasting Improvement Calculator
Turn a forecast error reduction into freed-up working capital and reduced stockout losses, based on your revenue, inventory value, and carrying cost.
Free ToolInventory Carrying Cost Calculator
Build your true annual carrying cost from capital, storage, insurance, and obsolescence components - and see what an inventory reduction target is worth.
Free ToolSyteLine MRP Health Check
Diagnose why your SyteLine MRP output is noisy or ignored, scoring data accuracy, parameters, and planner behavior across ten dimensions.
GuideImplementing AI Demand Forecasting Inside Your ERP
Implement AI demand forecasting inside SyteLine or Infor LN: data prerequisites, model selection, integration back into MRP, and a realistic rollout timeline.
GuideSyteLine Demand Forecasting Configuration Guide
Configure SyteLine demand forecasting with statistical models, forecast consumption, demand management parameters, and accuracy measurement for production planning.
GuideInfor M3 Demand Planning Configuration Guide
Configure Infor M3 demand planning with statistical forecasting, forecast consumption, MPS integration, and demand sensing for accurate production scheduling.
Talk it through with an engineer who knows SAP S/4HANA
Bring one real question your team cannot answer from the ERP today. We will map the data path, the model, and where it runs, and tell you honestly if AI is the wrong tool for it.