The Partial Restatement Problem: Why "Use the Latest Filing" Corrupts Financial Comps

Every public company's structured financials trace back to XBRL — eXtensible Business Reporting Language, the tagging standard the U.S. Securities and Exchange Commission (SEC) requires issuers to use when they submit a 10-K or 10-Q. A vendor, or an internal pipeline, pulls those tagged facts, maps them to standard line items, and hands you a clean quarterly trio: income statement, balance sheet, cash flow. Most of the time that's the whole story.

The part that trips up diligence workflows is what happens when a company amends a filing. A 10-K/A — an amended annual report — does not typically restate the entire financial statement. It usually fixes one thing: a misclassified expense, a corrected share count, a segment reallocation. Every other line item in that amendment is either omitted from the filing entirely or repeated unchanged, and the two cases look identical from the outside unless your pipeline is built to tell them apart.

The bug this creates

Picture the common shortcut: "when a company has filed an amendment, use the amendment as the source of truth for that period, and use the original filing for everything else." That sounds reasonable until you look at what "use the amendment" means in practice for a system that resolves whole filings rather than individual facts.

If the amendment only tags Revenue — because that's the only line item that changed — and a pipeline naively pulls "the latest filing's whole statement" for that period, one of two bad things happens. Either the amendment's sparse set of tags gets treated as the complete statement and every other line item goes missing for that period, or the pipeline falls back to blending an old filing's figures with the new one in a way nobody audited. A diligence analyst comparing revenue growth or net income margin across a cohort has no way to see that one company's numbers are now a stitched-together mix of two different filings, filed months apart, under two different accession numbers.

This is not a hypothetical edge case. Restatements are routine — reclassifications, immaterial corrections, and full-blown restatements all produce amended filings — and any pipeline that resolves data at the filing level rather than the individual-fact level is exposed to it on every cohort that includes an amender.

Resolving by fact, not by filing

LacunaIndex's SEC financial data path stores XBRL facts in an append-only table, one row per tagged fact per filing — never per statement. A 10-K/A that only touches Revenue adds exactly one new row for that concept and period; it does not touch the rows for Net Income, Total Assets, or anything else the amendment didn't re-tag. Nothing already stored is ever overwritten, so the full filing history for a given period stays intact and auditable no matter how many times a company amends it.

The resolver that reads from this table walks every stored fact for a given company, metric, and fiscal period ordered by filing date, most recent first, and — critically — picks the first non-null value it finds for that specific metric and period, independently for every line item. Revenue gets resolved by walking Revenue's own filing history; Net Income gets resolved by walking Net Income's own filing history. If the 10-K/A only restated Revenue, the resolver correctly returns the amended Revenue figure alongside the original, untouched Net Income figure — because it never conflated "the newest filing" with "the newest value for this line item." A restatement that omits an item doesn't create a gap or a mismatch; it just means that item's most recent value still comes from further back in the filing history, which is exactly correct.

The same fact-level resolution also protects against a second, related failure mode: some filers tag segment-level or geographic breakouts using the same underlying concept as the consolidated figure, distinguished only by a dimensional qualifier on the XBRL tag. A resolver that isn't checking for that qualifier can pick up a segment's revenue and present it as if it were the whole company's. The resolver skips any fact carrying a dimensional breakout and only accepts undimensioned, consolidated-level tags — so a segment slice never gets mistaken for the top-line number.

What gets surfaced, not just fixed

Two things distinguish this from a pipeline that just silently gets it right (or silently gets it wrong, which is the more common outcome elsewhere). First, every resolved value carries its own restatement flag: if an earlier filing existed for the same metric and period and was later superseded, the resolved figure says so, with the amendment's accession number and a link back to the filing. An analyst pulling five years of net income for a comp set can see, per company per year, which figures reflect the original filing and which reflect a later correction — rather than discovering it three weeks into a diligence process when the numbers don't tie out to what was reported in a prior year's 10-K.

Second, this data path is not a wholesale replacement for the third-party financial data vendor LacunaIndex has relied on to date — it's a metric-by-metric rollout gated behind a calibration process. Each canonical metric (revenue, net income, basic and diluted earnings per share, total assets, operating cash flow) carries its own promotion status: shadow, calibrating, promoted, or held. While a metric is in shadow or calibrating, the vendor-sourced figure remains what's displayed; the SEC-sourced figure is computed and compared in the background, with divergences above a threshold flagged for a human curator to resolve before that metric can advance. Only once a metric clears calibration does the directly-sourced figure become the number analysts actually see, with the vendor figure demoted to a fallback for cases like foreign filers who don't report under U.S. GAAP (Generally Accepted Accounting Principles). Every cell that has been overridden this way is tagged with its source, so a UI surfacing this data can show — line item by line item — whether a number came straight from a filing or from a vendor's derived figure.

Why this matters for diligence work

None of this is about catching fraud. It's about a much more mundane failure mode: routine SEC amendments are common enough that any comp set of meaningful size will include at least one company that has amended a recent filing, and a pipeline that resolves at the filing level rather than the fact level will get some fraction of those wrong — sometimes by dropping a line item, sometimes by silently blending figures across two filings without a paper trail back to either. For a diligence analyst building a cohort financial comparison, the risk isn't a wrong number in isolation; it's a wrong number that looks exactly as clean and complete as every correct one next to it, with no visible seam marking where the amendment cut in. The fix isn't a smarter aggregate rule — it's resolving one fact at a time and keeping every prior version on record, so "which filing is this number actually from" is always an answerable question rather than an assumption baked into the pipeline.