Why an AI financial analyst produces forecasts nobody trusts
A typical picture: an AI financial analyst is trained on an extract that was assembled "for reporting," not for forecasting. Revenue in the accounting system is allocated by documents, in the plan — by contracts, in sales — by deals in the sales pipeline.
The model averages all of this and produces a revenue forecast that diverges from actuals by tens of percent by the end of the first month.
The root cause is the quality of accounting data. Duplicate counterparties, reversing entries, period closing delayed by weeks, manual edits in 1C and the financier's spreadsheets do not pass any input validation. The model memorizes each such gap as a pattern and then reproduces it in the forecast.
Then accumulation takes over: the gap between plan and actuals is explained by "one-off factors," the figure is adjusted manually before every budget defense — and trust in the forecast falls to zero.
Management returns to manual summaries in spreadsheets, and the financial analyst spends several days a month assembling them instead of analyzing the causes of deviations.
This is not a weakness of the model, but the absence of a data circuit around it: consolidation of sources, reconciliation rules, input quality control, and a clear procedure for explaining discrepancies.
We break down how this is closed — from a unified accounting data layer to validating the forecast on historical periods.
Measurable effects: speed, accuracy, mitigated risks
We measure the effect before launch: on historical data, we run the same summaries and forecasts that are collected manually today, and compare metrics one to one. What exactly we fix in acceptance:
- Reporting preparation time. The management summary no longer takes 2–3 days to assemble: an overnight recalculation pulls data from accounting systems (including 1C) and the data warehouse, reconciles it, and calculates deviations — by morning the mart is ready by responsibility center.
- Forecast accuracy. We validate the model on closed periods: for key line items, the error over a 3–6 month horizon is lower than that of spreadsheet-based planning, and not just in words but on a holdout sample.
- Early detection of deviations. Thresholds for line items and ratios are set together with the finance team — 80–90% of threshold breaches surface before period close, not at the moment the report is signed.
- Cash gap. The payment calendar is built 4–8 weeks ahead in several scenarios: the threat of a gap is visible 2–3 weeks in advance, when it can still be closed through negotiations with a supplier or by shifting a payment.
- Expense control and a mitigated class of failures. Entries are tagged automatically by line item and contract; the share of transactions without manual allocation reaches 90%+. The discrepancy "the figure in the report does not reconcile with the source" also goes away: a unified mart and calculation log unwind any amount down to the entry.
We record the metrics in the acceptance criteria before work starts — if they do not match, the work is not accepted.
Implementation approaches: ready-made model, custom, hybrid
The implementation mode is chosen not by "level of technological sophistication" but by data maturity: how many labeled examples of financial statement analysis exist, who is responsible for labeling, and how strict the isolation requirements are. This determines where the boundary lies between the ready-made model and your domain logic.
| Option | When it fits | Limitations of the approach |
|---|---|---|
| Ready-made model by subscription | Fast start, standard reporting forms, few historical examples | Does not know your line item nomenclature, reference data, and consolidation rules; scenario fine-tuning is limited by the vendor's settings |
| Fine-tuning on your own data | There are 3–5 closed periods with reconciled entries and an owner for labeling | Requires a dataset versioning policy: without it, the model degrades when the accounting policy changes |
| Hybrid scheme | Reporting is non-standard, but part of the operations is typical | Support is more complex — a request routing layer and control of answer discrepancies between circuits are needed |
The difference shows up at the stage of calculating ratios and reconciling deviations: the ready-made model responds according to general logic, the fine-tuned one — according to your methodology. The hybrid covers both cases but requires an explicit rule for which request goes where.
We keep the transition between options open: configuration and reference data are transferable, so you can start with a ready-made model and later fine-tune it on accumulated analyses.
How we implement: from data audit to handover
Implementing an analyst is not installing a ready-made product, but a chain of engineering steps where each next one relies on the result of the previous one. We do not start calculating metrics until we understand where the data comes from and how much it can be trusted.
- Data audit. We compile a list of sources: extracts from accounting systems, manual-entry spreadsheets, external files. We check update frequency, duplicates, gaps, and discrepancies between systems — the output is a source map with an assessment of suitability for calculation.
- Metric schema. We agree on definitions: what we count as revenue, how we interpret outflow, which periods we compare. We record formulas and recalculation rules in writing — otherwise the discrepancy between analytics and accounting surfaces during report review, not in the calculation.
- Calculation setup. We implement reconciliation, aggregation by period, and allocation by division and counterparty. The key property of the result is reproducibility: the same input always produces the same figure, and every value is traceable down to the source entry.
- Historical validation. We run the calculation on already closed periods and reconcile it with actual reports. This step typically reveals errors in the source data: the share of rows where figures do not reconcile shows the real quality of accounting before work begins.
- Pilot operation. The analyst works in parallel with the usual process; we see where it makes mistakes and how clear the explanations for the figures are. We adjust wording, deviation thresholds, and recalculation rules based on actual questions from the finance team.
- Solution handover. We hand over access, the data update policy, instructions, and an analysis of typical situations. We train the team that will work with the analyst daily — after that, the solution lives and evolves without our involvement.
What the customer's team keeps after the project
The project is closed not when the analyst produces its first report, but when your team can change the calculation logic, add a data source, or revoke access without us.
That is why we hand over not a "working service," but a set of artifacts that keep the solution alive inside the company.
- Solution documentation — layers: data ingestion, normalization, calculation circuit, explanation of results; a flow diagram and connection points for a new source.
- Metric reference — for each value: formula, source, aggregation period, owner, and behavior when data is missing; we use it to reconcile indicators with the accounting system.
- Configured calculations — line item matching rules, recalculation scenarios, and anomaly thresholds are moved into configuration: an analyst makes the change, not a developer.
- Access rules — roles for source data, aggregates, and extracts; a log of access to sensitive fields; and the revocation procedure when an employee changes.
- Update policy — how to add a metric or source, how to check data quality before publication, and how to roll back an unsuccessful calculation change.
- Self-support instructions — typical operations: period recalculation, discrepancy analysis, and response to a complaint about an indicator.
We transfer environments, access, and task schedules to your accounts so that the solution remains operational without our involvement. If you need to expand the circuit, we will return with an estimate and a plan.
Case: branch forecast stopped diverging from actuals
A network of 38 branches; the summary for each — revenue, cost of sales, deviations from plan — was assembled manually: finance staff exported spreadsheets from accounting systems, consolidated them into one file, and corrected discrepancies "by eye." Preparation took two working days, and by the time the summary reached management, some of the figures had already become outdated.
What we found during the review
It turned out that the forecast diverging from actuals was not a model problem but an input problem: branches classified the same costs differently, counterparty reference data was duplicated, and some adjustments existed only in personal files.
Because of this, the forecast did not reconcile with actuals for 4 out of 10 branches, and the share of accurate forecasts stayed around 62% — and this was considered normal.
What we changed
We consolidated branch data into a unified mart on ClickHouse, fixed reference data and classification rules, and added input quality checks: an incomplete period or an atypical cost spike stops the calculation instead of flowing into the report.
The forecast is recalculated on schedule, and the calculation version is saved — you can see what data it was built on and what changed after adjustments.
What the outcome was
The summary is prepared in 20 minutes instead of two days and updates without manual exports. The share of accurate forecasts rose from 62% to 91%, and a discrepancy with actuals remained for one branch out of ten — and the reason is immediately visible: late data transfer. The finance function shifted from rebuilding spreadsheets to analyzing deviations.
How a digital analyst differs from reports in the accounting system
Reporting in the accounting system answers the question "what has already happened": registers reconcile, entries are in place, the balance is closed.
But the data breakdown in it is predetermined by the chart of accounts and reference data — to the question "why did margin decline specifically in this area," it gives a figure without explanation.
The digital analyst is built on top of the same circuit but works with analysis of the causes of deviations.
It compares plan and actuals line by line, decomposes the discrepancy into factors — volume, price, exchange rate, cost structure — and shows what share of the deviation is attributable to each.
Then scenario calculation kicks in: the analyst accepts a set of assumptions — demand shift, growth in purchase prices, exchange rate dynamics — and recalculates the model without manually exporting data into spreadsheets.
The source here is the same as in the accounting system, so no discrepancies arise between circuits.
The difference between the approaches is one thing: a report records the result, while the analyst explains it and calculates scenarios for how events may develop.
Every number in the model is traceable to an entry or source document, so the conclusion can be defended before audit and management.
There is also a limitation: if the accounting system lacks analytical attributes — responsibility centers, line items, projects — the digital analyst will not create them out of thin air.
Then the work begins with a revision of the chart of accounts and reference data, and only after that is the model built.
Technical doubts before starting: we answer directly
Doubts before starting are usually the same: will the analyst work with real data, will accounting have to be rebuilt, who is responsible for failures. We address them point by point — without promising full autonomy, which no team can provide.
How accurate are the calculations on our data if some entries are incomplete?
We check accuracy not on a demo dataset but on your extract for closed periods: we assemble a reference sample of transactions and use it to verify the analyst's conclusions for each category.
Where data is insufficient — no allocation by counterparty or there are manual adjustments — the conclusion is marked as incomplete rather than filled in with a guess.
Our financial accounting is in several systems — is that a problem?
We start by matching reference data: counterparties, line items, and periods are brought to a unified form, and methodology discrepancies are described by rules rather than left to the model's discretion. A new source does not rewrite the logic — a matching rule is added to it.
Can we launch in stages without stopping period close?
Yes: the analyst calculates the same indicators in parallel with the current process, the finance function reconciles the results, and only after they match does it enter the policy.
We start with one circuit — for example, revenue and cash — then connect reporting and forecasting. A rollback at any stage restores the previous process without data loss.
What access is needed to financial data, and what is your area of responsibility?
Access is minimally sufficient: read from accounting systems or extracts, usually in anonymized form — without personal data or payment details. Access is logged; we agree on the scheme with your security service before work starts.
We are responsible for the model, matching rules, calculation reproducibility, and documentation; your side is responsible for the completeness of source accounting.
Let's discuss the task and we'll return with an estimate and work plan
To make the project estimate rely on facts rather than assumptions, we need source data for your circuit. Describe the task in free form: what an AI financial analyst should do, what decisions it supports, and what result you consider correct. In response, we will return with an estimate, stages, and a work plan.
You do not need to prepare anything special — we take what is already in use: extracts, policies, examples of reporting. We will ask clarifying questions ourselves.
- What sources already exist — accounting system, bank statements, registers, spreadsheets — in what form and how often they are updated.
- What reports and calculations the analyst should produce now, and what in them is difficult or takes the most time.
- An anonymized sample of data for several periods, to check completeness and quality before the start.
- How the current process is organized: who prepares reporting, where discrepancies and errors most often appear.
- Requirements for the circuit: closed server or external services, rules for access, storage, and logging.
- Who on the customer side accepts the result and by what criteria they consider the calculations correct.
This is enough to estimate the effort, propose a starting order, and fix the scope of stages. Describe the task — we will return with an estimate and work plan.
