Point-in-Time Financial Data: What Did Investors Actually Know at the Time?

What is point-in-time financial data?

Point-in-time financial data answers:

That is different from asking:

Consider a company that reported $100 million of revenue in an original filing and later restated the same period to $95 million.

A current historical database may reasonably show:

Revenue = $95m

A point-in-time query run before the restatement should return:

Revenue = $100m

Neither query is inherently wrong; they answer different questions.

This is why point-in-time data is sometimes described as requiring two notions of time:

• when the economics occurred;
• when the information was known.

For financial filings, that second timeline can become surprisingly complicated.

The two clocks: economic time and knowledge time

A financial fact normally has an economic period.

For a duration fact:

Revenue
Jan. 1 → Mar. 31

For an instant fact:

Deferred revenue
as of Aug. 31

That tells us what period the fact describes.

It does not tell us when investors learned it.

A second timeline tracks knowledge:

Quarter end
    ↓
earnings release
    ↓
10-Q / 10-K
    ↓
amendment
    ↓
later comparative
    ↓
restatement / recast

A robust historical system therefore needs to distinguish at least:

ECONOMIC TIME
period_start
period_end

KNOWLEDGE / FILING TIME
disclosure source
acceptance / availability
filing date
filing vintage
later revisions

The first clock tells you when the business activity occurred.

The second tells you when a market participant could have learned about it.

Period end is not information availability

Oracle's FY2026 first quarter ended on August 31, 2026.

Its 10-Q reports $30.789 billion of deferred revenue as of that date.

But the 10-Q was not filed until September 11, 11 days later.

A naïve database might store:

date = 2026-08-31
deferred_revenue = $30.789bn

and make the value available to every historical query from August 31 onward.

That silently implies that an investor knew the quarter-end deferred-revenue balance on the day the quarter ended.

The loaded SourceState evidence does not support that.

The economic observation is dated August 31.

The loaded disclosure arrived later.

Source: Oracle FY2026 Q1 Form 10-Q
SEC filing: Oracle 10-Q · Aug. 2026 period ↗

Filing date, acceptance time, and dissemination are not identical

Even "use the filing date" can be too simplistic.

EDGAR has rules governing when electronically transmitted submissions receive their official filing date.

The SEC states that if a live submission begins transmission at or before 5:30 p.m. Eastern Time and is accepted, it generally receives that day's filing date. Most live submissions begun after 5:30 p.m. ET receive the next business day's filing date and are not disseminated by EDGAR until that next business day.

SEC guidance:
SEC primary source ↗

That creates an important distinction among:

Raw acceptance timestamp
        ≠
Official filing date
        ≠
Necessarily the first public availability of every underlying fact

CoreWeave's Q1 2026 10-Q demonstrates the first distinction unusually clearly.

The SEC submissions record shows a raw acceptance timestamp of:

2026-05-07T23:21:42Z

which is 7:21 p.m. Eastern Daylight Time.

The filing itself carries:

Filed: May 8, 2026

That is consistent with the SEC's after-5:30 p.m. filing-date treatment for ordinary submissions.

So even if a database stores both values, they answer different questions.

The raw acceptance timestamp tells you when EDGAR accepted the submission.

The official filing date follows the SEC's filing-date rules, while EDGAR dissemination determines when the filing enters the public filing stream.

The CoreWeave timeline: headline results first, filing detail later

CoreWeave provides a nearly ideal point-in-time example because SourceState contains both its earnings 8-K and its periodic filing.

March 31: the economic period ends

Q1 2026 ends.

The quarter's revenue is ultimately reported as $2.078 billion.

But the loaded SourceState record does not establish that investors knew that amount on March 31.

May 7: headline results arrive

CoreWeave files an earnings 8-K.

The attached earnings release reports:

• revenue: $2.078 billion
• net loss: $740 million
• backlog: $99.4 billion

The SEC raw acceptance time is:

2026-05-07T20:10:37Z

or approximately 4:10 p.m. ET.

For SourceState's loaded sources, this is the earliest supported public source for the revenue figure.

May 8: the 10-Q adds more information

The 10-Q submission was accepted late on May 7, but under the SEC's after-cutoff rules it received a May 8 filing date and next-business-day dissemination treatment.

The filing contains the same revenue figure, but it also contains detail absent from the loaded earnings-release exhibit.

In Note 2, CoreWeave reports that its two largest customers represented 65% of Q1 revenue:

Customer A     45%
Customer B     20%

This gives us two distinct availability questions:

and:

Those answers need not be the same.

Different facts can become available at different stages of the disclosure process.

Sources:

• CoreWeave Q1 2026 earnings 8-K
  SEC primary source ↗

• Earnings release exhibit
  SEC primary source ↗

• CoreWeave Q1 2026 Form 10-Q
  SEC primary source ↗

The 10-Q is not always the first source

A common shortcut is:

That can be too late for headline financial results.

CoreWeave's FY2025 sequence makes this clear.

Its fiscal year ended December 31, 2025.

The earnings 8-K was accepted on February 26, 2026 and reported FY2025 revenue of $5.131 billion.

The 10-K followed on March 2, 2026.

