DEV Community: Christian Pichichero

Why the Same Fundamental Lives Under Different XBRL Tags in SEC EDGAR

Christian Pichichero — Wed, 12 Aug 2026 16:31:22 +0000

If you've tried to pull "revenue" for a US company directly out of SEC EDGAR's XBRL data, you've probably noticed something annoying: the same line item on the income statement doesn't always show up under the same tag. One year it's Revenues. Another year, for the same company, it's SalesRevenueNet. After 2018 it might switch again to RevenueFromContractWithCustomerExcludingAssessedTax. Nothing about the business changed — the taxonomy did.

This is one of the least-discussed but most consequential problems in building point-in-time fundamentals from EDGAR, and it's the reason a lot of DIY XBRL scrapers quietly produce broken time series without anyone noticing until a backtest looks weird.

Why the tags change at all

The SEC requires filers to tag financial statement line items using the US GAAP XBRL taxonomy, which the FASB updates annually. A few things drive tag churn:

Taxonomy revisions. New tags get added, old ones get deprecated, and companies (or their filing agents) migrate to the current tag in a later filing — sometimes mid-history, sometimes not at all.
Accounting standard changes. The rollout of ASC 606 (revenue recognition) around 2018 is the clearest example: many filers moved from Revenues or SalesRevenueNet to RevenueFromContractWithCustomerExcludingAssessedTax or the "IncludingAssessedTax" variant, sometimes in the same fiscal year they adopted the standard.
Filer inconsistency. Two companies in the same industry, filing in the same quarter, can choose different (both technically valid) tags for what an analyst would call the same concept. Smaller filers and their outside preparers are especially inconsistent year over year.
Custom/extension tags. Filers can create company-specific extension tags instead of using a standard one, which is valid XBRL but invisible to anyone matching on a fixed tag list.

None of this is a data error. It's just how the taxonomy and filer behavior evolve. But if your pipeline hardcodes "revenue = tag X," you will silently lose or corrupt history the moment a company switches tags.

How this breaks naive datasets

The common failure mode looks like this: a script pulls Revenues for every 10-K, going back as far as the filer used that tag. The moment the company switches to RevenueFromContractWithCustomerExcludingAssessedTax, the naive pull sees a gap — the concept looks like it disappeared. Depending on how the downstream code handles missing values, you get one of three quiet failures:

A false gap in the time series (treated as no revenue reported).
A forward-fill of the last known value, understating growth or flatlining a metric that actually changed.
A join against the wrong tag entirely, if a fallback rule grabs a different line item that happens to exist (e.g., falling back to SalesRevenueGoodsNet and picking up only product revenue, not total revenue).

All three are worse than an explicit "no data," because they don't look like errors — they look like real numbers. That's the trap: tag drift doesn't crash your pipeline, it silently biases it.

How synonym-tag resolution actually works

The fix is conceptually simple but tedious to do correctly: instead of mapping one concept to one tag, you maintain a synonym set of tags per concept, ordered and scoped by validity period and filer behavior, and you resolve at read time rather than baking in a single tag at ingest time.

In practice, for Tradevo Data that means:

Each of our seven tracked concepts (Revenue, NetIncome, Assets, StockholdersEquity, OperatingCashFlow, EPSDiluted, DilutedShares) maps to a list of known US GAAP tags that filers have used for that concept, not a single tag.
When a filing is parsed, we check the synonym list in a defined priority order and record which tag actually resolved, so the mapping is auditable rather than a black box.
We track first_filed (when the value became public) separately from latest_value (the current, possibly amended figure), and flag rows as restated when a same-tag revision moves the value by more than 0.5%, including amendments. That's how the dataset ends up with 18,717 labeled restatements — those are tag-consistent revisions, not tag-switch artifacts.
qa_status on each row exists specifically so a switch that looks suspicious (e.g., a jump coinciding with a tag change) is visible to whoever is using the data, rather than silently smoothed over.

The full mapping logic and the reasoning behind it — including which tags we treat as synonyms for each concept and why — is public in the methodology alongside the free sample, not hidden behind the paid API. If you want to see exactly how a specific company's revenue tag changed over time, that's the place to check it yourself: github.com/christianpichichero-max/pit-fundamentals (3,280 rows across 40 companies, full methodology, no signup).

For the point-in-time angle specifically — why first_filed matters independently of tag resolution — see /blog/point-in-time-fundamentals-data and /blog/lookahead-bias-fundamental-backtests.

