← Quantery Blog

How much reporting lag should a backtest use?

September 19, 2026 · 8 min readbacktestingreporting-lagmethod

A backtest should use the shortest reporting lag that matches when its inputs could have reached the decision process. For SEC filing data, one day after the filing date is a defensible baseline. Then re-run with longer lags to find out whether the result depends on implausibly fast ingestion. The filing date sets the first possible moment. Your process sets the usable moment.

Don't substitute the fiscal period end or the statutory filing deadline. A quarter can end weeks before its report appears, and the deadline says only how late a filer may ordinarily submit. Build the signal from the actual filing date, add the delay your process needs, and enter no earlier than the next available close. That's the clean sequence.

What does reporting lag mean in a backtest?

Reporting lag is the delay between a public filing and the first simulated decision allowed to use it. If a report lands on date F and the thesis has a lag of L days, the new statement values stay invisible until F + L.

That delay solves a different problem from point-in-time storage. A point-in-time dataset preserves what was filed and when. Reporting lag decides when your simulated process could have consumed it. You need both. Perfect filing history with zero processing time can still flatter a strategy that nobody could have run as modeled.

There are three clocks to keep separate:

• The period end says which business interval the statement describes.
• The filing date says when the document became public through EDGAR.
• The decision date says when your rules may first act on it.

The first clock is an accounting label. It isn't a publication timestamp. Trailing versus forward numbers covers why period dates can't be used as knowledge dates. This article deals with the smaller gap after publication, where a test can still assume too much speed.

Consider a real sequence. Microsoft's fiscal year ended on June 30, 2026, and its Form 10-K was filed on July 29, according to the company's SEC submissions record. A backtest using the annual figures on June 30 has looked ahead by almost a month. A same-day July 29 signal may avoid that obvious error, yet it still assumes the document entered the dataset, the fields were mapped, the thesis ran, and a trade became executable before the chosen fill.

Why aren't filing deadlines enough?

Filing deadlines tell you the outer boundary for an on-time report. They don't tell you when a particular report arrived. The SEC's Form 10-K instructions give large accelerated filers, accelerated filers, and other registrants different annual deadlines. The corresponding Form 10-Q instructions use different quarterly deadlines by filer class. A deadline-based estimate therefore adds a classification problem before it even reaches the backtest.

It also throws away information you already have. EDGAR records the filing date for the actual document. If a company files before its deadline, pretending the report arrived only on the deadline makes the test unnecessarily stale. If it files late, a calendar estimate admits data that wasn't public.

Late notices make the shortcut worse. Form 12b-25 provides a separate notification path when a periodic report can't be filed on time. A rule that infers availability from fiscal calendars won't know whether the filing arrived early, on time, or under that late-filing process. Use the event that happened.

Publication also has an intraday edge. The SEC's EDGAR Filer Manual says ordinary direct transmissions begun after 5:30 p.m. Eastern Time receive the next business day's filing date, while a limited set of forms has exceptions. A daily backtest shouldn't pretend to possess a clean intraday ordering it doesn't store. Treat the recorded filing date as the public boundary, add a full-day lag, and let the next-close entry rule provide another separation between observation and fill.

This is conservative on purpose. It may delay a document that was available early in the day. That costs some apparent performance if markets react fast. Good. A daily test can't claim an intraday edge without intraday evidence.

How long should the lag be?

Start from the process you are trying to model.

A systematic pipeline that downloads EDGAR filings after the market closes, maps standardized facts, validates them, and runs overnight can reasonably test a one-day lag. A person who reads footnotes before changing a thesis needs longer. A workflow built from vendor-normalized fundamentals may need several days if the vendor's historical availability timestamps aren't preserved.

The right answer isn't one universal number. It's a documented service level for the research process. Write down what must happen between publication and decision:

1. The filing becomes public.
2. The source is collected and parsed.
3. Required fields pass validation.
4. The thesis is evaluated.
5. The resulting order can reach its modeled fill.

Ask which of those steps your historical data can prove. If you only have a filing date, day-level precision is the most you own. If your workflow sometimes waits for a manual review, model that delay too. Don't grant the historical simulation an automation stack you don't operate now.

There's another useful distinction. A data lag delays every newly filed value before a thesis can see it. A trading lag delays the fill after the signal exists. One doesn't replace the other. The data lag prevents a filing from entering the decision too soon. The trading lag prevents a signal computed at a close from buying at that same close.

Quantery separates those choices. In an illustrative thesis, the backtest block looks like this. The bundled templates are the reference for exact fields, and the Quantery thesis documentation covers the full structure.

# Filing availability and execution: illustrative
backtest:
  rebalance: monthly
  reporting_lag_days: 1
  entry: next_close
  exit:
    max_hold_months: 12
    on_gate_fail: true
  benchmarks: [SPY]

reporting_lag_days controls when fundamentals become visible. entry: next_close controls when a new qualification can be filled. Keep both explicit. A monthly rebalance doesn't make the lag irrelevant either. A filing that arrives near the rebalance boundary can fall into this month's decision or the next one, which can change the selected cohort.

How do you test whether the result depends on speed?

Run a lag ladder: keep the thesis, universe, dates, rebalance cadence, and benchmark fixed, then change only the reporting lag. Start with the shortest delay your process can defend. Add a slower automated case and a manual-review case.

The exact ladder should match your workflow. Round assumptions are enough. The purpose isn't to discover the lag with the best return. It's to learn what kind of process the thesis requires.

Compare more than the ending equity curve:

• Which qualification events move to a later rebalance?
• Which events disappear because another filing arrives first?
• Does the direction of excess return survive?
• Do drawdown and turnover change materially?
• Is one short market window carrying the difference?

Keep every return labeled hypothetical and before costs. Longer lag doesn't automatically make a result more credible. It tests one source of sensitivity. The usual problems remain: reconstructed historical universes, missing prices, sector concentration, and thresholds chosen after seeing the answer. How to tell if a backtest result is real gives the broader one-dial-at-a-time method, while choosing the right benchmark deals with the baseline.

Read the lag ladder as a capacity claim. If a thesis works with a one-day delay and fails with a modestly slower pipeline, it may be a speed-dependent event strategy wearing fundamental clothes. That doesn't prove the faster result is false. It says the result belongs to a process with strict operational requirements.

If the conclusion holds across slower settings, you've learned something better. The thesis appears to rely on the filed business information after it becomes broadly usable. It doesn't require being first through the door. You can spend less time defending a timestamp and more time testing the economic claim.

What does reporting lag fail to fix?

A lag can't repair bad source dates. If a dataset keys a fact to quarter end, adding a few days leaves the report weeks too early. Fix the point-in-time history first.

It can't recover a vendor's lost publication history. A database that overwrites old values with later restatements is still looking ahead after you delay it. What makes a backtest honest explains why first-reported values matter.

A lag also can't prove that your parser handled the filing correctly. Companies use extensions, amended reports, and issuer-specific tags. Missing fields shouldn't become zeros or passing scores. The thesis needs a null policy, and the run needs coverage checks.

Finally, a lag doesn't model market impact or trading friction. A next-close fill is a convention, not a promise that every selected security could be bought at that printed price. Thin names, high turnover, and crowded release windows make excluded costs more important.

The useful standard is reproducible restraint. Record the filing date. Choose a delay your present process can meet. Fill after the signal. Then slow the clock and see whether the idea survives. Quantery makes that assumption visible in the thesis, so it stays yours to inspect, change, and re-test.

Want to try this on your own rules? Quantery is free for 14 days: the full app, no card required.

← All articles