Christian Pichichero

Every financial statement exists in at least two versions: the number a company first told the market, and whatever number ends up in today's database after amendments, reclassifications, and restatements. If you're building a fundamental backtest, confusing the two is one of the quieter ways to inflate a strategy's historical returns — quieter than survivorship bias, but just as real.

This article works through what "as-reported" and "restated" actually mean, why a backtest that uses the wrong one is training on information that didn't exist yet, and how a point-in-time (PIT) dataset like Tradevo Data represents both so you can choose deliberately instead of by accident.

As-reported: what the market actually saw

As-reported (also called original or first-filed) is the value disclosed in the filing that made it public — for us, a 10-K (or 10-K/A). It's stamped with a date: the moment that number entered the public record via SEC EDGAR. Before that date, no market participant could have known it. That's the entire premise of point-in-time data: every fact carries a timestamp for when it became knowable, not just what the fact eventually became.

Restated: what the number is today

Restated (or latest) is the current, revised figure after any subsequent 10-K/A amendments or comparative restatements in later filings. Companies restate for real reasons — accounting errors, standard changes, reclassifications, M&A-driven reallocations. The restated number is often more accurate as a historical record of what actually happened. It is not, however, what a trader or analyst could have known on the date the original filing hit the tape.

Why this becomes lookahead bias in a backtest

A backtest that joins today's restated fundamentals to historical prices is implicitly assuming the market had access to information it didn't have yet. If a company later restates revenue upward and your backtest uses the restated figure as of the original filing date, any strategy conditioned on that revenue print will look smarter in hindsight than it could have been in real time. The effect is usually small per company, but restatements aren't rare — our dataset flags 18,772 restatements across 314,436 point-in-time rows, which suggests this is a systematic feature of financial data, not an edge case you can ignore.

The fix is mechanical, not statistical: for any date you're backtesting against, use only the values that had a first_filed date on or before that date, and use the value as it was first reported — not as it later became.

A concrete example

Suppose a company files its original 10-K reporting revenue for fiscal year N. Some quarters later, it files a 10-K/A that revises that same fiscal year's revenue — the change exceeds the 0.5% same-tag threshold we use to flag a meaningful restatement (not just a rounding or presentation tweak).

In Tradevo Data's schema, that single revenue fact for fiscal year N produces:

  • first_filed: the date the original 10-K became public
  • original_value: the revenue as first reported — this is what you join against historical dates for a PIT-safe backtest
  • latest_value: the revenue as currently stated, after the 10-K/A
  • restated: true, because the revision exceeded the 0.5% same-tag threshold
  • qa_status: our internal check on whether the row parsed and reconciled cleanly

If your backtest logic is "as of date X, what did we know about this company's revenue," you filter to rows where first_filed <= X and read original_value. If your logic is "what actually happened to this company's revenue, full stop," you read latest_value. Same row, two different questions, two different answers — and picking the wrong one for the wrong question is exactly the bug PIT data exists to prevent.

As-reported vs restated at a glance

As-reported (original_value) Restated (latest_value)
Answers the question What did the market know on this date? What is the corrected historical fact?
Correct use Backtesting, PIT research, signal generation Fundamental analysis of "true" historical performance, post-mortems
Risk if misused None if used correctly for its purpose Lookahead bias if fed into a historical backtest
Changes over time No — frozen at first filing Yes — updated as amendments are filed
Where it lives in our schema original_value + first_filed latest_value + restated flag

When restated data is genuinely the better choice

This isn't a case for always preferring as-reported. If you're doing retrospective fundamental analysis — "how did this company's margins actually trend over a decade" — the restated figure is usually the more honest answer, since it reflects corrected accounting rather than a since-fixed error. Restated data is also the right call for training long-horizon valuation models where you're not simulating point-in-time decisions, or for auditing how much a company's numbers have moved since first disclosure. The mistake isn't using restated data; it's using it inside a backtest that pretends to be historical.

When to build it yourself — or use someone else's dataset

Building a PIT pipeline from raw EDGAR filings is entirely doable, and for some teams it's the right call: you get full control over parsing logic, tag mapping, and restatement detection thresholds, and you're not dependent on anyone's refresh schedule. The tradeoffs are real, though — reconciling XBRL tags across amendments, tracking every 10-K/A, and validating first-filed dates against actual EDGAR timestamps is unglamorous, ongoing work, and it's easy to introduce silent bugs (like accidentally picking up a restated value) that only surface when your backtest results look suspiciously good.

If you need quarterly data, non-US markets, or Parquet natively today, other providers are worth evaluating — Sharadar, Tiingo, and QuantConnect all offer credible fundamentals products; see their pricing pages directly, since we won't quote competitor prices here and terms change. Tradevo Data is annual-only (10-K/10-K/A), US-only, and CSV-first (Parquet is on the roadmap), so if your use case needs more than that today, one of those may be the better fit right now.

Where Tradevo Data fits

What we do offer: 5,216 US companies, 314,436 point-in-time rows across 7 core concepts, up to 12 years of history, with every value carrying first_filed, original_value, latest_value, and a restated flag so you never have to guess which one you're looking at. On our 40-company free sample, the measured lookahead between a value becoming public and being usable averaged 43.4 days (max 61 days) on reliable-filing rows — a number we report scoped to that sample only, not the full dataset, because we haven't measured it universe-wide yet.

The full methodology and 3,280 sample rows are free, no signup: github.com/christianpichichero-max/pit-fundamentals. If it fits your workflow, the full dataset and API are $49/mo at tradevodata.com — bulk download and whole-universe snapshots included, cancel anytime. For more on how lookahead bias creeps into backtests, see /blog/lookahead-bias-fundamental-backtests and /blog/point-in-time-fundamentals-data.

Not investment advice; verify competitor pricing yourself on their respective sites.