Where an ERP AI assistant breaks on real data
Almost every ERP AI assistant rollout starts the same way: a pilot on a cleaned-up demo database produces sensible forecasts and recommendations, yet a month later in the live accounting system the same queries return contradictory answers.
The reason is not the model — it is that demo data and production data are two different worlds. Let us break down where the link between the assistant's answers and reality snaps.
The first break is fragmented master data. Items are maintained with full names in one subsystem and abbreviations in another, and counterparties accumulate duplicates with differently spelled details.
The assistant spreads one customer's sales across two records, and forecast errors grow not because of the algorithm but because the accounting object is not uniquely identified.
The second break is manual exports. Data reaches the assistant as files that someone prepares on a schedule, so it works not with the current state but with a snapshot as of the export date.
The delay turns a purchasing recommendation into a statement of a shortage that has already occurred.
The third break is differing calculation rules. The same metric is calculated differently across departments: with returns in some places, without them in others.
The assistant averages the interpretations, and no one validates data quality in the accounting system before launch — hence the discrepancy with what the manager sees in the report.
The conclusion is simple: you cannot put an assistant on top of data that no one has reconciled. Below we break down how we close these gaps.
How an ERP AI assistant changes reporting and forecasting
The assistant does not duplicate the accounting loop — it reads it: it connects to a 1С:ERP database or another corporate system through regulated access, matches master data, and builds a data mart for calculations.
A report is generated on demand from primary data, not from a copy in a spreadsheet that someone updated manually last week.
Two effects show up in the very first month. The share of reports assembled on demand grows to 80–90%, with rare forms requiring manual reconciliation covering the rest.
Every metric can be drilled down to the source document: following a variance leads to the journal entry, batch, or contract, so the question "where does this number come from" is answered in minutes rather than a day of back-and-forth messages.
Demand forecasting is based not on extending the previous period but on a model built from shipment history, seasonality, stock levels, lead times, and price.
The horizon is up to a quarter by product group, and the error over a short interval drops by roughly a third compared with manual estimation. Analysts stop working as an export factory and move on to testing hypotheses and tuning models.
Along with manual exports, an entire class of failures disappears: mismatched file versions, rows lost during copying, reports on an incomplete period.
Reducing manual operations here is not a goal in itself but a consequence — the fewer steps between data and a decision, the fewer places where a number can get corrupted.
Connection options to the accounting system and their limitations
The connection to an accounting system is always a trade-off between data freshness, load on the production loop, and the scope of access rights. We work with three schemes: an embedded module, an external service with an export, and a hybrid.
Each constrains access to the accounting system in its own way, so the choice depends on what matters more — an instant assistant response or a predictable load on accounting.
| Option | When it fits | Integration constraints |
|---|---|---|
| Embedded module | The assistant lives inside the accounting system and answers are needed while the user works | Access rules are set by the accounting system itself; updates follow its pace; analytical queries compete with user transactions |
| External service with an export | Forecasts and analytics are needed over accumulated history and accounting cannot be loaded | Data arrives with a delay; master data is duplicated; the export and accounting need to be reconciled on a schedule |
| Hybrid scheme | Real-time prompts come from accounting, while heavy analytics and forecasts run on a separate data copy | Two access loops: it is harder to separate rights, keep a request log, and track who reads which entities |
In practice the hybrid is chosen most often: the assistant reads only the entities it needs, and forecast computation runs on the service side.
Integration limitations then stop being a risk — the load on accounting is predictable, and the assistant's answers do not depend on whether the period close is running.
Implementation stages: data audit, schema, configuration, validation
Deploying an assistant on top of an accounting system is first and foremost work with data, not with the model. Until master data is reconciled and the links between documents and registers are formally described, the assistant answers confidently and incorrectly. That is why the sequence of work is fixed.
- Data audit. We look at master data completeness, duplicate counterparties and items, empty mandatory fields, and discrepancies in units of measure. The output is a list of defects with an assessment of how each one will distort the assistant's answer.
- Schema design. We describe the links between documents, registers, and master data: which fields are keys, which movements to account for, over what period data is comparable. We agree the schema with your accounting staff before configuration begins.
- Query configuration. For each type of question — stock, debt, dynamics, variances — we assemble a limited set of validated queries with filters by period and user rights. The assistant chooses from ready-made ones rather than constructing them arbitrarily.
- Access separation. Roles are carried over into the assistant: a department head will not see data that is closed to them in the accounting system. We test on a test account for each role.
- Answer quality validation. A run over historical periods with reconciliation against accounting system reports. We record the share of discrepancies and separately examine questions with no data: the assistant must say "insufficient data" rather than substitute a similar number.
- Handover to operation. A procedure for updating when master data changes, a log of queries and wording changes, an owner for quality, and user training on their own data.
The output is an agreed schema, a set of validated questions, and measured answer accuracy — instead of a demo on a prepared example.
Procedures, schemas, and documentation after implementation
Implementation is considered complete not when the assistant answers demo questions, but when it can be handed over to another team and maintained without its authors.
That is why we fix the documentation package in advance, against a checklist, and deliver it together with the system — otherwise six months later no one will remember which sources the knowledge base is assembled from or why the assistant answers the way it does.
- Integration schema — which ERP modules, master data, and registers participate in the exchange, in which direction data flows, where the failure points are, and how a failed request is replayed.
- Access policies — the assistant answers strictly within the boundaries of an employee's rights: role, department, confidentiality level. What happens when a role changes or an employee leaves is described separately.
- Knowledge update procedure — who reindexes the base when items, policies, or master data change, how often, and how quality is checked after loading.
- Technical documentation — the set of services, configuration parameters, control metrics, operation logs, and the procedure for rolling back to the previous version of the model and rules.
- Reference question set — several dozen typical queries with validated answers. It is run after every update to catch degradation before users do.
- Instructions for employees — how to phrase a query, how to verify the primary source in ERP, and what to do if the assistant answers uncertainly or there is no data.
- Responsibility matrix — who on the customer side owns the knowledge base and answer rules, who is responsible for the loop, and who receives a request when something fails.
The package ends up compact: it describes not the internals but actions — what to do when an exchange fails, master data is updated, or rights change. A set like this passes an audit and lets you change maintenance contractors without losing context.
Case: purchasing and stock forecasting in wholesale distribution
A wholesale supplier with several thousand active item records and four warehouses planned purchases in spreadsheets: an export from 1С:ERP, manual edits by an analyst, and approval with managers.
The forecast report took two working days to assemble — by the time it was ready, some data was already stale and decisions were made on the previous supply cycle.
What it was like before
The forecast was calculated as a three-month average, without a seasonal profile or demand spikes during promotions — during an upswing the purchasing system could not react in time.
For fast-moving items, 30–40 stockout cases per quarter were recorded, and about 60% of forecast lines were edited manually by the analyst, with the logic of those edits never stored anywhere: every week the reasoning started from scratch.
What we changed
We built a loop that daily pulls warehouse and order movements, builds a forecast with a horizon of up to 12 weeks accounting for seasonality, lead times, and pack multiples, and recalculates safety stock for each item itself.
The assistant does not replace the buyer: it shows a recommendation, highlights the deviation from the previous cycle, and asks for justification when a line is edited — edits become labels for model retraining.
What it became
Report preparation time dropped from two days to 20–30 minutes: export, calculation, and summary run in a single pass.
The share of manual edits in the forecast fell from 60% to 12–15%, stockout cases for fast-moving items fell to 4–6 per quarter, warehouse turnover accelerated by 9 days, and excess stock stopped growing.
Two quarters later, buyers treat the assistant's recommendations as the baseline scenario rather than as a check on someone else's calculation.
What to do if the accounting system is already heavily customized
A customized accounting system does not block assistant implementation, but it changes the connection method. First we inventory the changes: which objects are overridden, where the logic lives in extensions, and where a modification was made directly in the code.
We connect the assistant to a layer that does not depend on a specific customization and will survive the next release.
Non-standard master data is the main source of analytics errors: a counterparty is entered as three records, items have their own groups, warehouses have their own statuses.
On a set like this the assistant errs confidently, so before training we build a mapping map — a canonical dimension, rules for merging duplicates, and the fate of records with no owner. The map is agreed before the first forecast, not after.
There is often no clean test copy of the loop: the production database has changed dozens of times and no anonymized snapshot was ever made.
We take a copy, strip out personal data, record the 1С configuration version and the set of extensions — and get a loop with reproducible results. If even that is unavailable, the assistant starts in read-only mode on production data.
Backward compatibility matters more than speed: a platform or industry-solution update must not break the assistant. We keep the integration on documented extension points and vendor APIs rather than on parsing internal identifiers.
A regression test set confirms that after an update master data is read, forecasts are recalculated, and the export reconciles with the registers.
Migration without downtime runs through a parallel loop: first the assistant reads a copy, we reconcile the numbers with reports, then we enable prompts on the production database. We switch the operating mode on a schedule and keep a rollback point for 24 hours.
Common technical concerns before starting work
Before work begins, the same questions come up: how the assistant gets access to the accounting system, what it does when it is unsure of an answer, and who is responsible for it after launch. Below are short, to-the-point answers.
How are rights separated and data protected?
The assistant has no account with elevated rights — queries go into the system under the role of a specific employee. If a warehouse or the HR block is closed to them, the assistant will not show that data: the restriction sits at the source, not in the interface. Personal data is masked before processing, and requests are logged with a link to the user.
What happens if the model makes a mistake?
The assistant does not post entries or change data — it reads and suggests. An answer with low confidence is flagged and sent to a human for confirmation, and numeric values come with a link to the source: document, register, period.
The number can be verified in one click — that is the protection against a plausible but incorrect statement.
Will the model need to be retrained on our data?
Weights are usually not retrained: the main contribution comes from retrieval over your documents and a description of the accounting structure.
The glossary of terms, item synonyms, and metrics reference are extended during operation — accuracy grows without rebuilding the model and without stopping work.
What does post-launch support include?
We monitor the share of answers with a confirmed source, response time, and the list of unanswered questions — the latter reveals gaps in master data and data.
We fix the glossary update procedure and incident handling at the start so the assistant does not degrade as the accounting system changes.
Let's discuss your task and come back with a plan and an estimate
To make the conversation concrete, you do not need a finished technical specification — a description of your loops and pain scenarios is enough.
We review them together with your IT department and come back with a plan: where an AI assistant delivers value immediately and where data quality work is needed first.
Send whatever you already have at hand:
- a list of scenarios that eat up time: stock reconciliation, demand forecast assembly, explanations for plan-vs-actual variances;
- a data map: which accounting systems and master data are involved, who owns the master data, and whether exports to a warehouse exist;
- access constraints: which roles work with the assistant, which fields are closed, and anonymization requirements;
- examples of reference answers — 5-10 real questions and the correct answers to them; they become the basis of the validation set;
- integration points: the interfaces the assistant connects to for reading and, if needed, for writing;
- the documentation package your IT department needs for acceptance and ongoing maintenance.
The first step is a pilot run on 2-3 scenarios and a limited data set, isolated from the production system.
Before the start we fix acceptance criteria in measurable terms: the share of correct answers on the test set, response time, and the share of queries resolved without handing off to a human.
If the targets are met, we expand the set of scenarios and hand over the documentation: data flow schemas, the procedure for updating models and rules, and support instructions.
If not, the loop is rolled back with no impact on accounting, and you receive an analysis of the causes.
