DEV Community: Christian Pichichero

Survivorship Bias vs Lookahead Bias: The Two Silent Backtest Killers

Christian Pichichero — Mon, 06 Jul 2026 14:46:57 +0000

Most blown-up backtests aren't wrecked by a bad strategy idea. They're wrecked by two data problems that quietly inflate returns: survivorship bias and lookahead bias. They're often mentioned in the same breath, which is a mistake — they come from different places, they fail differently, and one of them is much easier to catch than the other.

This article defines both, explains why lookahead bias is the sneakier of the two, walks through how ordinary fundamentals data causes each one, and lays out what actually fixes them (spoiler: it's not one thing).

Survivorship bias, in one sentence

Your backtest only includes companies that still exist today, so every failure, delisting, and bankruptcy is invisible — and your historical universe silently gets better with hindsight than it actually was at the time.

It's the classic example: you backtest a value strategy on "all S&P 500 companies" using today's constituent list, applied to 2005 data. Every company that got delisted, acquired, or dropped from the index between 2005 and today never shows up in your test. Your strategy looks great because it only ever traded winners-in-hindsight.

Survivorship bias is loud once you know to look for it. If your universe is built from a current list of tickers and applied to past dates, you have it. The fix is mechanical: use a point-in-time universe (constituents as they were, on each date, including the companies that later failed).

Lookahead bias, in one sentence

Your backtest uses a data value on a date before that value was actually knowable, so the strategy is trading on information from the future.

This is the sneaky one. It rarely announces itself. It hides inside something completely mundane: a merge, a join, a groupby().last().

Why lookahead bias is sneakier

Survivorship bias is a universe problem — you either have delisted names in your data or you don't, and that's checkable with a row count. Lookahead bias is a timing problem buried inside data that otherwise looks perfectly normal.

Here's the mechanism most people never notice: financial databases typically store one row per fiscal period, keyed by fiscal period end date (e.g., "FY2022, ended 2022-12-31") — not by the date the number was actually disclosed. A 10-K for fiscal year 2022 isn't filed on December 31, 2022. It's filed weeks or months later, in early-to-mid 2023. If your backtest joins fundamentals to prices using the fiscal period end date as the effective date, you're handing your strategy Q4 2022 revenue on December 31, 2022 — months before any investor could have known it.

The merge runs without errors. The output looks like a normal dataframe. Nothing crashes. Numbers just quietly get used before they were public, because the strategy is trading on data from the future relative to the date you think it's trading on. That's why lookahead bias survives code review, survives peer review, and often survives into live trading before it's caught — because catching it requires knowing to ask "on what date was this number actually public?", not just "is this number correct?"

Restatements make it worse. Companies revise prior-period numbers (that's the restated flag you'll see in decent PIT datasets, and amendments — 10-K/As — are a normal part of that). If your data only stores the latest, current value, you're not just early, you're not even testing the number the market originally saw.

How ordinary fundamentals data causes both, side by side

	Survivorship bias	Lookahead bias
Root cause	Universe built from current tickers, not historical ones	Data keyed by fiscal period end, not filing/disclosure date
What's missing	Delisted, acquired, bankrupt companies	The gap between period end and public filing date
Where it hides	The universe list itself	A join/merge on `date`, invisible in the code
How obvious is it	Fairly obvious once you check for delistings	Not obvious — no error, no crash, silently optimistic
Typical inflation	Overstates returns by excluding losers	Overstates returns by using future information
Fix	Point-in-time universe / constituent history	Point-in-time fundamentals, filtered by first-known date
Also affected by restatements?	Not directly	Yes — original vs. latest values matter

The actual fix: PIT data + a stable universe

There isn't one fix for both, because they're two different bugs:

For survivorship bias: build or buy a universe that includes delisted/failed companies as of each historical date, not a snapshot of today's list applied backward.
For lookahead bias: use fundamentals filtered by the date a value first became public (first_filed <= as_of), not the fiscal period end date. And decide deliberately whether you're testing against the original_value (what the market actually saw first) or the latest_value (post-restatement), because those are two different questions.

Do both, and the numbers your backtest trades on are the numbers an investor could actually have had, on the date the strategy would have acted. We go deeper on the mechanics of the merge bug specifically in Lookahead Bias in Fundamental Backtests, and on what point-in-time data actually looks like row-by-row in Point-in-Time Fundamentals, Explained.

On our own 40-company free sample, the measured gap between fiscal period end and first public filing averaged 43.4 days and reached up to 61 days on the reliable-filing rows — scoped to that sample only, not a claim about the broader dataset. That gap is exactly the window lookahead bias exploits.

When the other option is the better choice

Being honest about scope matters more than winning the comparison. A few cases where you should look elsewhere:

You need quarterly fundamentals. Tradevo Data is annual-only (10-K/10-K/A) right now; quarterly is on the roadmap, not shipped. If your strategy needs 10-Q cadence today, that's a real gap.
You need international coverage. This is US-only, sourced from SEC EDGAR. Non-US equities need a different provider entirely.
You need bulk Parquet files or very high request volume. The API is JSON, rate-limited to 5,000 requests/day. If you're doing large-scale offline research across the full universe repeatedly, a bulk-file provider fits better.
You need decades of history or more concepts. This dataset covers up to 12 fiscal years and 7 core concepts. Established research-grade vendors like Sharadar, Tiingo, or QuantConnect may offer more concepts, longer history, or broader asset-class coverage depending on the plan — see their pricing pages directly, since we won't quote competitor prices here.
You'd rather build it yourself. SEC EDGAR is public domain. If you have the engineering time, you can pull filings, extract first-filed dates, and track restatements yourself. It's genuinely doable — it's also exactly the plumbing work this dataset already did, which is the tradeoff to weigh against $49/month.

If none of those apply and you mainly need clean, point-in-time US equity fundamentals without the merge-bug risk, the free sample is the lowest-friction way to see the actual row structure: github.com/christianpichichero-max/pit-fundamentals — 40 companies, 3,212 rows, full methodology, no signup. When you're ready for the full 5,214-company dataset, the API is at tradevodata.com.

Not investment advice; verify competitor pricing yourself.

Point-in-Time Fundamentals Data: What It Is, Why It Matters, and How to Choose

Christian Pichichero — Mon, 06 Jul 2026 14:46:27 +0000

If you backtest strategies on company fundamentals — earnings, revenue, book value, cash flow — the single most expensive mistake you can make is testing on numbers that weren't actually knowable on the date your model traded. That mistake has a name: lookahead bias. And the fix has a name too: point-in-time (PIT) fundamentals data.

This guide explains what PIT data actually is, why it matters, what separates a real PIT dataset from a marketing label, and an honest survey of your options — from free DIY tooling to five-figure institutional feeds. We build one of those options, and we'll say so plainly at the end, but the goal here is to help you choose the right tool, not to talk you into ours.

What "point-in-time" actually means

A normal fundamentals table gives you one number per company per period — say, Apple's FY2019 revenue. The problem is which version of that number you're looking at. Companies file a 10-K, then sometimes amend it (10-K/A), then restate prior years inside later filings. A vanilla database silently overwrites the original with the newest revision. So when your 2020 backtest reads "2019 revenue," it may be reading a value that wasn't published until 2022.

A point-in-time dataset instead answers a different question: "What was the value of this metric, as it was known on date X?" To do that honestly, each data point has to carry two things a plain table throws away:

A filing date — the date the value first became public (the 10-K's filing timestamp, not the fiscal-period-end date).
The original, first-reported value — preserved separately from any later revision.

With those, a query engine can filter to only the rows whose filing date is on or before your as-of date and hand back the number the market actually had. That's the whole game.

Why it matters: lookahead bias and restatements

Two distinct failure modes make non-PIT fundamentals dangerous for backtesting:

Reporting lag. A fiscal year ends December 31, but the 10-K might not be filed until late February or March. If your backtest assumes the annual numbers were available on January 1, you've handed your model roughly two months of the future. Multiply that across every rebalance and the phantom edge can be large.
Restatements. When a company restates, the revised figure often "improves" the historical picture in ways the market didn't know at the time. A model trained on restated data learns to trade on information that didn't exist yet. Restatements are common enough that ignoring them meaningfully distorts value and quality factors.

We go deep on the mechanics, worked examples, and how to audit your own pipeline in our companion article on lookahead bias in fundamental backtests. If you only read one follow-up, read that one.

What to look for in a PIT dataset

Not every dataset that says "point-in-time" earns the label. Here's a practical checklist:

A real filing-date stamp per row — the date the value became public, not just the period-end date. Without this, "as-of" queries are impossible.
Original value preserved separately from the latest value — so you can see both what was first reported and what it became, and a restated flag so you can filter or study revisions instead of being silently fed them.
A server-side as-of query — ideally you pass an as_of date and the API does the filing-date filtering for you, rather than you reconstructing it and hoping you got the boundary conditions right.
Survivorship handling — for cross-sectional backtests you also need delisted and dead companies present in the universe, or your results are biased toward winners. (Note: fundamentals coverage and a survivorship-free price/universe file are separate concerns — check both.)
Transparent QA — you want to know when a value is flagged or uncertain, not have it quietly dropped.

An honest survey of your options

There's no single right answer here — the right tool depends on your budget, coverage needs, and how much plumbing you want to own. Pricing below is directional and drifts constantly, so treat every number as "verify on their page," linked.

Option	Rough cost (as of July 2026)	PIT capability	Best for
DIY from SEC EDGAR	Free (your time + infra)	Full, if you build it	Teams who want total control and have engineering time
Budget PIT APIs (incl. us)	~$0–$50/mo tier	Varies — check for filing dates + original values	Individuals and small shops proving an idea
Sharadar SF1	Subscription — see pricing	Point-in-time (datekey-based)	Retail quants wanting broad coverage + ratios
Tiingo fundamentals	Add-on — contact/pricing	As-reported dimension available; confirm filing-date detail	Users already on Tiingo for prices
Compustat / LSEG	Institutional (commonly $10k–$50k+/yr)	Deep PIT snapshots (Compustat PIT from 1987)	Funds, academics via WRDS, anyone needing decades of history

DIY from EDGAR is genuinely free — all US filings are public domain. You can parse XBRL, stamp filing dates yourself, and own the whole stack. The catch is that "parse XBRL correctly, dedupe amendments, and handle restatements" is weeks-to-months of unglamorous work, and quiet bugs there reintroduce the exact lookahead you were trying to remove.

Sharadar and Tiingo are credible, established budget-to-mid options. Sharadar's fundamentals are point-in-time via its datekey structure and cover a broad US universe with many pre-computed ratios; Tiingo offers an as-reported dimension and pairs naturally with its price data. Confirm the specific PIT semantics you need against their current docs.

Compustat and LSEG are the institutional standard for a reason: decades of carefully curated PIT snapshots, global coverage, and support. They also cost accordingly and are usually accessed through an institution or WRDS.

Where we fit

Tradevo Data is a deliberately narrow, honest budget tier of research-grade PIT — one middle option among the credible ones above, not "the only cheap PIT." Concretely, today it is: point-in-time US annual equity fundamentals sourced from SEC EDGAR (public domain), covering 5,214 companies and 313,562 PIT rows across 7 core concepts (Revenue, NetIncome, Assets, StockholdersEquity, OperatingCashFlow, EPSDiluted, DilutedShares), up to 12 fiscal years.

Every row carries first_filed (when it became public), original_value (first-reported, PIT-safe), latest_value (current revision), a restated flag, and a per-row qa_status — flagged, never silently hidden. There are 18,539 labeled restatements in the set. Delivery is one JSON endpoint — /v1/fundamentals?ticker&as_of[&concept] — with server-side as-of filtering (first_filed <= as_of).

Being equally plain about the limits: it's annual only right now (no quarterly yet — on the roadmap), US only, and there's no Parquet bulk download yet. If you need quarterly data, decades of history, or global coverage today, one of the options above is a better fit, and you should use it.

When each option is the better choice

DIY EDGAR — you have engineering time, want zero per-month cost, and value owning the pipeline over speed.
Sharadar — you want broad US coverage plus ready-made ratios and a survivorship-free universe file, at a retail-quant price.
Tiingo — you're already using Tiingo for prices and want fundamentals in the same stack.
Compustat / LSEG — you need decades of PIT history, global coverage, or institutional support, and have the budget.
Tradevo Data — you want US annual PIT with explicit original-vs-restated fields and a dead-simple as-of API, cheaply, to prove out an idea before committing to a bigger feed.

Try it without a signup

If you just want to see what honest PIT rows look like, our free sample is on GitHub — 40 large caps, 3,212 rows, full methodology, no email required: github.com/christianpichichero-max/pit-fundamentals. Inspect the schema, run an as-of query against your own backtest, and decide for yourself.

If it fits and you want the full universe, the API is $49/mo, 5,000 requests/day, key issued instantly, cancel anytime — details and docs at tradevodata.com. And if it doesn't fit, one of the alternatives above genuinely will.

This is educational content, not investment advice. Pricing and product details for third-party vendors change — verify every number on the vendor's own pricing page before you buy.

Your Backtest Saw the Future: Lookahead Bias in Fundamental Data, Measured Across 313,562 Rows

Christian Pichichero — Mon, 06 Jul 2026 14:38:33 +0000

If your backtest joins fundamentals on the fiscal-period-end date, it is trading on numbers that did not exist yet. That's the whole bug, in one sentence. A company's fiscal year ends, and then — weeks later — a 10-K gets filed and the numbers become public. Join on the wrong date and every fundamental data point in your backtest arrives early.

We measured how early. Across the 313,562 point-in-time rows in our dataset (5,214 US companies, built from raw SEC EDGAR filings), on rows with a reliable filing date, fundamentals became public an average of 43 days after the fiscal period ended. The maximum in our sample was 61 days.

Forty-three days of free clairvoyance on the average row, compounding across every rebalance. That is why fundamental strategies so often look great in testing and evaporate live.

This post covers what lookahead bias is, the measurement, how to check your own pipeline for it, and what the honest fixes are — including the free ones.

What is lookahead bias?

Lookahead bias is when a backtest uses information that was not yet publicly available at the simulated decision time. The simulation "knows" something the market didn't, so the strategy's historical results are inflated in a way that cannot be replicated live.

It's the quieter sibling of survivorship bias, and it's more dangerous, because it doesn't require a broken universe or a bad vendor — it hides inside a perfectly innocent-looking merge(). The data is real. The values are correct. Only the timestamps are lying.

Price data mostly can't have this problem: a trade prints and is public within milliseconds. Fundamental data is the worst offender, for a structural reason.

Why fundamentals are the worst offender

Every fundamentals row has two dates, and most datasets only make one of them easy to use:

Period end — the date the fiscal year closed. This is the date the numbers describe.
First filed — the date the 10-K hit EDGAR. This is the date the numbers became knowable.

The gap between them is dead air during which the company knows its results and you don't. SEC deadlines let a 10-K be filed up to 60 days after fiscal year-end for large accelerated filers, 75 for accelerated filers, and 90 for everyone else — and late filers can extend beyond that.

Naive datasets index everything by period end, because that's the natural key for the accounting. But your backtest doesn't care what period the number describes; it cares when a trader could have acted on it. Those are different questions with different dates, an average of 43 days apart in our data.

A concrete example: Apple's FY2024

These rows come straight from our dataset (you can verify them in the free sample — no signup):


FY2024 period end	2024-09-28
FY2024 10-K filed	2024-11-01 (34 days later)
Revenue as first reported	$391.0B
Diluted EPS as first reported	$6.08

Now ask the only question a backtest should ever ask: what was the newest annual revenue you could honestly know about Apple on a given date?

As-of date	Newest AAPL annual revenue honestly knowable	Filed
2024-10-15	FY2023 — $383.3B	2023-11-03
2024-11-15	FY2024 — $391.0B	2024-11-01

Same company, one month apart, a different "latest known" number. A naive period-end join hands your October 2024 backtest the FY2024 figures — a month before the market saw them.

And note: Apple is the best case on timing. Across 12 fiscal years in our data, Apple filed its 10-K 30–37 days after year end, faster than the 43-day cross-sectional average — the average company gives your backtest a bigger peek than this. Even Apple, though, isn't clean on what comes next: run the sample and you'll find five AAPL rows flagged restated. FY2018–19 diluted EPS and share counts were retroactively rewritten by exactly 4× when the 2020 stock split was applied to prior years — the diluted EPS the market first saw as $11.91 is carried in current data as $2.98 — and FY2017 operating cash flow was later revised by about 1%. Which is the second problem.

The second leak: restatements

Fixing the filing date is necessary but not sufficient, because filed numbers don't stay put. Companies restate and revise: 10-K/A amendments, reclassifications, corrections, retroactive split adjustments. In our dataset we found 18,539 rows where a later filing revised a previously reported value by more than 0.5% on the same XBRL tag.

Here's why that leaks even in a dataset that has a filing-date field. Most budget fundamentals APIs store one mutable value per period. When a restatement lands, the historical value is silently overwritten. Your backtest then reads the corrected number stamped with the original filing date — information that genuinely did not exist on that date. The lookahead is smaller and rarer than the 43-day version, but it's concentrated exactly where it hurts: in the companies whose numbers turned out to be wrong.

A genuinely point-in-time dataset has to keep both values: what the market first saw, and what we now believe is true.

How to detect lookahead bias in your own backtest

You don't have to take any of this on faith. Two checks, both cheap.

1. Audit your join dates against real filing dates

Our free sample (40 large caps, 3,212 rows, CSV) carries a first_filed column derived from the actual EDGAR filings. Merge your vendor's data against it and count the leaks:

import pandas as pd

# free sample: github.com/christianpichichero-max/pit-fundamentals
pit = pd.read_csv("data/pit_fundamentals_history.csv",
                  parse_dates=["period_end", "first_filed"])
pit = pit[pit["filed_reliable"]]

print((pit["first_filed"] - pit["period_end"]).dt.days.describe())
# mean lag ≈ 43 days — on this sample and on the full 313,562-row dataset

# your data: ticker, fiscal_year, and the date your backtest
# currently *sees* the row (whatever you join on today)
m = vendor.merge(
    pit[["ticker", "fiscal_year", "first_filed"]].drop_duplicates(),
    on=["ticker", "fiscal_year"])
leaked = m["visible_date"] < m["first_filed"]
print(f"{leaked.mean():.0%} of rows were visible to your backtest "
      f"before they were public")

If that percentage isn't ~0%, your historical results include information that hadn't been published yet.

2. The lag-shift test

Re-run your backtest with every fundamental data point delayed to period_end + 90 days (a conservative bound on public availability). If your Sharpe or CAGR degrades materially, the difference was never alpha — it was the peek. A strategy that only works when it sees filings early is a strategy that doesn't work.

Softer symptoms worth suspicion: fundamental signals that seem to "time" earnings surprisingly well, value strategies whose turnover clusters near fiscal year-ends, and — the classic — a live track record that decays immediately relative to the backtest.

How point-in-time data fixes it

A point-in-time (PIT) dataset makes knowability the primary index. Every value in ours carries:

first_filed — the date the number actually became public (the PIT stamp)
original_value — the number as first reported: what the market saw. Use this for backtests.
latest_value — the current post-revision number. Use this for present-day screening.
restated — flagged when a later filing moved the value >0.5% on the same tag (including 10-K/A amendments)
qa_status — per-row validation result. Rows we can't fully trust are flagged, never hidden.

The query semantics then enforce honesty server-side. Our API is one endpoint:

GET /v1/fundamentals?ticker=AAPL&as_of=2024-10-15

This returns only rows where first_filed <= as_of — so the 2024-10-15 query above returns FY2023 and earlier, never FY2024, no matter how you write your backtest loop. (One honest edge to know: the comparison is inclusive, so a filing dated exactly on your as-of date is returned. If you want to be strict about same-day tradability, subtract a day.)

One more thing, because trust in a dataset should be earned, not asserted: before launch we had independent agents adversarially re-derive values from the raw EDGAR filings and compare them against ours. They found one real bug in our revision tracking. We fixed it before shipping. The full methodology — tag resolution, duration filters, restatement thresholds, QA rules — is published in the open alongside the sample.

Your options, honestly compared

We sell one of these options, so calibrate accordingly. But the comparison below is real, and for some readers the right answer is not us.

1. DIY from SEC EDGAR — free. EDGAR's companyfacts API is public domain, free, and needs no key. This is what we build from, and you can too. The catch is engineering, not access: companies switch XBRL tags over time (Apple's revenue has lived under three different tags since 2014), stub periods and quarters can leak into annual figures, and reconstructing first-reported values through restatements is genuinely fiddly — that's where our own audit found a bug. If you have the time, our published methodology is a usable blueprint. Budget a few weekends, not a few hours.

2. Budget fundamentals APIs (~$15–100/mo). Many include a filing-date field, which solves the 43-day problem if you remember to join on it. The structural gap is the mutable single value per period described above: restatements silently overwrite history, so the "point-in-time" join can still leak, and you can't reconstruct what the market originally saw.

3. Sharadar and Tiingo — the credible budget incumbents. We will not pretend to be the only affordable PIT-aware option, because we aren't. Sharadar (via Nasdaq Data Link, roughly $550–830/yr for personal use) offers as-reported dimensions, quarterly data, ~20,000 companies including delisted ones, and history to 1998 — if you need quarterly or delisted coverage today, buy Sharadar; it is better than us at those things. Tiingo's asReported fields are also genuinely PIT-relevant. The tradeoffs: you assemble the as-of join yourself from dimension tables, pricing sits behind a login, and Sharadar's non-professional license excludes money-management use.

4. Research-grade institutional PIT ($10k–50k/yr). Compustat Snapshot, LSEG, Calcbench, Intrinio (~$9.6k/yr). These are the genuine article — deep history, full revision archives, survivorship-bias-safe universes — and if someone is paying you to manage money, they are probably the right call. They are also priced for institutions and generally won't sell to an individual with a Stripe card.

5. Tradevo Data — the middle. $49/mo, one documented JSON endpoint with server-side as_of, original_value vs latest_value on every row, restatement flags, per-row QA, 5,000 requests/day, key issued instantly after checkout. We think of it as the honest budget tier of a product that has historically cost $10k–50k/yr — not "better data than everyone," just lookahead-safety as the default query semantic, at a price an individual can justify.

What our data doesn't do (yet)

Stating this up front so you don't find out after paying:

Annual only — 10-K and 10-K/A. Quarterly (10-Q) is on the roadmap, not shipped.
US companies only (5,214 of them).
7 concepts: Revenue, NetIncome, Assets, StockholdersEquity, OperatingCashFlow, EPSDiluted, DilutedShares.
Up to 12 fiscal years of history.
No bulk Parquet download yet — it's a query API.
first_filed <= as_of is same-day-inclusive, as noted above.

If any of those is a dealbreaker, the comparison section above has options that fit better, and we'd rather you use them than be disappointed here.

Check the work yourself

The free sample is on GitHub — 40 large caps, 3,212 point-in-time rows, full methodology, no signup: github.com/christianpichichero-max/pit-fundamentals. Run the audit snippet above against your current vendor. If your pipeline comes back clean, excellent — you lost ten minutes and gained a verified negative.

If it doesn't, and you want the fix as an API instead of a weekend project: the full dataset is $49/mo at tradevodata.com, key issued instantly, docs at tradevodata.com/docs, cancel anytime.

Tradevo Data is a product of Tradevo Technologies Inc. Source data is U.S. SEC EDGAR (public domain). We sell a dataset, not signals — nothing here is investment advice, and no data product can make a bad strategy good. It can only stop a backtest from lying to you.

How to Build a Point-in-Time Fundamentals Database from SEC EDGAR (and When Not To)

Christian Pichichero — Mon, 06 Jul 2026 14:38:27 +0000

If you backtest with today's fundamentals, you are cheating yourself. The Revenue figure you pull for Q4 2019 was probably restated in 2021, and the restated number was not knowable on the day you would have traded. That gap is lookahead bias, and it is why "point-in-time" (PIT) fundamentals exist: a dataset that answers what did filers report, and when did the market first see it?

The good news: the raw material is free and public. The SEC's EDGAR system publishes structured XBRL financials for every US filer, and with enough patience you can assemble a real PIT database yourself. The honest news: a few steps are fiddly enough that most DIY builds ship a subtle bug. This guide teaches the whole pipeline — our full methodology is public on GitHub — then weighs the cost fairly so you can decide whether to build or buy.

The build: EDGAR companyfacts, step by step

1. Pull companyfacts. EDGAR exposes a per-company JSON blob at data.sec.gov/api/xbrl/companyfacts/CIK{10-digit}.json. It contains every XBRL fact the company has ever tagged, grouped by taxonomy (us-gaap, dei) and concept, each with an array of reported values. This is your source of truth. Respect the SEC's fair-access rules (declare a User-Agent, throttle to ~10 requests/sec).

2. Filter to annual 10-K facts. Each fact carries a form (10-K, 10-K/A, 10-Q, 8-K…) and, for flow concepts like Revenue, a start/end window. You want annual figures, so keep 10-K and 10-K/A (amendments) and filter duration concepts to roughly 365-day windows. Skip this and you will silently mix quarterly and annual Revenue into the same series — a classic corruption.

3. Resolve XBRL synonym tags across years. This is where builds quietly break. Companies change the tag they use for the same economic concept. Revenue might be Revenues one year, RevenueFromContractWithCustomerExcludingAssessedTax the next, and SalesRevenueNet in an older filing. If you map only one tag, you get holes exactly where a company evolved its reporting. You need an ordered synonym list per concept and a deterministic resolution rule so the same logical field is populated every year.

4. Stamp first_filed. For each value, record the date it first appeared in a filing (the accession's filing date), not the fiscal period end. This first_filed stamp is the entire point of PIT: a backtest asks "what was known as of date X?" and you answer by returning only rows where first_filed <= X. Same-day filings should be inclusive.

5. Detect same-tag restatements. When a later 10-K or 10-K/A reports a different value for a period you already have, that is a restatement. Keep both: the original_value (first-reported, PIT-safe) and the latest_value (current best estimate), plus a restated flag. Use a tolerance — we flag when the same tag's value moves more than 0.5% — so rounding noise does not masquerade as a restatement.

6. QA every row. Sanity-check signs, magnitudes, and duplicate periods; carry a qa_status so consumers can filter. Fundamentals data is dirty; a QA column is not optional.

The part everyone underestimates

Restatement reconstruction is deceptively hard, and we say that from experience: our own audit found a bug in exactly this step. It is easy to write logic that looks right on Apple and Microsoft — clean filers with stable tags — and quietly mislabels the messier 80% of the market. Tag switches (step 3) and restatement detection (step 5) are where a DIY dataset silently drifts from ground truth, and you often won't notice until a backtest looks suspiciously good. Budget real test coverage across small caps, amenders, and tag-switchers, not just the mega-caps.

Build vs. buy: an honest comparison

	Build from EDGAR	Tradevo Data ($49/mo)	Research-grade vendors
Cost	$0 + your time	$49/mo	Higher / quote-based
Setup	Days to weeks	Minutes (key after checkout)	Varies
PIT correctness	Yours to get right	`first_filed`, original vs. latest, restatement flags	Yes (their core)
Coverage	Whatever you build	5,214 US companies, annual only	Often broader (quarterly, global)
History	As far as you pull	Up to 12 fiscal years	Often 20-25+ years
Restatements	You reconstruct	18,539 labeled	Handled
Bulk / Parquet	Build it	JSON API only (no bulk yet)	Often available
Methodology	Yours	Public	Usually opaque

Credible paid PIT options exist and we won't pretend otherwise. Sharadar Core US Fundamentals (via Nasdaq Data Link) is a well-regarded point-in-time dataset with deep history; its personal pricing is not publicly listed as of July 2026, so check their page. Tiingo offers a Power plan at $30/mo individual / $50/mo commercial as of July 2026, with fundamentals sold as a separate API add-on (pricing on request) and an as-reported option of its own — see their pricing. Both are legitimate; verify current terms before you buy, because vendor pricing moves.

When to build it yourself

You want to learn the plumbing. Building the pipeline once teaches you what PIT actually means, and you'll trust your data more for having wrangled it.
You need concepts or coverage nobody sells. Custom tags, obscure line items, non-standard filers — EDGAR has it all; you just have to extract it.
Your time is genuinely free relative to $49/mo, and you enjoy this kind of work.
You need full control and auditability down to the accession level.

When buying is the better choice

You'd rather test a strategy than debug XBRL synonym tables. The engineering is real, and every week on the pipeline is a week not spent on research.
You want restatement handling you didn't have to reconstruct — the exact step where our own audit caught a bug, and where DIY builds most often ship wrong.
$49/mo is cheaper than your afternoon. For most working quants, it is.
You need broader coverage or quarterly data. Then a deeper vendor like Sharadar or Tiingo may fit better than either a weekend build or our annual-only tier — we're the honest budget tier, not the only option.

Start free, either way

Whichever path you pick, start by looking at real PIT data. Our free GitHub sample has 40 large caps, 3,212 rows, and the complete methodology — tag resolution, first_filed stamping, same-tag restatement detection, QA — with no signup. Read it, copy the approach, and build your own. If you'd rather skip the fiddly parts, Tradevo Data serves the same discipline as one JSON endpoint (/v1/fundamentals?ticker&as_of) with server-side as_of filtering, 5,000 requests/day, and an instant key after checkout — cancel anytime.

Build it or buy it. Just don't backtest on restated numbers and call it edge.

Not investment advice. Tradevo Data provides point-in-time US equity fundamentals sourced from public SEC EDGAR filings; it does not make performance claims. Competitor pricing and features are as of July 2026 — always verify current terms on each vendor's own page before purchasing.