Structuring Decades of Filings So an AI Can Actually Use Them

You cannot hand a language model a folder of twenty years of annual reports and expect a reliable answer, because those filings are not a clean dataset. They are decades of slightly different labels, formats, and accounting conventions stacked on top of each other, and much of the older history has since been quietly rewritten. Before any model can reason over that pile, someone has to impose structure on it and preserve what was true on each original filing date. The problem itself is what matters here, not any one way of solving it.

The temptation is understandable. Modern models read documents well. So why not point one at the whole archive and ask questions? The reason is that the archive only looks uniform. Underneath, it is heterogeneous in ways that matter precisely where research matters, and the model has no way to see the seams.

The same idea, worded a dozen ways

Start with the most basic problem: labels do not agree. Two companies in the same industry can report the same economic concept under different names. One calls a line “finance costs”, another “interest expense”, a third folds part of it into “other expenses”. Depreciation and amortisation might be one line or two. “Revenue from operations” in one filer maps to “net sales” or “total income” in another, and the difference is not cosmetic, because one number may include other income and the other may not.

Now stretch that across time. A single company changes its own labels over the years as reporting standards evolve and as its business grows new segments. A filing from a decade ago and a filing from last quarter can describe the same reality with different words, different groupings, and different levels of detail.

A keyword search cannot bridge this, and neither can a model reading one document at a time. If the question is about interest cost and this year’s filing happens to call it “borrowing costs”, plain retrieval that matched on the phrase “finance costs” will miss it entirely. This is a cousin of the problem covered in why RAG alone fails for equity research: retrieval finds strings that look similar, not concepts that are the same. Mapping every one of those variant labels to a single, consistent meaning is unglamorous work, and it is the work that has to happen before a model can compare anything to anything.

Formats change, and so do the boundaries

Labels are only the surface. The shape of the disclosure changes too. Companies redefine their reporting segments, merge two into one, or split one into three, and when they do, the historical comparison breaks unless someone reconciles the old boundaries to the new. A margin that looks like it collapsed may simply be the same business reported inside a differently drawn segment.

Then there are the structural events. A demerger carves a division out into a separate listed entity. A discontinued operation is stripped from the continuing numbers. An acquisition folds a new business in. Each of these changes what the reported totals even mean, and none of them announce themselves in a way a model reading raw text would reliably catch.

A number is only comparable to another number if you know that both were measured the same way. Most of the effort in structuring filings is establishing exactly that, and it is invisible in the final answer.

The format also changes in dull, mechanical ways that still cause damage. Units shift between crore and lakh. A statement is presented in a new order. A note that used to sit in one place moves to another. None of this is intellectually hard, but all of it has to be handled, because a model that reads a value under the wrong unit will be wrong by a factor of a hundred and sound completely confident doing it.

History is not what it looks like today

Here is the part that surprises people most. The history you can read today is not always the history that was knowable at the time. When a company reports a quarter, it usually restates the prior-year comparable alongside it, so the two periods are shown on a like-for-like basis. That restatement can reflect an accounting policy change, a demerger, a discontinued operation, or a segment redefinition. The prior year gets presented again, adjusted, as if it had always been reported that way.

This is entirely legitimate. It is also a trap for anyone building software on top of filings. If your only view of the past is the latest restated version, you are looking at a version of history that was edited after the fact. The numbers a decision-maker actually saw on the original filing date may have been different.

That distinction is the heart of point-in-time correctness, which we cover more fully in why point-in-time data matters. Structuring decades of filings is not just about tidying labels. It is about preserving, for every figure, what was reported when, so you can reconstruct the world as it looked on any past date rather than only as it looks now.

The reason this is not a pedantic concern shows up the moment anyone tests an idea against history. Suppose you want to check whether a certain signal in the numbers tended to precede a good or bad outcome. If you run that test on data that has been silently restated, you are letting the model see corrections that no one could have known at the time. The result flatters itself. This is a specific form of the mistake explained in what is lookahead bias: using information in a test that would not have been available when the decision was made. A structure that does not track vintages cannot protect against it, because it has thrown away the very thing you need, which is the original as-reported version.

Why raw retrieval over the pile fails

Put the three problems together and the reason a naive approach breaks becomes clear. Drifting labels mean the model retrieves the wrong line or misses the right one. Changing formats and boundaries mean the numbers it does retrieve may not be comparable across the years it is comparing. Restatements mean the history it reasons over may be a rewritten version rather than what was actually filed.

A powerful model does not fix any of this. If anything, a fluent model makes it worse, because it will produce a confident, well-written answer built on top of mismatched inputs, and the polish hides the flaw. The failure is upstream of the model, in the data it was handed, which is the broader point made in data quality beats model quality. You cannot reason your way out of an input that was never lined up correctly in the first place.

What a serious approach has to respect

Without describing any particular build, the principles that any credible approach to this problem must honour are not mysterious. They fall out of the problems themselves.

The problem	What the structure must do
Labels differ across filers and years	Map variant labels to a single consistent meaning, so like is compared with like
Segments and boundaries get redefined	Reconcile old and new definitions before comparing across time
Formats and units change	Normalise so a value always carries its correct unit and context
History gets restated	Preserve the original as-reported figures alongside later revisions
Questions span many filings	Make the structure queryable across periods, not one document at a time

Notice that none of these are about the model at all. They are about the discipline applied to the data before a model ever touches it. This is the same idea that runs through building an AI that understands financial statements: a statement is structured accounting bound by rules, and treating it as loose prose throws away the structure that made it trustworthy. A long archive of statements is that problem multiplied by every filer, every year, and every restatement in between.

The unglamorous conclusion

The interesting truth about applying AI to decades of filings is that most of the hard work has nothing to do with the AI. It is in accepting that the archive is messy, that its labels drift, that its formats change, and that its history has been edited, and then doing the patient work of imposing a clean, consistent, time-aware structure before a single question is asked.

None of that shows up in the final answer. When it is done well, the answer just looks obvious, and the years of quiet reconciliation underneath it stay invisible. That is the nature of good plumbing. You only notice it when it is missing, and in this domain, missing plumbing does not announce itself with an error. It announces itself with a confident answer that happens to be wrong.