A fair comparison of your options

Approach	Handles tag drift?	Point-in-time (`first_filed`)?	Frequency	Cost
Raw SEC EDGAR + your own scraper	Only if you build synonym mapping yourself	Only if you build it (EDGAR gives you filing dates, not a PIT API)	Whatever you implement	Free (your engineering time)
Tradevo Data	Yes, synonym sets per concept, documented in the free methodology	Yes, `first_filed` + `original_value` on every row	Annual only (10-K / 10-K/A); quarterly is on the roadmap, not available today	$49/mo
Sharadar / Tiingo / QuantConnect fundamentals	Not independently verified by us — these are established, mature vendors, so check their docs for specifics	Varies by product; check each vendor's docs	Varies by product; check each vendor's docs	See their pricing pages: Sharadar via Nasdaq Data Link, Tiingo, QuantConnect

This isn't an attempt to declare a winner. We haven't audited Sharadar's, Tiingo's, or QuantConnect's internal tag-resolution logic, so we're not claiming to know how they handle it — only that they're credible, established sources worth comparing against. If price or feature fit matters to your decision, their pricing pages will tell you what's on offer; we're not going to guess a number for you.

When the established players are the better choice

Be honest with yourself about what you actually need before defaulting to the cheaper option:

If you need quarterly fundamentals, Tradevo Data doesn't have them yet (roadmap only) — an established vendor that already offers quarterly data is the right call today.
If you need non-US markets, more historical depth than 12 fiscal years, or a broader concept set beyond our seven, a larger vendor's coverage is likely to fit better.
If you need a track record — a data provider that's been used in production research for years, with support SLAs and a sales team you can talk to — that's a real advantage of established players over a $49/mo budget tool run by a small team.
If Parquet or other formats matter to your pipeline today (not roadmap, today), check whether an established vendor already ships it.

We'd rather point you to the right tool than pretend we're the right tool for every use case.

When you should build it yourself

Building your own EDGAR XBRL parser is a legitimate choice, not just a fallback for people who can't afford data. It's the right call if:

You need concepts or tags outside the seven we track (segment data, non-GAAP reconciliations, footnote disclosures).
You need international filers or non-EDGAR sources.
You have engineering time to spend and want full control over the synonym-resolution rules rather than trusting someone else's judgment calls.
Your research only needs a handful of companies and a few concepts — at that scale, hand-checking tag switches against the actual 10-K filings is faster than integrating a new data source.

Where a vendor (any vendor, not just us) earns its cost is in the tedious part: tracking taxonomy changes across thousands of filers over many years, catching restatements, and doing it consistently so you're not re-solving the same tag-drift problem every time the FASB updates the taxonomy.

Try it before you pay for it

The free sample has the same tag-resolution logic as the paid dataset, just scoped to 40 companies and 3,280 rows — enough to inspect a real tag switch yourself and decide if the approach holds up: github.com/christianpichichero-max/pit-fundamentals.

If it does and you need the full 5,193-company, 313,001-row universe with a server-side as_of query, the API and bulk download (/v1/download, /v1/snapshot?as_of) are $49/mo, cancel anytime: tradevodata.com/?ref=blog.

Not investment advice. This dataset describes what was publicly filed and when — it makes no claims about future performance. Verify competitor pricing and feature claims yourself on their websites before deciding.

SEC 10-K Filing Deadline Data: The Structural Reason Fundamentals Lag Weeks Behind

Christian Pichichero — Wed, 12 Aug 2026 16:30:51 +0000

If you've ever wondered why a company's "Q4 numbers" aren't publicly known the day the fiscal year ends, the answer isn't vendor laziness or data-pipeline delay. It's the SEC's own filing calendar. The deadlines are public, stable, and have been in place for years — and they're the single biggest structural reason any honest fundamentals dataset has a gap between period-end and public availability.

This matters for anyone backtesting on fundamentals: if your data model assumes a number was known the moment the quarter closed, you're not modeling reality. You're modeling a fantasy calendar that doesn't exist.

The SEC's 10-K Deadlines Are Public and Fixed by Filer Class

Under SEC rules (Exchange Act Rule 12b-2 and related Regulation S-K guidance), the deadline to file an annual report (Form 10-K) after fiscal year-end depends on the company's filer category, which is based on public float:

