I build Intrinsiqq, which computes quality scores, valuations and ten years of financials for around 7,800 listed companies. Every number comes from companies' own filings with the SEC.

People assume the hard part was the finance. It was not. The hard part was that financial filing data is free, structured, machine readable, and constantly, quietly wrong in ways that do not announce themselves.

I want to describe the shape of that problem, because I have not seen it written down anywhere and I would have saved months if someone had.

Why build on filings at all

Most finance sites buy aggregated data from a vendor. I went to the source instead, because filings are free, public, legally usable, and they contain what a company actually told a regulator rather than a vendor's cleaned-up interpretation. It means the numbers on my site reconcile with the annual report, and it is the reason the product can be free at all. I wrote up how the pipeline fits together if you want the overview.

That decision was right. It was also much more expensive than I budgeted for.

The failure mode is silence

This is the thing I want to convey above everything else.

When you consume a normal API and something is wrong, it fails. You get a 500, a schema mismatch, a null where you expected a number, and your monitoring tells you. Filing data does not behave like that. It hands you a number of the correct type, in the correct currency, in the correct shape, sitting in the correct field. And it is wrong.

Nothing throws. Nothing logs. Your tests pass. The page renders. A revenue figure eight billion dollars short of reality looks exactly as convincing as a correct one, because there is no context in which it looks odd unless you already know what the answer should be.

So the entire discipline of the project turned out to be: how do you detect being wrong when nothing tells you that you are?

Fiscal calendars do not agree with anything

Roughly every assumption a developer brings to a date field is wrong here.

Companies do not share a financial year. Some end in December, plenty do not. The year label attached to a filing describes the document, not the numbers inside it, and a single annual report carries several prior years of comparative figures all wearing the same label. Group by the obvious field and you quietly blend three different years into one.

Then there are markers that look like they identify a quarter and actually identify a calendar period, which coincide for some companies and are months apart for others. Two of the largest companies in the world fall on the wrong side of that distinction. If your logic assumes those are the same thing, you misclassify a large fraction of your history and every derived figure inherits it.

Quarters are partly a fiction

Companies file three quarterly reports and then an annual one. There is no fourth quarterly report. The fourth quarter exists only as the difference between the year and the three quarters you have, so anything quarterly has to be reconstructed rather than read.

Reconstruction is where things get interesting, because it is arithmetic on top of data you have already possibly misclassified. Different statements in the same filing also cover different spans: some figures are for the three months just ended, others are cumulative from the start of the year. They sit side by side, look identical structurally, and mean different things. Treat them uniformly and your cash flow figures are inflated by a factor that grows as the year goes on.

There is also a whole category of bugs where a reconstruction runs against incomplete inputs and produces something plausible instead of nothing. Those are the worst ones. A missing value you can catch. A confidently derived wrong value hides.

The same number appears many times and the copies disagree

Any given figure shows up in several filings across several years, and the versions differ, for legitimate reasons. Companies sell divisions and restate history so the comparison is like for like. Companies split their stock and restate per-share figures onto the new basis.

Which means for every duplicate you have to decide which version you want, and the answer is not the same for all kinds of figures. Some of them you want as originally reported. Some of them you want as most recently restated. Pick one rule and apply it across the board, which is the obvious thing to do, and you will be wrong about a large slice of your data while being right about the rest, which makes it very hard to notice.

Every industry breaks your assumptions

I built the first version around a normal operating company: revenue, costs, margins, cash flow, debt.

Then I pointed it at a bank, and there was no revenue, because a bank's revenue is interest and it does not live where revenue lives. Debt is not a risk signal for a bank, it is the raw material. For a property company, the largest expense is a non-cash accounting entry, so the headline profit figure is close to meaningless and the cash figure is what matters. An insurer works differently again.

The lesson generalised well past parsing. A single scoring framework applied to every industry produces confident nonsense, so we route several sectors to their own scorecards. I wrote about how we picked the metrics and why some industries get different rules.

Broad categories sweep in things you did not want

My favourite bug, in hindsight.

Where a specific figure was missing, I fell back to a broader category, which felt like sensible defensive design. Then a payroll processing company showed several billion dollars of investments it did not own, because the broad category included money the company merely holds on behalf of its clients. The correct figure was zero. Nothing looked wrong. It was a perfectly reasonable-looking balance sheet for a company with a five-billion-dollar hole in it.

The general lesson: a fallback that is broader than the thing you are looking for is not a safety net, it is a slow leak. Better to show nothing than to show something adjacent.

What I would do differently

Build the verification harness before the parser. Almost every problem above was found by a person looking at a page and thinking "that cannot be right", not by a test. The only real defence against silent wrongness is checking computed output against totals the filing already states. Does the balance sheet balance? Do the parts sum to the whole? That is unglamorous and it would have caught most of this years earlier.

Treat "no data" as a legitimate answer. A lot of my early bugs came from an instinct to always produce a number. Some companies genuinely have no debt. Some figures genuinely are not reported. Guessing to avoid a blank is how you turn a gap into a lie.

Write down why, publicly. We publish a methodology page covering how each figure is computed, and a process for correcting errors when someone finds one. Partly that is a trust obligation for anything financial. Mostly it is that being forced to explain a calculation in plain language is what exposed several of these bugs, because a rule you cannot justify out loud is usually wrong.

If you want to see the output, Microsoft's financials are built from filings through everything described here.

If you are working on something similar and hitting a category of weirdness I have not mentioned, I would genuinely like to hear about it. I am fairly sure I have not found the last one.