Dec. 31
Fiscal year ends
    │
    ▼
Feb. 26
Earnings 8-K
Revenue known in loaded source
    │
    ▼
Mar. 2
10-K
Periodic filing arrives

So the rule:

information_date = 10-K filing date

can be wrong in the opposite direction from:

information_date = period end

One can be too early; the other can be too late.

But an earnings release does not contain the whole filing

The opposite mistake is to assume:

CoreWeave's Q1 customer-concentration disclosure shows why that is unsafe.

For the loaded SourceState sources:

Q1 revenue
Supported in earnings 8-K

Customer A = 45% of revenue
Earliest loaded SourceState support: 10-Q

Customer B = 20% of revenue
Earliest loaded SourceState support: 10-Q

There is an important qualification.

SourceState does not currently prove that the 10-Q was the first public disclosure anywhere of those concentration figures.

There may have been another public channel not ingested by the system.

So the precise statement is:

That distinction—between earliest supported source and true earliest public disclosure—is important in any serious point-in-time system.

A calendar date can still be too coarse

Assured Guaranty's FY2025 filings show why a date without time can lose useful ordering.

On February 27, 2026, the company had both a 10-K and an earnings 8-K.

The SEC submission timestamps were:

10-K
2026-02-27T13:35:20Z

Earnings 8-K
2026-02-27T13:43:24Z

They share the same filing date but were accepted roughly eight minutes apart.

A data model storing only:

2026-02-27

cannot preserve that sequence.

This does not mean every research workflow needs second-level timestamps.

But for intraday event studies, systematic earnings trading, same-day document sequencing, or strict information-set reconstruction, a date-only timestamp can be insufficient.

Sources:

• Assured Guaranty FY2025 10-K
  SEC primary source ↗

• Assured Guaranty earnings 8-K
  SEC primary source ↗

One fiscal period can have multiple valid filing vintages

Availability timing becomes more complicated when the historical number itself later changes.

Valeant's six months ended June 30, 2015 provides a clean example.

Version 1 — original filing

Filed July 28, 2015:

Revenue       $4.9233bn
Net income      $22.9m

Version 2 — later restated comparative

Filed August 9, 2016:

Revenue       $4.9025bn
Net income      $46.9m

The later filing states that the 2015 financial statements had been restated, including adjustments related to Philidor revenue recognition.

The correct historical query therefore depends on the knowledge date:

AS OF JULY 28, 2015

Use:
Revenue = $4.9233bn
Net income = $22.9m

while a latest-known query can return:

LATEST RESTATED HISTORY

Revenue = $4.9025bn
Net income = $46.9m

The same economic period has more than one valid database representation.

This defeats a data model built around:

(company, fiscal_period, concept) → one value

because the missing dimension is filing vintage.

Source: Valeant / Bausch Health 2016 Q2 Form 10-Q, Note 2
SEC primary source ↗

Latest-known history vs point-in-time history

This distinction deserves to be explicit.

Latest-known history

Ask:

For Valeant's 2015 comparative, use the restated figures.

For a company that later reorganized segments, use the recast segment history when you want a consistent current view.

Latest-known data is ideal for:

• current financial modeling;
• peer comparison;
• latest accounting history;
• current segment trend work;
• reconciliation to the newest filing.

Point-in-time history

Ask:

Use the original filing vintage until a later disclosure becomes available.

Point-in-time data is essential for:

• historical screens;
• event studies;
• factor backtests;
• systematic strategies;
• reconstructing analyst information sets;
• answering "what did investors know then?"

Those two query modes should not necessarily return the same answer.

Recasts create a different kind of future information

A point-in-time problem does not require the consolidated number itself to change.

Honeywell's FY2023 revenue remained $36.662 billion.

But its segment structure later changed.

Originally, the filing presented:

Aerospace                              $13.624bn
Home & Building Technologies             6.031bn
Performance Materials & Technologies    11.506bn
Safety & Productivity Solutions          5.489bn
Corporate & All Other                     0.012bn

The later filing recast FY2023 under a new segment presentation:

Aerospace Technologies                 $13.624bn
Industrial Automation                   10.756bn
Building Automation                       6.031bn
Energy & Sustainability Solutions         6.239bn
Corporate & Other                         0.012bn

Consolidated revenue did not change.

But the analytical structure available to an investor did.

If a backtest dated February 2024 uses the later segment definitions disclosed in February 2025, it is importing future organizational knowledge into the historical model.

That is look-ahead bias even though:

Total revenue before = total revenue after

Point-in-time data must therefore version structure, not only scalar values.

Sources:

• Honeywell FY2023 Form 10-K
  SEC primary source ↗

• Honeywell FY2024 Form 10-K with recast comparatives
  SEC primary source ↗

An amendment does not automatically create a new financial value

Amendments create another common temporal trap.

Assured Guaranty's Q2 2011 10-Q/A actually changed financial facts.

For example:

Total assets

Original 10-Q       $19.238864bn
10-Q/A               19.299825bn

The amendment corrected intercompany eliminations involving financial-guaranty variable-interest entities and insurer subsidiaries.

So in that case, the amended filing genuinely creates a later financial-data vintage.