Filer Category	Public Float Threshold	10-K Deadline After Fiscal Year-End
Large Accelerated Filer	$700M or more	60 days
Accelerated Filer	$75M to $700M	75 days
Non-Accelerated Filer	Under $75M	90 days

These thresholds and deadlines are public record, not proprietary knowledge. Any company can and does file earlier than its deadline — but a meaningful share file close to it, because compiling audited financials, running the audit committee process, and drafting MD&A takes real time. The deadline is a ceiling companies work toward, not a floor they clear early by default.

Why the Deadline Creates a Point-in-Time Gap

Here's the mechanical consequence: a fiscal year that ends December 31 might not have its 10-K publicly filed until late February (large accelerated), mid-March (accelerated), or the end of March (non-accelerated). That's a 60-to-90-day window baked into the regulatory structure, before you even account for filers who use extensions (Form 12b-25) or file 10-K/A amendments later.

So when you see a "FY2023 Revenue" figure, the honest question is: known to the public when? Not "as of fiscal year-end" — as of the date the 10-K (or amendment) actually hit EDGAR. Any dataset that timestamps fundamentals by fiscal period end instead of filing date is implicitly assuming zero-day disclosure, which the SEC's own deadlines show doesn't happen.

From Filing Date to "First Known" Value

This is why point-in-time (PIT) datasets track more than just the number. Tradevo Data's schema, sourced directly from SEC EDGAR (public domain), records for each row:

first_filed — the date the value first became public
original_value — the first-reported figure (the point-in-time-safe one)
latest_value — the current, possibly-restated figure
restated flag — set when a later filing changes the same tag by more than 0.5%, including amendments
qa_status

Across the dataset, 18,717 restatements carry the restated flag — a reminder that "the number" for a given fiscal year isn't fixed at first filing; it can move, and a PIT-correct backtest needs to use what was known on a given date, not what we know now with hindsight.

What We Actually Measured (Scoped Honestly)

On the free 40-company sample's reliable-filing rows, the measured lookahead — the gap between fiscal period end and first_filed — averaged 43.4 days, with a maximum of 61 days. That number is specific to the 40-company sample and should not be quoted as a property of the full 5,195-company, 313,137-row dataset; the two are measured differently and we're not going to blur that line for a cleaner headline.

When a Bigger or Quarterly-Aware Vendor Is the Better Choice

In the interest of not overselling: if your strategy needs quarterly (10-Q) fundamentals, non-US equities, Parquet delivery, or a vendor with a longer operating track record and broader SLA guarantees, providers like Sharadar, Tiingo, or QuantConnect are worth evaluating — see their pricing pages directly, since we won't quote competitor prices here. QuantConnect in particular is worth a look if you want fundamentals data pre-integrated into a backtesting engine rather than delivered as a standalone feed. Tradevo Data is annual-only (10-K plus 10-K/A) for now, US-only, and delivered as JSON/CSV — quarterly and Parquet are roadmap items, not shipped features.

When to Build It Yourself from EDGAR

EDGAR's raw filings and XBRL data are free and public. If you only need a handful of tickers, have engineering time to spare, and want full control over parsing logic, building your own extractor is a legitimate option. The tradeoffs to budget for: XBRL taxonomy changes across years, handling 10-K/A amendments correctly so you don't silently overwrite original_value with latest_value, and building the first_filed logic so your backtest can't see a number before it existed. None of this is exotic, but it's also not a weekend project if you want it PIT-correct rather than just "mostly right."

Where Tradevo Data Fits

Tradevo Data exists for the middle case: you want SEC-sourced, point-in-time-correct annual fundamentals — Revenue, NetIncome, Assets, StockholdersEquity, OperatingCashFlow, EPSDiluted, DilutedShares, up to 12 fiscal years — across 5,193 US companies (313,001 rows), without building the EDGAR pipeline yourself or paying for a full institutional-grade platform. The $49/mo plan includes the full bulk /v1/download, the whole-universe /v1/snapshot?as_of cross-section, and the /v1/fundamentals?ticker&as_of JSON endpoint (5,000 requests/day), with a Stripe checkout that issues a key instantly. Cancel anytime. Docs are at /docs.

This is a budget tier of research-grade PIT data — not a claim to be the only cheap option, and not a promise about what it will do for your returns.

Try Before You Subscribe

The free sample — 40 companies, 3,280 rows, full methodology, no signup — is on GitHub: github.com/christianpichichero-max/pit-fundamentals. It's the same schema, same first_filed/original_value/restated logic, just smaller. If the filing-deadline mechanics above are new to you, the deeper walkthroughs are at /blog/lookahead-bias-fundamental-backtests and /blog/point-in-time-fundamentals-data.

