What point-in-time fundamental data is, and why backtests need it

A point-in-time fundamentals dataset can answer the question: what did this company’s financial statements say, as far as anyone could know, on a given date? Two conditions follow from it. A figure must not be returned for a date before the filing that contains it became public. And when a figure was later amended or restated, the original must still be returned for dates before the amendment.

Many financial APIs answer a different question: what is this number now? That is the right answer for a current screen and the wrong one for a historical test, because it quietly mixes in information from after the date being studied.

On February 28, 2025, Axon Enterprise reported total current liabilities of $997,586,000 for fiscal 2024, giving a current ratio of 2.30x. On May 7 it filed an amendment that moved $680,289,000 of convertible notes from long-term into current liabilities. The same line became $1,677,875,000, and the current ratio fell to 1.37x.

Nobody had made an arithmetic error, and both figures are correct as filed. But a dataset that keeps only the second one cannot say what a model saw in March 2025, so a backtest run then cannot be reproduced now, and nothing in the data shows that an input changed.

A point-in-time dataset keeps both versions, each with the filing it came from. Arche records a restatement as a new version, never overwrites the previous one, and computes the per-metric difference between them. See how Arche handles financial restatements.

Look-ahead bias is using information in a historical simulation that was not available when the simulated decision was made. With fundamentals it has two common sources:

• Filing lag. A fiscal period ends weeks or months before its 10-K or 10-Q is filed. A figure dated to its period end appears in the data before anyone could have read it, so every signal built on it trades on foresight.
• Restatement back-fill. When a dataset overwrites an original figure with a later correction, the corrected figure appears for dates on which only the original existed.

The fixes are different. Filing lag needs the date each filing became public, and a query boundary that respects it. Restatement back-fill needs every version preserved, and a rule for which version was current on any date. Arche resolves as-of queries using the time the SEC accepted each filing, and keeps every version.

GET https://api.arche.fi/v1/edgar/as-of/2024-01-01/financials/0000320193

A universe built from companies that exist today leaves out every company that was delisted, acquired, taken private or went bankrupt during the test period. The backtest then only ever selects from survivors, and its results are biased in a direction you cannot see from inside them.

Avoiding it requires a dataset that retains companies after they stop filing. Arche retains delisted, acquired and taken-private registrants, and they stay queryable.

As-reported asks what the filer originally said about each period. As-of asks what was knowable on a particular date, which includes restatements that had already been filed by then. They are different questions with different answers. In Arche’s time-series routes, as_reported=true answers the first and as_of_date answers the second, and they can be combined. See the time series documentation.

1. Can I query a date, and is the boundary the date the filing became public or the fiscal period end?
2. After a restatement, can I still retrieve the originally reported figure?
3. Can I see which filing a given value came from?
4. Are companies that stopped filing still in the dataset?
5. Will the same historical query return the same result next year?

Arche’s answers are in the concepts and versioning documentation. For the full list of questions to ask any provider, see how to choose a point-in-time fundamentals API.