Why AI Excel analysis breaks on real exports
The assistant confidently passes a demo on a three-column table — and falls apart on the first real-world export. It's not the model: the demo file is clean, while the real one has passed through a dozen hands.
Someone merged cells for a nice header, someone added a row manually, someone left a hidden sheet with an old structure.
Failures repeat in one scenario. Merged cells shift boundaries: the value sits in the first column of the range, neighboring ones are empty, and the aggregate is calculated over empty cells.
Hidden sheets and active filters cause double counting — rows a person cannot see end up in the selection. Duplicates without a natural key turn counting unique customers into counting all transactions.
Formats do no less damage. Dates in one file are ISO, in another — DD.MM.YYYY, in a third — text. Numbers with thousands separators and decimal comma, after saving to CSV, are read as text, and the column sum gives zero.
And an export in cp1251 without an encoding marker turns Russian headers into garbage: matching columns by name fails silently.
It is precisely bringing data to machine-readable form that consumes hours of manual data analysis, not the conclusion itself.
Therefore, before feeding it to the model, we build a sheet schema: where the header row is, which ranges are merged, where a cell contains a formula instead of a value. Then comes typing — dates and numbers to a unified form, duplicates are flagged rather than silently deleted.
This way errors in tables stop being a surprise: Excel export parsing follows verifiable rules, not the luck of a demo file.
What the assistant provides: speed, accuracy, reproducibility of parsing
The first effect is visible in preparing a summary. Previously, a manager waited for a report until the end of the day: an analyst consolidated exports from several systems, manually pulled formulas, and double-checked totals.
The assistant accepts the entire file and returns a ready summary in minutes — the share of manual operations drops from most steps to checking the result.
Automating table parsing addresses the main cause of manual work — inconsistency in input data. Merged cells, headers not in the first row, different date formats, separators, and encodings are processed by the same normalization rules.
A new export of the same type does not need to be prepared by hand: the structure is recognized, service rows are discarded, and columns fall into place.
Data accuracy rests on checks, not on the performer's carefulness. Duplicates, gaps, and outliers are marked at input; questionable rows do not silently fall out of the calculation but go into a separate list.
The share of discrepancies between the summary and source files decreases because every figure in the report references the rows from which it was obtained.
Reproducibility of calculations is something manual assembly cannot provide in principle. Processing rules and calculation order are fixed, so the same file twice gives the same result, and a discrepancy can be explained rather than attributed to human error. When rules change, it is visible exactly what changed in the totals.
Connection methods: files, accounting system, scheduled exchange
The connection method determines how fresh the data the assistant sees is and how much manual work remains for the analyst.
Starting with a full integration is not necessary: one-time file uploads give the first result on real data, while regular exchange with the accounting loop is connected later, when the structure of reports is already clear.
We support four modes — they differ in update frequency, access requirements, and what will need to be maintained on your side.
| Option | When it fits | Limitations |
|---|---|---|
| File upload | Parsing several exports, testing hypotheses, one-time reports | Data is current as of the moment of sending; history does not accumulate without repeated uploads |
| Integration with accounting system | Fresh balances, sales, and register movements are needed for each request | A read-only account is required and coordination with system administrators |
| Scheduled exchange | Regular analytics on a schedule: exports are generated and placed in an agreed location | Delay between export generation and parsing; if the schedule fails, data lags |
| Closed loop | Data must not leave your infrastructure | Deployment and updates on your side, support according to an agreed schedule |
The modes are combined: reference data and history are conveniently pulled via scheduled exchange, while operational questions are closed by parsing individual files. At the start, one option is enough — the scheme can be expanded without reworking already parsed reports.
Implementation stages: from table audit to handover of regulations
The order of work is the same for any source: first we understand what actually lies in the files, then we build parsing and rules, and only then we hand the system over to operation.
The reason is simple — a typical export almost never matches how the customer describes it: the header is not in the first row, one indicator is spread across three columns, dates come as text in two formats, and some rows are intermediate totals.
- Data audit. We collect all exports, record sheet structure, merged cells, hidden rows, mixed types in a column, encodings, and separators. The output is a list of sources, their owners, and update frequency.
- Parsing schema. We describe target fields and relationships between sheets, rules for finding headers, and discarding service rows. We get a mapping "source column → model field", which is then used to build parsing.
- Rule setup. Normalization of dates, numbers, and counterparty names, synonym dictionaries, deduplication, thresholds at which a value is marked suspicious. We keep rules separate from parsing logic — they can be edited without rewriting the system.
- Data quality check. A run on historical exports and reconciliation of totals with what the analyst calculates manually. We look not only at matching sums but also at the share of discarded rows with a reason for each.
- Trial run on live questions. Employees formulate questions themselves; we calculate the share of answers accepted without clarification. Usually after two or three dictionary edits, this share grows noticeably.
- Handover of regulations. Instructions for updating exports, description of rules and their change log, procedure for escalating parsing errors. We train one or two employees so that dictionaries and thresholds are subsequently edited within the customer's team.
What we hand over: schemas, parsing rules, documentation
An assistant for Excel and CSV analysis must not remain a black box: if parsing rules live only in correspondence with the developer, any new export from the accounting system breaks the report.
Therefore, along with the working service, the customer receives a set of artifacts by which their team can see for themselves how the system reads files, what it calculates, and how to change it.
- Data flow schema: where the file comes from, at which step it is normalized, what ends up in the final table — with control points for reconciliation.
- Parsing rules: definition of the header row, column types, date and number formats, behavior with merged cells, empty rows, duplicates, and concatenated sheets.
- Reference books and classifiers: nomenclature, departments, items, synonym lists — with the procedure for replenishment and a person responsible for keeping them up to date.
- Catalog of typical queries to the assistant: formulations it parses correctly, and examples where a clarified statement is needed.
- User instructions: how to upload an export, how to check the result, what to do if there is a discrepancy with the source file.
- Support regulations: who and within what time frames updates rules when export structure changes, how requests and edits are recorded.
- Quality check log: a set of real files on which parsing accuracy has been confirmed, and a list of known limitations.
Documentation is written for your exports, not from a template, and remains with you in editable form. The team makes changes to reporting according to the described rules independently, and we step in when the processing logic itself changes.
Case: parsing warehouse exports in a closed accounting loop
Before: two days of manual consolidation
The customer's accounting loop is closed: exports from 1C were placed in a network folder, then manually consolidated in Excel.
Every month — more than forty CSV files with different column structures: SKU came sometimes as text, sometimes as a number, dates — in three formats, warehouse names were written differently in different branches.
Consolidating one summary took two working days, and in every second build negative balances or doubled batches surfaced — they were found after the report had already gone further down the chain.
After: summary in 40 minutes
The assistant was placed inside the loop, without external calls: data does not leave the customer's network. Column matching was described by a nomenclature reference book and type normalization rules, not a rigid template, so a new export format does not break parsing.
Checks were moved before report assembly: negative balances, duplicate batches, discrepancies between the warehouse export and primary documents, anomalous quantity spikes.
- Manual operations in the cycle — instead of 14, 3 remain: uploading files, confirming matching, reviewing the discrepancy list.
- Time to consolidate the monthly summary — from two working days to 40 minutes.
- Errors of the "negative balance" and "duplicate batch" class in the finished report — zero: they are cut off before assembly, not after.
- The share of reports that had to be rebuilt decreased from about half to isolated cases.
The assistant answers questions about data in Russian ("how many items left warehouse No. 4 for the period", "show discrepancies for the supplier"), so the summary does not need to be built anew each time.
The matching schema and check rules are stored as configuration: when the export format changes, one reference book is edited, not the parsing logic.
What to do if data is already maintained in Excel tables?
There is no need to abandon files: AI analysis of Excel tables is placed on top of current exports, not instead of them. The first step is a data contract: we fix which sheets and columns are read, which value types are expected, what to do with empty rows. After that, employees continue to edit the file by hand, while parsing remains predictable.
Manual edits are the main source of discrepancies: a column was renamed, a row was inserted, text got into a numeric field, a duplicate appeared.
Therefore, the schema is supplemented with checks — the assistant does not fail on such a row but flags it and collects it into a data quality report so the edit can be made consciously.
A hybrid loop is built as follows: the parsing result is written to a separate sheet or internal storage, and the source export remains untouched.
Excel exports from accounting systems are picked up on a schedule, and re-parsing an already processed file does not create duplicates — rows are matched by a stable attribute.
Gradual implementation starts with one regular report where the cost of an error is minimal. Rules are tested on historical slices and compared with what was previously calculated manually; when discrepancies are reconciled, the neighboring export is connected.
At the same time, work does not stop: files live their own life, while the assistant runs alongside as a second loop — parses new batches, answers questions with figures, and shows which rows require manual review.
Technical doubts: data quality, loop, support
Dirty data is the norm, not the exception: merged columns, different date formats, duplicate rows, empty cells, numbers recorded as text.
The first step is profiling: for each column we calculate the share of gaps, types, value frequency, and outliers, and a quality report comes before the first calculations.
We fix cleaning rules in writing — what we consider a duplicate, how we parse dates — relying on data quality management practice DAMA-DMBOK.
The second doubt is the loop. The assistant works without external access: file parsing, the model, and rules are hosted on your server or in an isolated segment without internet access.
Data does not leave the perimeter, and export is limited by a role model — the analyst works with depersonalized samples.
Each department sends a file in its own format — what to do?
We collect a source map and bring them to one schema at input: required columns, mapping reference books, date parsing rules. A new format is added as a separate profile — calculation logic is not rewritten.
Who is responsible for rules after launch?
We maintain a register of processing rules and a change log with the person responsible for approval. Edits in reference books undergo review and a test run on a reference set — the assistant does not diverge from the accounting system after export updates.
Support is part of the work, not a separate service: new sources, rule changes, and incident resolution are handled according to regulations, so the assistant does not depend on one person in the team.Let's discuss the task: we will return with an estimate, plan, and scope of work
For an initial review, it is enough to send 2-3 real files with their structure preserved and a list of questions currently asked of the data.
Full depersonalization of exports is not needed — form matters more to us: headers, merged cells, several sheets, column types, and how dates and amounts are recorded.
- 2-3 Excel or CSV files as they are, without manual cleaning — structure matters more than content;
- 5-10 typical questions in Russian that you ask of this data;
- how the answer is assembled today: manually, with a pivot table, by export from the accounting system;
- what formats are needed on output — a table, a brief note, a chat message;
- where the files are located, who has access to them, and whether there are restrictions on processing outside your loop;
- which columns are considered reference and which are filled by manual input.
Then we discuss the task with an engineer: we analyze the file structure, clarify question formulations, and agree on the boundaries of the pilot area. This way the project estimate relies on your data, not on average assumptions.
As a result, we return with a work plan and scope of work: stages, timelines, boundaries of the pilot area, what we do and what will be required from your side. Describe the task in free form — we will return with an estimate and plan.