If the schema fits your backtests, the full dataset is at tradevodata.com/?ref=blog. If you're still comparing PIT vendors, tradevodata.com/?ref=alt lays out the options side by side.

Not investment advice; verify competitor pricing yourself.

We Shipped a 10x Error on General Mills. Here's the Bug, and the Check That Would Have Caught It.

Christian Pichichero — Tue, 04 Aug 2026 19:38:46 +0000

On 2026-08-03 our API was serving General Mills' FY2024 revenue as $2.038 billion. The real figure is $19.857 billion. We were wrong by an order of magnitude on an S&P 500 company, for weeks, and every automated check we had said the data was fine.

This is the post-mortem. It is worth reading if you build anything on SEC XBRL, because the root cause is not exotic — it is the most natural way to write the code, and it is wrong.

What the filing actually says

General Mills tags two different numbers in the same 10-K for the same period:

XBRL element	FY2024 value
`Revenues`	$2,037,800,000
`RevenueFromContractWithCustomerExcludingAssessedTax`	$19,857,000,000

Both come from SEC's own companyconcept API. Neither is a mistake by the filer. Revenues here is a component; the consolidated top line lives under the ASC-606 element.

We picked Revenues.

Why we picked the wrong one, and why it was defensible

Our tag resolution used a static priority list, with Revenues ranked first. That ordering was itself a fix. Earlier, we had ASC-606 contract revenue ranked above Revenues, and it produced this:

MetLife FY2024 — served at $2.2B against a true $71.0B
Capital One — 85% low
AvalonBay — 99.8% low, for eight consecutive years

For insurers, REITs and card issuers, contract revenue is a small slice and Revenues is the real total. So we promoted Revenues, verified MetLife came out right, and shipped.

That fix was correct for MetLife and catastrophically wrong for General Mills — because there is no single XBRL element that is the consolidated top line for every filer. Revenues is the total for an insurer and a minor component for a consumer-goods company. Any fixed ordering serves one and betrays the other.

We had traded one class of error for another, and we could not see it, because we validated the fix against the company that motivated it.

Why nothing caught it

This is the part worth generalising. We had four automated gates:

a claims check comparing published site copy to the database
a minimum-row-count guard against truncated builds
endpoint smoke tests
an invariant scan for internal consistency

Every one of them asks "is this data consistent with itself?" None asks "is this number correct?"

$2.038 billion is internally consistent. It is correctly dated, plausibly sized for a public company, sourced from a real XBRL element in a real filing, and it passes every range check. It looks exactly like money. There is no internal signal that separates it from the right answer.

We even had a flag firing. The row carried qa_status = FLAG:ambiguous_tag, which our engine sets when another element in the same filing reports materially more. The system detected the ambiguity and published the smaller number anyway. Detecting is not deciding.

The second bug, which was worse

While fixing the first, we found that our bank-revenue path had been silently broken for months.

Banks frequently tag no single total-revenue element, so we synthesise one: net interest income plus noninterest income, the standard definition. That code computed Fifth Third's FY2023 revenue correctly at $8.708B. Then it stamped the value with the wrong filing date — 2026-02-24 instead of 2024-02-27 — because of this:

nii = {p["end"]: p for p in annual_points_for_tag(...)}

A dict comprehension keeps the last entry per key. SEC reports the same period across many filings, so the last one is the most recent re-filing. The synthetic bank total therefore always looked like it was filed years late.

Our selection logic picks the earliest-filed candidate, on purpose — that is the point-in-time discipline. So the correct bank total always arrived "late" and lost to the fee-income tag it existed to replace. The fix computed the right answer and threw it away, every single time. Fifth Third kept publishing $0.577B against a true $8.708B.

One line, and it silently reversed the outcome of a fix everyone believed had shipped.

The check that would have caught both

The missing piece was not more tests. It was one test of a different kind: compare the data to something outside itself.

node scripts/verify-against-sec.mjs

For a sample of served values, it asks SEC's companyconcept API for every candidate revenue element the filer reported for that exact period, and asserts that what we serve is the consolidated total rather than a component of it. It deliberately does not reuse our tag-selection logic — otherwise it would reimplement the bug and agree with itself.

Run against the broken data, it printed:

