Can AI Actually Read a Balance Sheet? Where LLMs Break on Financial Statements

Yes, up to a point, and that point matters more than the headline suggests. A large language model can read the words on a balance sheet fluently and summarise them well, but the moment you ask it to trust the numbers, it starts to fail in specific, repeatable ways.

The failures are not random. They cluster around the exact places where a financial statement stops being prose and becomes structured accounting. That distinction is the whole story, so it is worth being precise about it.

What models are genuinely good at

Give a language model the notes to the accounts and it will do useful work. It can summarise a management commentary, flag the paragraph where a company discusses a contingent liability, translate accounting jargon into plain sentences, and match the phrasing in one filing against the phrasing in another. These are language tasks, and language is what these systems are built for.

They are also strong at pattern recognition across text. Ask which filings mention a change in depreciation policy, and a capable model will find them. This is real value, and none of what follows takes it away.

The trouble begins when the task shifts from reading about the numbers to reading the numbers themselves.

A balance sheet is not prose

A financial statement looks like a table of text, but underneath it is a system bound by accounting identities. Assets equal liabilities plus equity. The cash flow statement reconciles to the movement in cash on the balance sheet. Subtotals are the sum of their parts, not independent figures. These are not stylistic conventions. They are constraints that must hold, and a correct reading is one that respects them.

A model that treats the statement as text has no built-in reason to enforce any of this. It predicts plausible tokens. Most of the time the plausible answer is also the correct one, which is exactly what makes the failures dangerous: they are rare enough to trust and wrong enough to hurt.

A model reading a statement as prose will be confidently wrong in precisely the places where being wrong costs the most.

Here is where it breaks, concretely.

Reporting units and the 100x error

Indian filings do not agree on units. Some report in absolute rupees, some in thousands, many in lakh or crore. The label sits in a header, a footnote, or the column heading, often far from the number it governs. A model that grabs the figure without binding it to its unit can read 45,000 (in crore) as 45,000 (in rupees), or the reverse.

That is not a rounding slip. Crore is ten million. Misread the unit once and a revenue line moves by a factor of ten million, quietly, while every surrounding sentence still reads perfectly. It is the single most common way machine-read financials go wrong, and the hardest to catch by eye because the digits look right.

The same line item, different labels

Ind AS sets out principles, not a fixed dictionary. Two companies reporting the identical economic item can name it differently. “Finance costs” in one filing is “interest expense” in another. “Revenue from operations” may or may not be shown net of excise or other levies, depending on the filer and the period. A model matching on labels will either miss the item or map two different things onto the same slot.

Subtotals mistaken for line items

Statements are full of subtotals: total current assets, total equity, profit before tax. A reader who does not know the structure can pick up a subtotal and treat it as a component, then add it back in alongside its own constituents. The number double counts, and nothing in the surrounding text signals the mistake.

Consolidated versus standalone

Most listed groups file both a standalone statement (the parent alone) and a consolidated one (the parent plus subsidiaries). The two sets of numbers are both correct and often very different. Mix a consolidated revenue with a standalone debt figure and you have a ratio that describes no real entity. A text reader has no reason to keep the two worlds apart.

Associates and minority interest

Consolidation is not simple addition. Subsidiaries are fully consolidated, then the share that does not belong to the parent is stripped out as minority interest (non-controlling interest). Associates are brought in by the equity method, a single line rather than a full roll-up. Profit attributable to owners is not the same as total profit, and earnings per share is built on the former. A model that does not model these mechanics will confuse “profit for the year” with “profit attributable to owners” and get per-share figures wrong.

Restatements that change the past

A number you recorded last year can change. Companies restate prior periods for errors, accounting policy changes, or reclassifications, and the restated figure appears in the later filing next to the current year. If your reading treats the first version as permanent truth, your history is now inconsistent with the company’s own updated accounts.

Common failure modes at a glance

Failure	What goes wrong	Why prose reading misses it
Units (100x error)	Absolute rupees read as crore, or vice versa	Unit label lives in a header or footnote, not beside the number
Inconsistent labels	Same item named differently across filers	Matching on words, not on the underlying concept
Subtotals as line items	Totals added alongside their own components	Structure is implicit; text gives no warning
Consolidated vs standalone	Numbers from two different reporting entities mixed	Both look valid in isolation
Associates and minority interest	Total profit confused with profit to owners	Consolidation mechanics are not linguistic
Restatements	Old figure kept after the company revised it	Later filing quietly supersedes the earlier one

None of these require an exotic edge case. They show up in ordinary annual reports, across ordinary companies, every reporting season.

What makes machine reading reliable

The fix is not a cleverer prompt. It is treating the statement as what it is: structured data governed by rules. Three things do most of the work.

Normalisation. Every number is bound to its unit, currency, period, and reporting basis (consolidated or standalone) before anything else happens. A figure without its unit is not yet a number, it is a string. Once normalised, the crore-versus-rupee ambiguity is resolved once, at the source, rather than re-guessed each time the value is used.

Structure. Line items are mapped to a canonical set of concepts, so “finance costs” and “interest expense” land in the same place regardless of the words the filer chose. Subtotals are marked as subtotals. The hierarchy of the statement is preserved rather than flattened into a list of numbers that all look alike.

Checking against identities and the source. This is the part text alone cannot give you. Because accounting is closed under its own rules, you can test a reading against them. Does the balance sheet balance? Do the components sum to the stated subtotal? Does the cash flow reconcile? When a check fails, the reading is wrong, full stop, and you go back to the source filing rather than accept a plausible-looking number. In the Indian context, the machine-readable XBRL alongside the Ind AS statements gives a second, tagged view of the same figures, which is precisely the kind of independent anchor a language model does not have on its own.

This is the difference between a system that reads financial statements and one that merely reads about them. The language model is still useful inside such a system, for the summarising and matching it does well, but the numbers are governed by structure and identities, not by fluent prediction. It is the approach we take at Altys Labs, and it is less a trick than a discipline.

The practical takeaway

If you are using a general model to pull figures out of filings, assume it will be right most of the time and wrong in ways that are expensive. That combination is the trap.

• Never accept a number without its unit, its period, and its basis (consolidated or standalone). The 100x error hides here.
• Do not trust label matching. The same concept wears different names across filers.
• Reconcile what you extract against the accounting identities. If the sheet does not balance, the reading is wrong, no matter how confident the prose around it sounds.
• Treat prior-period numbers as revisable. A restatement can move history.
• Keep the source filing (and, for Indian companies, the XBRL) as the arbiter. When a check fails, the filing wins, not the model.

Language models are a genuine advance for working with financial text. They are not, on their own, a reader of financial statements. Knowing exactly where the line falls is what separates a useful tool from a confident liability.