In a garment factory in the Vale do Ave with 120 employees, the head of purchasing spends every Monday morning exporting three files from the ERP, pasting them into a spreadsheet and trying to guess what will be short the following week. It is not a lack of technology — the ERP is there. It is a lack of connection between what the system knows and what the buyer decides.
The thesis of this article is uncomfortable: the problem is not the absence of AI in Portuguese industrial SMEs. It is that, when AI does arrive, it lands in a procurement process that was not designed to receive it. The forecast sits in a dashboard. The purchase order is still written by hand. And the Monday Excel file survives another quarter.
According to INE, in 2025 only 9.4% of small Portuguese companies with 10 to 49 workers used artificial intelligence — and among medium-sized companies (50 to 249 workers) the rate does not reach 20%. The overwhelming majority of Portuguese industrial SMEs still have no AI layer between historical data and the purchasing decision. The spreadsheet remains the de facto middleware. What this article explains is how to close that gap — from the forecast to the automatically generated purchase order — with the real trade-offs that no software vendor presents in the demo.
The ERP holds all the data that AI would need. The problem is that no one connected it to the decision engine.
The problem is not the forecast — it is the last mile
Most discussions about AI and demand forecasting focus on the models: ARIMA, Prophet, neural networks, gradient boosting. The real problem for Portuguese factories lies elsewhere. It lies in the last mile — the jump between "the model forecasts X units" and "the ERP issues the purchase order".
We see this repeatedly: a company installs a forecasting module, the model runs, the numbers appear in a report, and the buyer carries on doing what they always did because they do not trust numbers they do not understand and do not have time to question them. The model did not fail. The integration never existed.
For a Portuguese industrial SME, the value of AI in demand forecasting does not lie in the most sophisticated model — it lies in the integration between the model and the procurement flow already in place in the ERP MULTI or equivalent. Without that integration, the forecast is just another report that no one reads on Monday mornings.
What has changed to make this relevant now
Sufficient and clean historical data
A textile factory in the Vale do Ave cluster with five years of active ERP typically has tens of thousands of lines of stock movement, purchase orders and customer order notes. That volume is already enough to train time-series models with useful results — not perfect, but better than the 12-week moving average most use today. The reasonable minimum threshold is 24 months of clean history. With less than that, the model learns the noise, not the patterns.
Accessible cloud infrastructure
Until a few years ago, running a machine learning model required dedicated infrastructure and a data science team. Today, the main cloud providers offer AutoML services that an IT team of three people can operate without specialist training. Compute cost is no longer the main obstacle. The main obstacle has become data quality — and that is a process problem, not a technology one.
Native APIs in modern ERPs
QAD Adaptive ERP exposes REST APIs that allow externally calculated forecasts to be injected directly into procurement suggestions. This means the AI model does not need to replace the ERP — it feeds it. The purchase order is still generated by the ERP, with all the business rules, approvals and traceability that already exist. AI enters as a decision layer, not as a substitute for the system of record.
Regulatory and traceability pressure
The EU Strategy for Sustainable and Circular Textiles requires material traceability along the value chain. A purchase order generated automatically by AI has to be auditable — who approved it, on the basis of which forecast, with what input data. The AI Act (Regulation EU 2024/1689), in force since August 2024, classifies AI systems that influence procurement decisions in an industrial context and requires documentation of the model's reasoning. It is not an optional requirement: it is compliance that has to be designed into the architecture from the outset, not added afterwards.
The real technical options
Approach 1 — Native ERP module
Some vertical ERPs include statistical forecasting modules based on simple time series: weighted moving average, exponential smoothing. It is not AI in the strict sense, but for products with stable demand and predictable seasonality — cotton yarn in spinning, sole components in footwear, standard packaging in food distribution — it works reasonably well. The advantage is zero additional integration. The disadvantage is structural: the model does not learn from external variables. A sales campaign, a supplier delay, a demand peak from a seasonal event — none of this enters the calculation. The model is blind to context.
Approach 2 — BI layer with predictive models
BI tools such as Qlik Sense allow forecasting scripts in R or Python to be embedded directly in the dashboards. The analyst sees the forecast alongside the operational KPIs and decides manually whether to convert it into a purchasing suggestion. It is a middle-ground approach: more sophisticated than the native module, but with mandatory human intervention in the last mile. The risk is that "mandatory human intervention" becomes, in practice, "no one has time for this and the suggestion stays in the dashboard forever".
Approach 3 — External AI pipeline with API integration
The model runs outside the ERP — in your own cloud, Azure ML, AWS SageMaker or similar — consumes data via ETL from the ERP, generates forecasts and returns procurement suggestions directly to the purchasing module. The purchase order is created automatically when the forecast exceeds the reorder point and the preferred supplier is active. It is the only approach that eliminates the Monday Excel file. It requires consistent technical integration and a partner that knows both the model and the ERP — the most common failure is building an excellent pipeline that no one in the company can maintain six months after implementation.
Approach 4 — Specialist demand planning platform
Dedicated demand planning solutions integrated with the ERP via standard connectors offer more sophisticated models, including the incorporation of external data: weather, search trends, trade fair calendars. For footwear companies in Felgueiras with 800 to 1,200 SKUs and three axes of variation — colour, size, last — this is often the only approach that models the real complexity. International buyers visit twice a year and the ordering windows are short. A forecasting error in a women's footwear collection in February is not corrected until August. The licence and implementation cost is correspondingly higher, but so is the cost of a poorly provisioned collection.
| Approach | Technical complexity | Time to production | Forecast quality | PO automation |
|---|---|---|---|---|
| Native ERP module | Low | 2–4 weeks | Basic (simple time series) | Yes, native |
| BI with predictive models | Medium | 6–10 weeks | Medium (depends on the model) | No — manual decision |
| External AI pipeline + ERP API | High | 14–24 weeks | High (supervised ML) | Yes, via API |
| Demand planning platform | Medium-High | 16–28 weeks | Very high (multi-variable) | Yes, with approval workflow |
Trade-offs by company size
Fewer than 50 employees: the native ERP module is, in most cases, the right answer. Not because it is the best model — it is not. But because the IT team does not have the capacity to maintain an external pipeline, and the opportunity cost of a 20-week implementation is too high relative to the volume of purchases at stake. Start with the ABC analysis of purchased items: the 20% of references that represent 80% of purchasing value are the only ones that justify sophisticated forecasting. The remaining 80% of references can carry on with fixed safety stock and monthly review — and that is correct.
Between 50 and 200 employees, the BI approach with predictive models has the better return. The company already has enough data volume, already has someone who uses the BI regularly, and the jump to time-series models with seasonality does not require a full-time data scientist. The main risk is not technical — it is maintenance fatigue. The model needs to be retrained periodically, and that has to be in the calendar of someone with a name and a responsibility. When it is not, the model quietly becomes outdated and the forecasts degrade without anyone understanding why.
Above 200 employees or with high SKU complexity, the external pipeline with API integration or the specialist platform are the only options that scale. A food distribution company in the Lousada-Paços de Ferreira corridor with 30,000 active references and variable lead times cannot manage item-by-item forecasting with simple time series in an operationally useful way — the model does not capture the customer's promotions, the supplier's stock-outs or the substitution effects between SKUs. It needs a model that learns relationships between items, not just the history of each one in isolation.
In a company with 800 active SKUs, the average forecasting error is not the problem. The problem is the error in the 40 items that represent 60% of the margin.
The data architecture that no one designs before starting
Any demand forecasting model needs, at a minimum, five types of data: sales or consumption history by item and by period without gaps from stock-outs; a calendar of past promotions and campaigns with exact dates; real lead times by supplier and by item — not the contractual lead time, the effective lead time recorded in the warehouse receipts; current safety stocks and the logic that produced them; and sector-specific seasonality data, which for footwear means the international trade fair calendar, for textiles the fashion campaigns, and for food distribution the calendar of festivities and chain promotions.
The problem we encounter repeatedly: the ERP has the sales data, but the real lead times are in the buyer's spreadsheet. The promotions are in an email from three months ago. The historical stock-outs are not flagged — they appear as zeros that the model will interpret as an absence of demand, when in reality they were weeks when demand existed but the stock did not. A sophisticated model fed with dirty data produces worse forecasts than a simple moving average with clean data. Audit the data quality before choosing the model.
The data preparation pipeline has a sequence that is rarely respected. First, extract the stock movement history for the last 36 months from the ERP — not the invoiced sales, the real warehouse outbound movements. Second, identify and flag the stock-out periods: zero stock with pending demand. Replace those zeros with estimates of unmet demand, calculated from the backorders recorded in the ERP. Third, enrich with the calendar of promotions, holidays and relevant sector events. Fourth, validate the effective lead times per supplier calculated from the order dates and warehouse receipt dates — contractual lead times are a useful fiction for negotiation, not for planning. Fifth, define the time granularity: week is the minimum useful level for most industrial sectors; month is too coarse for distribution with high rotation.
From forecast to purchase order: the approval flow
Full automation vs. assisted automation
The fully automatic purchase order — with no human approval — is technically possible. In practice, it is imprudent for most Portuguese industrial SMEs. The model does not know about the negotiation under way with the supplier: the buyer may be renegotiating price and an automatic PO commits the negotiating position before the right moment. The model does not detect recent quality anomalies: an open complaint about the last batch is not, typically, in the model's data feed. And the AI Act, for decisions with significant financial impact, strongly recommends documented human oversight — not as bureaucracy, but as a correction mechanism when the model gets it wrong.
The correct approach for most companies is assisted automation: the model generates procurement suggestions with quantity, supplier and lead time; the buyer approves, adjusts or rejects with one click; the ERP issues the PO. Decision time falls from hours to minutes. The responsibility remains human. Traceability is guaranteed. The buyer stops building the suggestion and starts validating it — which is a substantial change of role that has to be managed, not just announced.
Confidence thresholds and automatic escalation
Configure the system with explicit confidence thresholds. When the model has high confidence in the forecast — low historical deviation, item with stable demand, supplier with a consistent lead time — the suggestion goes straight to the buyer for quick approval. When confidence is low — new item, irregular seasonality, supplier with a history of delays — the suggestion escalates to manual review with the supporting data visible on screen. Do not treat all suggestions the same way. That is exactly what generic ERPs do, and it is why buyers learn to ignore the suggestions after three months.
An automatic procurement system that generates 200 suggestions a week with the same visual priority is a system that the buyer will learn to ignore within three months.
Decision matrix: which approach for your context
| Criterion | Native ERP module | Predictive BI | AI pipeline + API | Specialist platform |
|---|---|---|---|---|
| No. of active SKUs | <500 | 500–2,000 | 500–10,000 | >2,000 |
| Relevant external variables | No | Limited | Yes | Yes, many |
| Internal IT capacity | Minimal | Medium | High or external partner | Medium + partner |
| Clean data history | Not critical | Important | Critical | Critical |
| PO automation | Native | Manual | Via API | Native with workflow |
| AI Act compliance | Simple | Simple | Requires documentation | Requires documentation |
| PT2030 funding eligible | Partially | Yes | Yes | Yes |
What works in practice
Start with the right item, not the right model
A footwear factory in Felgueiras with 900 active SKUs could, in theory, apply AI forecasting to the entire range. The gain concentrates in the 80 to 120 bottom-of-range items with stable demand — the sole components, the standard laces, the everyday linings. These are the ones that generate the most expensive stock-outs and the most persistent stock excesses, precisely because no one pays attention to them: they are items with no glamour, no apparent urgency, until the day they stop the line. Starting with these items, with a simple but well-fed model, produces visible results in two to three months. Expanding afterwards to fashion items, with aggressive seasonality and short ordering windows, is a second project — with the lessons from the first already embedded in the team.
The buyer as validator, not as operator
In the implementations that work, the buyer's role changes concretely: they stop building the purchasing suggestion and start validating the system's suggestion. This only works if the system shows, next to each suggestion, the data that supports it — consumption history, expected lead time, current stock, safety stock, and the forecast's confidence interval. Without this data visible on the same screen, the buyer has no basis to disagree with the model. Either they approve everything blindly, or they reject everything out of distrust. Both behaviours nullify the value of the system. The KORA Inventory Suite allows this context information to be presented directly in the approval flow, without forcing the buyer to navigate to another screen or open another system.
The sales force as a source of early signal
The AI model learns from the past. The salesperson knows what is going to happen in the next four weeks. It is a structural mismatch that demand planning manuals rarely address. A distribution company in the Lousada-Paços corridor could integrate the sales force visit notes — recorded via KORA Sales Suite — as an input variable in the model. When the salesperson records that a customer is going to launch a promotion in March, that signal can adjust the demand forecast before the history reflects it. It is exactly the kind of tacit knowledge that Portuguese factories have in abundance — and that is rarely digitised. Capturing it does not require a more sophisticated model. It requires a recording process that the salesperson actually uses.
Compliance and traceability: what to document
AI Act and procurement decisions
Regulation (EU) 2024/1689 classifies AI systems by level of risk. A system that generates purchase orders automatically is not, in general, classified as high risk — that category is reserved for AI in critical contexts such as health, public safety or employment. But it requires minimum documentation: description of the model, training data used, decision logic, human oversight mechanism, and a record of the decisions taken. Keep this documentation in the Document Management system with versioning. The auditor will ask for it — and will ask for it at the least convenient moment.
NIS2 and the digital supply chain
The NIS2 Directive, transposed into Portugal by DL 65/2025, imposes cybersecurity requirements on essential and important entities, including the security of the digital supply chain. An AI pipeline that communicates with the ERP via API is a potential attack vector that many companies do not consider when they design the architecture. Audit the ERP access permissions that the pipeline uses, implement token authentication with periodic rotation, and log all accesses. Consult the cybersecurity policy applicable to your infrastructure before exposing the ERP to external integrations.
SAF-T and purchase order traceability
Automatically generated purchase orders have to be traceable in SAF-T (Portaria 195/2020). Check that the ERP generates the PO origin field in a way that allows manual orders to be distinguished from orders generated by automatic suggestion. This is not just good practice — it is what allows the tax auditor and the quality auditor to understand the rationale behind each purchase. Discovering that the field does not exist after six months of automatic POs is a reconciliation problem that consumes weeks.
How to measure success after implementation
Four operational metrics define whether the system is working. The MAPE — mean absolute percentage forecasting error per item — is the base indicator: for bottom-of-range items with stable demand, a value below 15% is reasonable; above 30%, the model is not adding value over the simple historical average. The stock-out rate — percentage of days with zero stock for items with active demand — should fall by 30 to 50% for the items covered by the model in the first year; if it does not fall, the model is forecasting but is not influencing purchasing. Stock rotation should increase by 10 to 20% for the items managed by the model: if the forecast is good, safety stock can be reduced without increasing stock-outs. And the PO approval cycle time — the average time between the system's suggestion and the issuing of the PO — has to fall relative to the manual process; if it does not fall, the approval workflow is not working and the buyer is doing the same work as before with one extra step.
Retrain the model at least quarterly. Compare the MAPE of the current model with that of the previous model. If quality does not improve with more data, the problem is not the volume of history — it is the data quality or the choice of model. Do not invest in more compute before resolving the data quality. It is an expensive and frequent mistake.
To go deeper into the logic of integration between shop-floor systems and the ERP, the article on MES without ERP integration: the hidden cost the COO does not see develops the risks of decision-making with fragmented data. For the governance dimension and documentation of the AI model, the article AI governance in industrial SMEs: what to document before the AI Act is the natural next step. And if the topic is the broader automation of industrial processes, Industrial process automation: where AI starts to pay off contextualises where demand forecasting fits into the factory's digital maturity.
Just-in-Time was for decades the ideal of industrial procurement. AI does not replace it — it finally makes it practicable for companies that do not have Toyota's demand stability. The difference between a forecast that stays in a dashboard and a forecast that generates a purchase order is, almost always, an architecture decision taken at the start of the project. Taking it late is not just more expensive. It is more expensive and harder to undo.
Sources
- INE — Survey on the Use of Information and Communication Technologies in Enterprises, 2025. Available at ine.pt
- Eurostat — ICT usage in enterprises: Artificial Intelligence, 2025. Available at ec.europa.eu/eurostat
- Regulation (EU) 2024/1689 of the European Parliament and of the Council (AI Act), published in the Official Journal of the EU on 12 July 2024. Available at eur-lex.europa.eu
- Directive (EU) 2022/2555 (NIS2), transposed into Portugal by Decree-Law 65/2025. Available at eur-lex.europa.eu and dre.pt
- Portaria 195/2020 — monthly SAF-T communication to the Tax and Customs Authority. Available at dre.pt
- European Commission — EU Strategy for Sustainable and Circular Textiles, COM(2022) 141 final. Available at ec.europa.eu
Frequently asked questions
What is the "last mile" in AI demand forecasting?
It is the jump between the AI model forecasting a quantity and the purchase order being automatically issued in the ERP. Many companies install forecasting, but the buyer carries on ignoring the numbers because they do not trust them or do not have time. The integration between forecast and purchasing decision was never done, making the model useless in practice.
Why do Portuguese SMEs still use spreadsheets for purchasing?
The ERP already contains all the necessary data, but no one connected it to the decision engine. The procurement process was not designed to receive AI. So the buyer carries on exporting files manually every week because it is the flow they know and control, even if it is inefficient.
How much data history is needed to train a forecasting model?
The reasonable minimum threshold is 24 months of clean history. A factory with five years of active ERP typically has tens of thousands of lines of stock movement, which is enough to train time-series models with useful results, superior to the traditional moving average.
Can AI completely replace the ERP in generating purchase orders?
No. AI enters as a decision layer, not as a substitute. The model calculates the forecast externally and feeds the ERP via API. The purchase order is still generated by the ERP, keeping all the business rules, approvals and traceability already in place in the system.
What is the difference between using the native ERP module and an external AI layer?
The native module (moving average, exponential smoothing) works well for stable demand and predictable seasonality, but is blind to external context. An external AI layer can incorporate variables such as sales campaigns, supplier delays or seasonal events, offering more sophisticated and adaptable forecasts.
Does the European AI Act require changes to the design of AI for purchasing?
Yes. Regulation EU 2024/1689 classifies AI systems that influence industrial procurement decisions as carrying risk and requires documentation of the model's reasoning. Auditability — who approved, with what data, on the basis of which forecast — has to be designed into the architecture from the outset, not added afterwards.
What is the main obstacle to implementing AI in Portuguese SMEs: technology or data?
It is no longer the technology. Cloud infrastructure and AutoML services are accessible and operable by small IT teams. The main obstacle is data quality and integration with existing processes — process problems, not technology problems.