WRONG GIS FY2024: serving $2.038B vs SEC $19.857B — 10.3% of the total
WRONG GIS FY2023: serving $1.957B vs SEC $20.094B —  9.7% of the total
WRONG PG  FY2014: serving $29.400B vs SEC $83.062B — 35.4% of the total

It now runs on every data refresh and fails the build. A gate that cannot catch its own motivating case is decoration, so we proved it fired before shipping it.

The actual fix

We stopped ranking elements and started comparing them. Every tag in our candidate list is intended to be a consolidated total — the gross-overstating ones are explicitly excluded — so when two candidates in the same filing disagree materially, the larger is the total and the smaller is a component of it. That rule gets MetLife and General Mills right simultaneously, which no fixed ordering can.

The regression test keeps them in the same file, deliberately, because they pull in opposite directions.

What this cost, and what changed

Wrong values reached the paid API and the free sample. P&G FY2014 shipped at $29.4B against a true $83.1B in the public CC0 file — the one our own pricing page tells prospects to verify against.

All of it is corrected now: General Mills at $19.857B, P&G at $83.062B, Fifth Third at $8.708B, M&T at $9.279B, MetLife still right at $70.986B. Roughly 320 values across all seven concepts have since been checked against SEC's API with zero mismatches.

Three things we would tell anyone building on XBRL:

There is no universal top-line element. Any static tag priority is wrong for some filer. Compare magnitudes within the filing instead of trusting an order.
Detecting an ambiguity is not resolving it. We flagged the row and published it anyway. If your system knows something is uncertain, decide what to do about it.
Self-consistency is not correctness. Every gate we had compared the data to itself. Wrong numbers pass those effortlessly, because wrong numbers are usually well-formed. Something in your pipeline has to compare against the outside world.

We would rather publish this than have you find it. The free sample is 40 large caps, {{sampleRows}} point-in-time rows, CC0, no signup — github.com/christianpichichero-max/pit-fundamentals — and the methodology is public specifically so it can be attacked.

Not investment advice.

As-Reported vs Restated Financial Data: Why the Difference Matters for Backtesting

Christian Pichichero — Wed, 29 Jul 2026 16:54:14 +0000

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.

How to Detect Lookahead Bias in a Backtest: A Practical Checklist

Christian Pichichero — Wed, 08 Jul 2026 17:03:29 +0000

Lookahead bias in a fundamentals backtest almost never announces itself. It shows up as a backtest that looks unusually good, and then a live strategy that quietly stops working. The mechanism is boring: your join used a date the data wasn't actually public yet. This article is a checklist for finding that, not a pitch for a particular dataset — though we'll use our own free sample to show working code, because it's the one we can show you column-by-column without asking anything of you.

This is not investment advice. Nothing here promises a better-performing backtest — only a more honest one, with fewer joins that leak future information into the past.

Symptom 1: Your signal times earnings suspiciously well

If a fundamentals-driven signal enters positions right before earnings-driven price moves with better-than-random timing, check what date you used to decide the fundamental was "known." A common bug: joining on fiscal period end date (e.g., Q4 2019 = 2019-12-31) instead of the date the 10-K was actually filed and made public. Every company reports its fiscal year end weeks to months before the filing exists. If your backtest thinks Q4 data is available on the period end date, it's trading on the future.

Symptom 2: Live performance decays right after paper trading ends

This is the classic tell. A strategy backtests clean, goes live (or into a genuinely walk-forward paper test), and the edge shrinks or disappears. If the strategy relies on fundamentals and nothing else changed — no regime shift, no capacity issue — lookahead bias in the historical joins is the first thing to rule out, because live trading is the one environment where lookahead is structurally impossible.

Symptom 3: Performance is fragile to a few outlier dates

Run your equity curve breakdown by trade. If a disproportionate share of PnL comes from trades placed in a narrow window around known reporting seasons, and those specific trades have unusually strong hit rates, look at whether the fundamental value used in the join was restated later and your backtest is silently using the restated number instead of what was originally reported.

The Join-Date Audit

The fastest way to check: pull your actual join logic and ask, for every fundamental value, "what date did my code think this became true?" Then compare that to the date it was actually filed. Two dates get confused constantly:

Fiscal period end — when the reporting period closed (always in the past relative to filing)
First filed date — when the 10-K (or 10-K/A) hit EDGAR and became public

If your pipeline uses the former where it should use the latter, you have a lookahead bug baked into every single row, sized to the actual filing lag for that company and quarter.