But Devon's FY2025 10-K/A is a useful counterexample.

Its amendment added Part III Items 10–14 and certifications.

The explanatory note stated that it did not update the other information in the original filing.

No financial-statement fact needs to become a new value merely because:

form = 10-K/A

The correct logic is:

Sources:

• Assured Guaranty Q2 2011 original 10-Q
  SEC primary source ↗

• Assured Guaranty Q2 2011 10-Q/A
  SEC primary source ↗

• Devon FY2025 10-K/A
  SEC primary source ↗

Six naïve timestamp rules—and why they fail

Point-in-time errors often come from reasonable-looking shortcuts.

Rule 1: Make every fact available on period_end

Fails.

CoreWeave's Q1 period ended March 31.

The loaded headline results arrived in May.

Using March 31 creates future knowledge.

Rule 2: Make every fact available at midnight on filing_date

Can fail.

A filing date does not encode intraday order.

It can also differ from raw SEC acceptance timing under EDGAR filing-date rules.

CoreWeave's 10-Q carries a May 8 filing date despite a May 7 raw acceptance timestamp after the normal 5:30 p.m. ET cutoff.

Rule 3: Keep only the latest value for each fiscal period

Fails for point-in-time work.

Valeant's 2015 historical revenue and net income changed after restatement.

Keeping only the later values erases what was originally public.

Honeywell's segment structure changed even though consolidated revenue did not.

Rule 4: Assume the 10-Q or 10-K is always the first disclosure

Fails.

CoreWeave's earnings 8-K disclosed headline revenue before the periodic filing.

Rule 5: Treat every amendment as a new financial value

Fails.

Assured Guaranty's amendment changed financial statements.

Devon's later 10-K/A did not.

The form suffix alone is insufficient.

Rule 6: Store only YYYY-MM-DD

Can fail when sequencing matters.

Assured Guaranty's 10-K and earnings 8-K have the same filing date but different SEC acceptance timestamps.

A date-only field loses that order.

Why this matters for backtests

Look-ahead bias is usually described with an obvious example:

Financial fundamentals create subtler versions of the same error.

Error 1 — period-end leakage

A model receives March-quarter fundamentals on March 31 even though the company does not report them until May.

Error 2 — latest-value leakage

A backtest uses a later restated number instead of the number investors originally saw.

Error 3 — structural leakage

A historical segment model uses a segment organization that was not created until a later year.

Error 4 — disclosure-detail leakage

The model assumes every footnote fact was available when headline earnings were released.

Error 5 — intraday sequencing leakage

Two documents filed the same day are treated as simultaneous even when one precedes the other.

Timing can also be strategy-relative. CoreWeave's earnings 8-K was accepted at about 4:10 p.m. ET. For a strategy whose decision point is the regular 4:00 p.m. close, that disclosure is future information for that day's close even though it became available later the same calendar day.

A clean backtest therefore needs more than:

ticker
period
value

It needs an information set—and a clearly defined decision timestamp.

What a point-in-time financial record needs

At minimum, the system should distinguish several classes of metadata.

Economic period

period_start
period_end
instant / duration

Source identity

form
accession
document
source location

Filing / availability metadata

filing_date
acceptance_datetime, where available
source-specific availability

Version identity

original filing
later comparative
amendment
restatement
recast

Fact identity

concept
reported label
value
unit
dimensions

Conceptually:

FACT
Revenue = $2.078bn
       │
       ├── Economic period
       │      Jan. 1 → Mar. 31
       │
       ├── Source
       │      Earnings 8-K
       │
       ├── Source availability
       │      May 7
       │
       ├── Later periodic filing
       │      10-Q
       │
       └── Later vintages
              amendments / restatements / recasts

A point-in-time query then becomes:

That is very different from:

How SourceState currently handles temporal history

SourceState already preserves several pieces needed for point-in-time financial data.

Currently stored

• period_start and period_end where applicable;
• filing date, at date granularity;
• accession number;
• periodic filing form;
• amendment flag;
• accession-specific facts and filing snapshots;
• source anchors / document positions for part of the fact set.

That accession-level preservation is important because original and later filing vintages are not silently collapsed into one physical record.

For example, the original Valeant filing and later restated comparative remain separate accession-specific fact sets.

Currently not stored as universal structured fields

The reviewed SourceState schema does not currently store:

• SEC acceptance_datetime;
• a universal original → restated → recast version chain;
• a structured restated/recast status on every fact;
• a universal earliest_information_availability timestamp.

Acceptance timestamps used in this article were obtained from SEC submission records rather than SourceState's financial filing schema.

SourceState also contains some 8-K event records and attached exhibits, which can establish earlier supported disclosure for cases such as CoreWeave. But that does not prove capture of every public dissemination channel.

So the careful statement today is:

That distinction matters.

Point-in-time integrity is not created by labeling a dataset "PIT."

It comes from preserving enough source and version information to reconstruct what was actually knowable.

The simplest way to think about point-in-time data

A normal historical query asks:

A point-in-time query asks:

Those questions can return different answers.

Likewise:

can mean:

or:

Point-in-time financial data exists to preserve that distinction.