The operations director of a Castilian distribution company with thirty employees puts it plainly: «I buy on instinct and I always get it wrong in the same direction: some references pile up and others run out of stock just when the customer needs them». That is the root problem of poorly resolved — or simply absent — forecasting. The good news is that in 2025-2026 connecting a demand forecasting model to Odoo, Dynamics 365 Business Central or Sage X3/Sage 200 is no longer an enterprise-scale project. With the right architecture, an industrial SME can have its purchase plan generated automatically every week, reviewed in thirty minutes and approved without touching a single spreadsheet.
This article explains what ERP-integrated demand forecasting is, how it connects technically to the three most common ERPs in the Spanish SME market, which models work best depending on the sector, and what implementation sequence has delivered the best results in real-world projects.
What «demand forecasting connected to the ERP» really means
Demand forecasting is the ability to predict how many units of each reference you will sell (or need in production) over a given time horizon — week, month or quarter — based on historical data, seasonal patterns, market trends and external variables. Until recently, that work was done by an analyst in Excel starting from a sales data export.
What changes when you connect the model to the ERP is that the cycle is closed: the forecast does not end in a PowerPoint report but instead directly generates purchase order proposals (purchase orders in the ERP), adjusts replenishment parameters (minimum stock, reorder point, economic order quantity) and can trigger alerts to the purchasing manager when a critical reference deviates from the expected pattern.
The integration has three layers:
- Data extraction: the model reads sales history, current stock, open orders and supplier lead times directly from the ERP tables (or via API/connector).
- Model computation: an algorithm — which can be classical such as ARIMA/Holt-Winters or machine-learning-based such as Prophet, XGBoost or an LSTM network — calculates the forecast demand by reference and period.
- Writing results back: the suggested orders are pushed back into the ERP as draft purchase orders, which the responsible person validates or rejects with a single click.
How it integrates with Odoo, Dynamics 365 and Sage
Each ERP has its own integration architecture and its own constraints. Here are the most relevant practical differences for the technical team designing the solution.
| ERP | Main integration mechanism | Native forecasting module | Openness level for external AI |
|---|---|---|---|
| Odoo 17/18 | REST JSON-RPC API + Replenishment module | Basic Replenishment (reorder rules); no native ML | High: accessible ORM, easy to write to stock.warehouse.orderpoint |
| Dynamics 365 Business Central | OData v4 API + Power Automate / Azure ML | Planning Worksheet with demand forecasting via Azure AI Forecast | High with Premium licence; MS copilots only with Copilot licence |
| Sage X3 | SOAP/REST Web Services (Syracuse) + events | Basic MRP; no native ML module | Medium: requires specific connector licences |
| Sage 200 | REST API (Sage 200cloud) or direct SQL DB access | No native forecasting module | Medium-low: the fastest path is reading the DB directly |
Odoo: the most agile option for budget-conscious SMEs
Odoo exposes all its inventory and purchasing logic via JSON-RPC. The AI model reads the sale.order.line and stock.move tables to build the history, calculates the forecast and writes directly to stock.warehouse.orderpoint (the replenishment rules) or creates purchase.order records in draft state. The complete cycle can be automated with n8n or a Python script scheduled in cron, without the need for expensive middleware.
A more advanced variant uses the Odoo Forecasting module (available in Odoo Enterprise 16+) which adds a forecasting view per product with adjusted moving average. It is a useful starting point, although for complex seasonal demand or with many references (more than 500 SKUs) it is worth replacing it with a more powerful external model.
Dynamics 365 Business Central: the Azure path for companies already in the Microsoft ecosystem
Business Central has a native connector with Azure AI Forecast (powered by Azure Machine Learning), allowing demand forecasts to be generated directly from the Planning Worksheet. The model takes the sales history from the Sales module and returns a forecast demand curve that MRP consumes to calculate purchasing requirements.
For companies already using Microsoft 365 and holding Premium Business Central licences, this is the most direct path. If the SKU volume is large or external variables need to be incorporated (weather, commodity price indices, sector Google Trends data), the alternative is to build a pipeline in Azure Machine Learning or Azure Databricks and connect the results to Business Central via OData API or Power Automate.
Sage: access via the database or the Web Service
Sage X3 has a Web Services server (Syracuse) that exposes business objects such as ORDERS, PURCHASEORDERS or SSTOCK. This is the official channel for integrations. The problem is that connectors require additional licences and the learning curve is steep. In many SME projects with Sage X3, the most pragmatic path is to extract data directly from the underlying Oracle or SQL Server database (with read-only access for the model) and write purchase orders via Web Service or, in less demanding cases, by generating a CSV import file that the user validates before uploading.
Sage 200cloud has a documented REST API that allows reading sales orders (GET /sales-orders) and stock movements (GET /stock-transactions) and writing purchase orders (POST /purchase-orders). For companies with on-premise Sage 200, the fastest path is usually the SQL Server database with a nightly extraction job.
Which forecasting models to choose depending on your case
There is no single optimal model. The choice depends on three factors: the volume of references (SKUs), the demand pattern (seasonal, erratic, clear trend) and the availability of historical data (less than 18 months limits seasonal models).
| Demand type | Recommended model | Minimum history required | Notes |
|---|---|---|---|
| Stable with gentle trend | Holt-Winters (ETS) / SARIMA | 12-18 months | Interpretable, easy to audit |
| Strong seasonality (food, fashion, construction) | Prophet (Meta) / SARIMA with regressors | 24 months | Prophet handles holidays and multiple seasonalities well |
| Many references (> 500 SKUs), mixed patterns | XGBoost / LightGBM with lag features | 18 months | Scales well; requires more feature engineering effort |
| Erratic or intermittent demand (spare parts, MRO) | Croston / TSB / LSTM | 24 months | ARIMA and Prophet fail with sporadic demand |
| New references with no history | Pattern transfer from analogous references | N/A | Based on category, price and channel similarity |
In industrial SME projects, the model that best combines accuracy and maintainability for a range of 100-800 SKUs with medium seasonality is Prophet (open source, by Meta), which also natively handles Spanish and regional public holidays — a critical factor in food distribution or building materials.
The automatic purchase plan: how the complete circuit works
Once the model produces forecasts by reference and period, the purchase plan automation circuit follows this sequence:
- Weekly forecast: every Monday at 02:00 the pipeline extracts the updated history from the ERP, recalculates the model and generates a table with forecast demand per SKU for the next 8 weeks.
- Requirements calculation: available stock, in-transit stock (already confirmed purchase orders) are subtracted and the target safety stock is applied, yielding the net quantity to order per reference.
- Grouping by supplier and lead time: requirements are grouped by supplier, respecting the lead times registered in the ERP and each supplier's minimum order quantities (MOQ).
- Creating drafts in the ERP: the system creates purchase orders in draft state grouped by supplier, with detailed lines and automatically calculated required delivery dates.
- Human review (30 minutes): the purchasing manager receives a summary by email or in their ERP panel with the proposed orders. They can adjust quantities, delete lines or approve in bulk. Only then are orders confirmed.
- Continuous learning: each week the model consumes the actual sales from the previous period and recalibrates its parameters, progressively improving accuracy.
This circuit reduces the purchasing manager's time from two or three days a week to less than one hour. Exception decisions — supplier changes, volume negotiations, references with imminent stock-out — remain human. The AI automates the repetitive work and frees the team to focus on what creates real value.
If you want to see how this circuit applies to your specific ERP, the Summum IA team carries out a demand forecasting diagnostic that starts from your real data and delivers a working prototype before committing the full project budget.
External variables that improve model accuracy
A model trained only on your own sales history has a precision ceiling. External variables (regressors in forecasting parlance) allow you to break through that ceiling when demand responds to signals from the environment:
- Weather: essential in food, beverages, HVAC and building materials. Historical temperature and precipitation series from AEMET are free and improve MAPE (mean absolute percentage error) by up to 15-20% in climate-sensitive sectors.
- Commodity prices: the INE IPRI index or commodity futures (wheat, steel, PET plastic) anticipate demand movements in the processing industry.
- Holiday and campaign calendar: Prophet natively incorporates Spanish public holidays; for your own campaigns (Black Friday, Epiphany, summer) it is enough to add a binary column to the training dataset.
- Macro indicators: Spain's manufacturing PMI (published monthly by S&P Global) is a useful leading predictor for industrial B2B distributors.
- CRM sales pipeline: if your sales team logs expected orders from large customers in HubSpot or Dynamics CRM, that data provides direct signals of future demand that the model can consume.
Metrics to measure whether forecasting is working
Before implementation and after each iteration, the project must be measured with concrete metrics. The most commonly used in SME projects:
- MAPE (Mean Absolute Percentage Error): the average percentage error per reference. Below 20% is considered a good result for volatile demand; below 10% for stable demand.
- Bias: systematic tendency to over- or under-estimate. A sustained negative bias means the model is buying too little; positive means it is accumulating unnecessary stock.
- Fill rate: the percentage of customer order lines fulfilled completely and on time. This is the business metric that forecasting should move.
- Inventory turnover: reducing average inventory without worsening fill rate is the efficiency indicator for the complete cycle.
- Stock coverage (days): how many days of forecast demand current stock covers. This typically drops by 15% to 30% after implementing a well-calibrated forecast, without increasing stock-outs.
How much does an ERP-integrated forecasting project cost: market ranges
The following ranges are indicative of the Spanish market in 2025-2026 for consulting and implementation projects, not Summum tariffs. Sources: public proposals in tender portals, Gartner benchmarks and IT sector reference publications (IDC, Forrester).
| Project type | Typical scope | Investment range (€, excl. VAT) | Estimated timeline |
|---|---|---|---|
| Diagnostic + prototype | Data analysis, pilot model on 50-100 SKUs, retrospective validation | 4,000 – 9,000 € | 3-5 weeks |
| Basic implementation (up to 500 SKUs, 1 ERP) | Model in production, ERP integration, monitoring dashboard | 12,000 – 25,000 € | 2-3 months |
| Advanced implementation (500+ SKUs, external variables, multiple warehouses) | MLOps pipeline, automatic retraining, alerts, CRM+ERP integration | 25,000 – 60,000 € | 3-5 months |
| Annual evolutionary maintenance | Model monitoring, seasonal adjustments, technical support | 4,000 – 12,000 €/year | Ongoing |
The factors that push the price up most are: number of SKUs to manage, number of warehouses or distribution centres, complexity of ERP integration (especially in Sage X3 with customisations), and whether dedicated cloud infrastructure is required (Azure ML, AWS SageMaker) versus open-source tools deployed on the client's own server.
Common mistakes in forecasting projects that fail
A high proportion of forecasting projects in SMEs never reach production after six months, according to various studies on supply chain analytics (Gartner estimates that 60% of supply chain digital adoption efforts fail to deliver their promised value). The most frequent causes:
- Dirty data in the ERP: duplicate references, inconsistent units of measure, unregistered stock movements. The model learns what you give it: if the history is bad, the forecast is bad. Data cleansing consumes 30-50% of the time in a well-run project.
- Inadequate forecast horizon: requesting 6-month forecasts for references with a 2-week supplier lead time is unnecessary and generates uncertainty. The horizon should be adjusted to the maximum replenishment lead time plus a safety margin.
- No model owner: if no one in the company is responsible for reviewing forecasts weekly and feeding the model with known exceptions (planned campaigns, large contracts already signed), the system degrades within weeks.
- Over-automation from day one: starting with draft orders that require human approval before confirmation is safer than connecting directly to automatic confirmation. Confidence in the model is built gradually.
- Not measuring before/after: without baseline metrics (fill rate, coverage days, hours spent on purchasing), it is impossible to demonstrate return on investment and secure budget renewal.
Frequently asked questions
Can a forecasting model work with less than one year of history?
With less than 12 months of history, seasonal models (Prophet, SARIMA) do not have enough data to learn annual patterns. In that case, the alternative is to use simpler models (weighted moving average, exponential smoothing) or to supplement your own history with sector data. For new references without history, the demand pattern of similar established references can be transferred. In general, 18-24 months of clean history is the recommended starting point for a robust model.
Does AI forecasting replace the purchasing manager?
No. What it does is eliminate repetitive calculation work — extracting sales, averaging, estimating requirements — and focuses the manager's attention on decisions that genuinely require judgement: managing difficult suppliers, negotiating terms, making decisions based on market information the model does not have. In projects seen in the market, the time spent on administrative purchasing tasks is reduced by 50% to 70%, but the role remains essential.
Does it work for companies with very irregular demand or very concentrated customers (B2B with few large clients)?
Customer concentration is the hardest case for any statistical model, because the loss or gain of a large customer radically distorts the history. In these cases, the most effective solution is hybrid: a statistical model for recurring small-volume references, combined with manual inputs from the sales team (CRM pipeline) for references that depend on large contracts. Some ERPs, such as Dynamics 365, allow sales forecasts from the CRM to be incorporated directly into the demand planning process.
Does demand forecasting also help in production, or only in purchasing?
The same demand forecast that feeds the purchase plan can also feed the master production schedule (MPS) if the company manufactures. In that case the flow is: demand forecast → finished product requirements → semi-finished goods and raw material requirements (bill of materials BOM explosion) → coordinated purchase plan and production plan. Odoo, Dynamics and Sage X3 have MRP modules that can consume forecasts generated by the external model through their respective APIs.