A pandas check using first_filed

Our free PIT sample (40 companies, 3,212 rows, no signup) includes a first_filed column specifically so you can run this check yourself. Example:

import pandas as pd

df = pd.read_csv("sample.csv", parse_dates=["first_filed", "fiscal_period_end"])

def check_leakage(df, as_of_date, join_col="fiscal_period_end"):
    as_of = pd.Timestamp(as_of_date)
    naive_join = df[df[join_col] <= as_of]        # what a naive backtest would include
    correct_join = df[df["first_filed"] <= as_of]  # what was actually public by as_of
    leaked = naive_join[~naive_join.index.isin(correct_join.index)]
    return leaked

leaked_rows = check_leakage(df, "2020-03-31")
print(f"{len(leaked_rows)} of {len(df)} rows would be lookahead-leaked "
      f"if you joined on fiscal_period_end instead of first_filed")

If leaked_rows is non-empty for a realistic as_of date, your naive join is including fundamentals before they existed publicly. Swap the join key to first_filed (or whatever your data vendor's equivalent "became public" field is called) and rerun.

The Lag-Shift Test

A second, independent check that doesn't require inspecting your join code line by line: shift your as_of date backward by a fixed number of days across your entire backtest — say 30, 60, 90 days — and rerun. If performance is fairly stable under small shifts, that's a decent sign your logic isn't sitting right on a knife's edge of leaked information. If performance craters the moment you shift even slightly earlier, your original result was likely dependent on data being available earlier than it should have been. This is a blunt instrument, not proof, but it's cheap to run and catches a lot of accidental lookahead.

For deeper background on why this matters mechanically, see lookahead bias in fundamental backtests and our overview of point-in-time fundamentals.

Comparing Your Options for Fixing It

Approach	Effort	Coverage	Cost	Best for
Scrape EDGAR yourself, track filing dates	High	Whatever you build	Your time	Teams needing full control, custom concepts, or non-US data
Research-grade PIT vendors (e.g. Sharadar, Tiingo, QuantConnect)	Low	Broad, often quarterly + more concepts	See their pricing pages	Funds/teams needing quarterly data, longer history, or bulk delivery — this is genuinely where they win over us
Tradevo Data	Low	5,214 US companies, 7 concepts, annual only, up to 12 fiscal years	$49/mo	Individual quants who need PIT-safe annual US fundamentals cheaply, via API
Free PIT sample (GitHub)	Low	40 companies, 3,212 rows	Free	Prototyping the join logic and running the checks in this article before paying for anything

We're not the only affordable option, and we're not claiming to be — the vendors above are credible and some cover more ground (quarterly data, longer history, bulk delivery). See their pricing pages directly since we won't quote numbers we don't control.

When to Build It Yourself (or Use Someone Else)

Being honest about where Tradevo Data isn't the right tool — and where the vendors above genuinely win:

You need quarterly fundamentals. We're annual-only (10-K + 10-K/A). Quarterly PIT logic is a roadmap item, not shipped. A vendor with quarterly coverage wins here.
You need non-US equities. We're US-only, sourced from SEC EDGAR. A vendor with international coverage wins here.
You need more than 7 concepts, or line items beyond Revenue, NetIncome, Assets, StockholdersEquity, OperatingCashFlow, EPSDiluted, and DilutedShares.
You need bulk Parquet delivery for a data lake — we're a single JSON endpoint (/v1/fundamentals), rate-limited to 5,000 requests/day, which is fine for iterative backtesting but not for a nightly full-universe dump.
You're already comfortable parsing EDGAR filings directly and tracking first_filed yourself — that's a legitimate, free path if you have the engineering time, and it's exactly what our free sample's methodology documents.

If none of those apply and you just want a point-in-time-safe first_filed/original_value pair for US annual fundamentals without building the EDGAR pipeline yourself, that's the actual use case we built for.

Try It Before You Pay for Anything

Start with the free sample — 40 companies, full methodology, no signup — and run the join-date audit and lag-shift test above on your own logic. If it holds up and you want the full 5,214-company, 313,562-row dataset with first_filed, original_value, latest_value, and restatement flags via API, it's $49/mo at Tradevo Data, instant key after checkout, cancel anytime, docs at /docs.

If you're actively comparing PIT data providers, our alternatives page lays out where we fit and where we don't.

Not investment advice; verify competitor pricing yourself on their own pricing pages.

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.