Why AI integration into ERP breaks on data
The forecasting module in ERP errs not in the math, but in the source data. Demand is calculated from order history, warehouse balances, and the production calendar, but these entities live in different subsystems and are updated at different frequencies.
Accuracy drops because of contradictory input, not because of the algorithm — this is the main bottleneck of forecasting.
The first source of loss is fragmented master data. Items are duplicated: “cable 3x2.5” and “cable 3*2,5” are different entries, units of measure are not aligned, one counterparty has three cards.
The model adds together what cannot be added, and the forecast for the product group diverges from actual shipment.
Manual adjustments quietly corrupt the training sample. A warehouse worker edits a balance, a procurement specialist closes an order “for reporting,” a manager moves shipment to the next period. The model takes these edits as fact and reproduces the human error as a demand pattern.
Delays in data uploads add bias. The nightly exchange returns an outdated snapshot: while the data is in transit, the warehouse has already changed, and the model receives a feature that did not exist at the time of forecasting. This is data leakage, and it inflates quality during validation.
All this is reinforced by the absence of a data owner: no one is responsible for item consistency, adjustment rules are not documented, quality is not measured. Therefore, AI integration into ERP is first and foremost work on ERP data quality, and only then on the model. Let's look at how this is addressed.
Demand forecasting on ERP data
The forecast is built not on a single sales series but on a combination of ERP data: shipments and returns by customer and warehouse, balances and lead times, price and promotion history, seasonal profiles of product groups.
The model outputs not a single number but a demand distribution — the planner sees the expected value and the bounds within which demand may go.
The planning horizon is divided into levels: short term for warehouse replenishment, medium term for purchasing with a long supply cycle, long term for production and budget.
Each has its own granularity and its own model: in the short term, fresh deviations and balances matter more; in the long term, trend and seasonality. This eliminates the main flaw of a single forecast that does not suit both warehouse and procurement at the same time.
The effect of AI in ERP is visible in accuracy and labor costs. Recalculation runs on schedule with current data, so manual reconciliations of uploads with planner spreadsheets are reduced severalfold.
The class of procurement errors — ordering based on last month, ignoring returns, double ordering the same item from different branches — is closed by rules and data quality control, not by employee attentiveness.
Exchange with the accounting system goes through standard interfaces, without manual intermediaries; in SAP landscapes these are standard exchange objects.
We validate accuracy on a holdout period and compare it with the current procurement rule, monitor model drift, and keep a fast rollback to the previous logic if the forecast diverges from fact.
Model connection options: comparison of approaches
The forecasting loop is connected to the accounting system in one of four ways, and the choice is dictated not by fashion but by the decision-making mode.
Where the decision is made within period close, the logic lives in the system itself; where the model learns on external data, it is moved to a separate service.
The difference is visible in response latency, load on the accounting loop, and the amount of work when updating the model.
| Option | When it fits | Limitations |
|---|---|---|
| Built-in AI module | The forecast is needed where the data is: procurement, reserves, overdue. There is no exchange between systems; calculation runs alongside posting. | It evolves with the accounting system and shares its load. |
| External model service | The model learns on data from several sources and changes more often than the accounting system. | An exchange channel and access rules are needed; if the service fails, a fallback scenario is required. |
| Batch calculation | Scheduled jobs: demand forecast, norm recalculation, procurement plan — launched at night when the loop is free. | The result is “yesterday’s”: between runs, decisions rely on outdated data. |
| Event-driven calculation | Reaction to an action: a large request, order status change, deviation from plan. | Harder to maintain: protection against repeated processing and an event log are needed. |
What to check before choosing
In practice, the options are combined: batch calculation sets the baseline plan, event-driven calculation adjusts it, and the built-in module returns the result directly in the document.
The main thing is to determine in advance which loop is considered the source of truth; otherwise forecasts will begin to diverge.
Implementation stages: from data audit to handover
The order of steps here is not a formality. If you start with model configuration while bypassing the data audit, the forecast is built on incomplete and contradictory records and diverges from fact already in the second week — and the “bad model” will be blamed.
Therefore, we go from the actual state of accounting data to a working loop inside your ERP, with a checkpoint at each transition.
- Data audit. We examine master data, movement history, and closed documents: where there are gaps, duplicates, manual adjustments. We record which records are suitable for forecasting and which will have to be restored or excluded.
- Flow diagram. We describe where data comes from and at what frequency, where the forecast is calculated, and how the result is returned to ERP documents — order, purchase, load plan.
- Exchange setup. We configure the integration in your environment: read and write permissions, exchange schedule, error handling, and retries when the source is unavailable.
- Validation on historical data. We run the model on closed periods and compare the forecast with fact for each item. If the deviation exceeds the agreed threshold, we return to feature preparation rather than tweaking the report.
- Pilot operation. Several weeks in parallel with current planning: we compare deviations and tune trigger sensitivity so there are few but relevant signals.
- Team training and handover. Your specialists receive regulations for updating models, analysis of typical failures, and forecast quality control — support does not require our ongoing involvement.
Documentation, regulations, and access at handover
Integration work ends not with launching the forecast but with handing over a set of artifacts that your team can use to develop the solution and troubleshoot failures without us.
Everything that appears in the project is recorded in the repository and knowledge base — not in chat threads and not in the heads of individual engineers.
- Data flow diagram: from export from the accounting system through intermediate storage to the feature mart and back-writing of the forecast into the accounting loop.
- Exchange configurations: schedules, incremental load rules, handling discrepancies, reruns, and suspicious volumes.
- Access role matrix: who sees raw data, who sees aggregates, who is authorized to change model parameters and trigger retraining.
- Policies for handling sensitive fields: masking, retention periods, separation of development and production environments.
- Integration documentation: exchange contracts, list of sources, description of features and assumptions, impact of gaps on forecast quality.
- Operations regulations: forecast quality control, degradation thresholds, retraining procedure, and rollback to the previous model version.
- Instructions for on-call shifts: typical exchange failures, checkpoints, escalation procedure, change log maintenance.
- Test environment with a reference dataset on which changes are validated before deployment to production.
Such a set allows in-house engineers to add sources and features without rebuilding the integration. Acceptance is based on a checklist: each item is closed with a document, access is granted and verified, and model rollback is tested in the test environment.
Case study: procurement forecasting in manufacturing
A manufacturing enterprise planned raw material procurement in the accounting system based on average consumption over past periods.
Such a forecast saw neither lead times of specific suppliers, nor warehouse balances, nor shifts in the production plan — so procurement specialists adjusted it manually for almost every item.
During peak weeks this resulted in shortages, and after the downturn, in frozen inventory that was later written off.
We collected purchasing, production, and warehouse movement history over several years and trained a forecasting model separately for each item. The calculation included seasonality, lead times for each counterparty, current balance, and the confirmed production plan.
The forecast is returned to 1C:ERP: the procurement specialist sees the recommended volume and order date, and a deviation from their edit above a specified threshold is flagged for review.
What changed in numbers
Forecast accuracy for critical items increased from 62% to 89%. The share of manual adjustments fell from 70% to 18% — procurement specialists moved from editing every line to reviewing exceptions.
Recalculating the procurement plan takes minutes instead of two working days, so the plan keeps up with production changes.
A separate class of errors that manual calculation did not catch was also closed: shortages during peak weeks and advance purchasing for a seasonal spike. The model holds both constraints simultaneously — minimum safety stock and absence of excess volume.
The same loop is transferred to other sites: data sources and approval rules change, while the forecasting logic remains.
What to do if ERP already has its own reports?
Standard ERP reports answer the question “what has already happened”: they are built on the same registers and postings as accounting and remain the source of truth for operational decisions.
The forecasting loop works as a supplement to reporting, not as its replacement: it connects to the same data and answers the question “what will happen.”
Almost everything is reused — item and counterparty master data, registers, access rights, scheduled export jobs.
The forecast is calculated on the same entities, so a second truth does not appear: discrepancies between the figure in the report and the figure in the model do not arise.
What is added is what ERP does not have: a layer of historical snapshots, features — seasonality, lead times, counterparty behavior — and the calculation itself.
The result is returned to ERP as an ordinary field: planned date, probability of overdue, recommended procurement volume. The user stays in the familiar interface.
The choice of approach depends on scale. When one answer is needed for one object and the rules are simple, the calculation is embedded in a standard report.
When there are several models and regular retraining with quality control is needed, the calculation is moved to a separate loop that reads the export and writes the result back.
Validation of the approach is comparison on historical data: where the forecast is more accurate than the current report, and where standard reporting is already sufficient.
If there is no gain, we do not touch the report — this is also a result of the review, and it saves the team’s effort.
FAQ about data, access, and reliability
AI integration into ERP rests not on the model but on data and the operating mode: master data diverge between modules, operation history has gaps, and access to the accounting system is granted for a specific task. Below are the doubts most often voiced at technical meetings, and our substantive answers.
We tie forecast reliability to measurable thresholds: share of deviations, speed of response to drift, behavior with incomplete data.
The model runs in the customer’s environment, and the rules for its updating and rollback are described before launch, not after the first failure.
What to do if historical data is incomplete or inconsistent?
We profile the sources: we calculate the share of gaps, duplicates, and discrepancies between master data for each dimension. Some we restore using matching rules, the rest we mark as unreliable and exclude from training.
We fix the data quality threshold before the start — if it is not reached, the forecast is issued with an uncertainty zone marker rather than as reliable.
Will accounting stop during implementation?
No. Work is carried out on a copy of the environment with depersonalized data, and we set up exchange in read mode.
We enable writing to the accounting system in stages by module and only after validation on a test period; each stage can be rolled back without losing posted documents.
Who is responsible for the model after launch?
We hand over the operations regulation: controlled metrics, retraining frequency, version rollback procedure. Engineers support an agreed period and transfer knowledge to your team — after that, the system runs on your infrastructure.
What access is needed to accounting data?
The minimum necessary: read access to specific registers and master data, without administrator rights. The service account is limited to a list of objects, the access log is stored on your side, and keys are not taken outside the environment.
Let's discuss the task: what to send for assessment
Assessment of AI integration into ERP begins not with the model but with the environment: which modules are involved, where historical data is stored, and who owns the master data.
The more precise the source materials, the fewer assumptions remain in the implementation plan and the more specific the timelines.
- Accounting environment diagram: the ERP itself, adjacent systems, the master system for master data, and the method of exchange between them.
- Export of historical data for 2–3 closed periods — sales, procurement, production, or logistics, depending on what we are forecasting.
- List of decisions that should appear: what we calculate, at what frequency, who is the consumer of the forecast, and in what form they receive it.
- Period close regulation and recalculation rules — they determine the frequency of model retraining and the moment the result is delivered.
- Role and access matrix: who sees data, who confirms recommendations, who is responsible for manual adjustment.
- Access to a test environment with depersonalized data or to a copy of the production database.
- Description of current decision points: where the plan is calculated today, how long it takes, and which errors repeat from period to period.
This is enough to analyze the task, fix the scope of work, and come back with an assessment, implementation plan, and timelines. If some data is missing, describe what you have: we will discuss which sources close the gap and how this affects the phasing.