How to Trace a Financial Number Back to an SEC Filing

What does financial-data lineage mean?

Financial-data lineage is the chain connecting an analytical value back to the disclosure that supports it.

At its simplest:

ANALYTICAL VALUE
        ↓
REPORTED FACT
        ↓
SOURCE FILING

But serious financial reporting usually requires more detail.

A stronger chain looks like:

STANDARDIZED CONCEPT
        ↓
AS-REPORTED LABEL
        ↓
XBRL CONCEPT
        ↓
CONTEXT / DIMENSIONS
        ↓
FILING ACCESSION
        ↓
DOCUMENT
        ↓
SOURCE OCCURRENCE

And in some cases:

DERIVED VALUE
        ↓
COMPONENT FACTS
        ↓
EACH COMPONENT'S SOURCE

or:

CURRENT HISTORICAL VALUE
        ↓
LATER FILING VINTAGE
        ↓
ORIGINAL HISTORICAL VALUE
        ↓
ORIGINAL FILING VINTAGE

The objective is not simply to prove that a number exists somewhere in EDGAR.

It is to preserve enough information to understand why this particular number is the right observation for the question being asked.

A filing URL is not enough provenance

A citation to a 10-K is useful, but it is not necessarily sufficient.

Amazon's FY2025 consolidated net sales appear multiple times in the same filing. SourceState records the same consolidated fact at four stored positions in amzn-20251231.htm:

189
1445
1488
1507

The underlying concept, value, period, unit, and context are the same.

The filing repeats the total across the face statement and supporting disclosures.

So:

Source = Amazon FY2025 10-K

identifies the document.

It does not identify the intended occurrence.

This becomes even more important when nearby facts use the same broad financial concept but describe something different.

The same Amazon filing contains:

Product sales           $296.266bn
Service sales            420.658bn
North America            426.305bn
International            161.894bn
AWS                      128.725bn

All of those facts are revenue.

None of them is the consolidated $716.924 billion total by itself.

Source: Amazon FY2025 Form 10-K
SEC filing: Amazon FY2025 10-K ↗

Step 1: standardized concept

For cross-company research, analysts often work with standardized concepts such as:

Revenue
NetIncome
TotalAssets
Cash
Debt
OperatingCashFlow

That layer is useful because companies do not always report the same economic concept using the same label or XBRL concept.

For example:

Amazon FY2025

Reported label:
"Total net sales"

XBRL concept:
us-gaap:RevenueFromContractWithCustomerExcludingAssessedTax

SourceState standardized concept:
Revenue

DXC FY2026

Reported label:
"Revenues"

XBRL concept:
us-gaap:Revenues

SourceState standardized concept:
Revenue

Different reported labels.

Different XBRL concepts.

Same SourceState analytical concept.

That standardized layer makes comparison possible.

But the normalized field should remain connected to the observation it came from.

Otherwise, a user can see:

Revenue = $X

without knowing how the company actually reported it.

Sources:

• Amazon FY2025 10-K
  SEC filing: Amazon FY2025 10-K ↗

• DXC FY2026 10-K
  SEC primary source ↗

Step 2: preserve the as-reported label

The reported label matters because it preserves management's presentation.

Amazon did not label the row simply:

It reported:

That distinction may not change the standardized concept, but it remains useful evidence.

The as-reported label helps an analyst answer:

• How did management describe the line?
• Is the normalized concept broader or narrower than the company's language?
• Did the reported label change over time?
• Does a peer use different terminology?
• Is the field a total, subtotal, or company-specific category?

Standardization should therefore add a common analytical layer without erasing the company's own presentation.

A useful lineage record can preserve both:

STANDARDIZED
Revenue

AS REPORTED
Total net sales

The first supports comparability.

The second supports interpretation and reconciliation.

Step 3: keep the XBRL concept

The XBRL concept gives the fact machine-readable accounting identity.

For Amazon's consolidated FY2025 revenue:

us-gaap:RevenueFromContractWithCustomerExcludingAssessedTax

For DXC's FY2026 revenue:

us-gaap:Revenues

This matters because labels alone are unreliable identifiers.

Two issuers can use different labels for comparable facts.

Two facts can also display similar labels while having different concepts, contexts, or statement roles.

The XBRL concept is therefore an important part of the evidence chain.

But it is not enough on its own.

The same concept can appear many times in one filing.

That is where context becomes essential.

Step 4: context determines what the fact actually means

Amazon's FY2025 filing uses the same revenue concept for several different observations.

Consolidated

Revenue
$716.924bn

Context:
FY2025
no dimensions

Product sales

Revenue
$296.266bn

ProductOrServiceAxis
→ ProductMember

Service sales

Revenue
$420.658bn

ProductOrServiceAxis
→ ServiceMember

AWS

Revenue
$128.725bn

StatementBusinessSegmentsAxis
→ AmazonWebServicesSegmentMember

Same broad concept.

Different context.

That difference is not incidental metadata.

It is what tells you whether the number is:

• the whole company;
• a product/service category;
• a segment;
• another dimensional slice.

This is why selecting a fact by XBRL concept alone can produce a perfectly sourced but financially wrong answer.

A concrete failure mode

Suppose an agent searches Amazon's filing for:

RevenueFromContractWithCustomerExcludingAssessedTax

and retrieves:

$128.725bn

The number is real.

The concept is real.

The filing citation is real.

But if the agent answers:

the answer is wrong.

It found AWS segment revenue, not consolidated revenue.

Step 5: filing identity matters

A fact should remain linked to the filing that supplied it.

At minimum:

form
filing date
accession number
document

For Amazon:

Form:
10-K

Filed:
February 6, 2026

Accession:
0001018724-26-000004

Document:
amzn-20251231.htm

The accession number is especially useful because it identifies the filing vintage.

That becomes critical when historical values are later:

• amended;
• restated;
• recast;
• reclassified;
• repeated in later comparative filings.

A fiscal period alone does not uniquely identify its historical representation.

Step 6: trace to the source occurrence

Document-level provenance gets you to the filing.

Source-position lineage gets you closer to the actual evidence.

For Amazon's consolidated FY2025 total net sales, SourceState stores an anchor at position:

189

with the verified displayed value:

716,924

The filing's face statement labels the row:

For CoreWeave's Q1 2026 Customer A concentration fact, SourceState stores:

Document:
crwv-20260331.htm

Position:
380

Context:
c-62

Displayed value:
45

The filing location is Note 2, "Significant Customers."

This is the last-mile problem in financial-data provenance.

A filing URL tells the analyst:

A source anchor tells the analyst:

There is an important current limitation: SourceState does not have universally populated row-level anchors or human-readable table names for every fact. Source positions are internal document positions, not SEC page or line numbers.

So the honest distinction is:

FACT → FILING
strongly supported

FACT → DOCUMENT POSITION
supported for many facts

FACT → UNIVERSAL EXACT ROW/TABLE LABEL
partial

That is still materially stronger than a document-only citation.

Why the same correct number can appear several times

Amazon's $716.924 billion revenue total is a useful provenance edge case.

SourceState records four positions for the same consolidated fact:

189
1445
1488
1507

Why?

Because the same total appears in multiple parts of the filing.

A company can repeat the same number in:

• the face financial statements;
• a segment note;
• a revenue-disaggregation table;
• a geography disclosure;
• MD&A;
• another supporting schedule.

Those repetitions are not necessarily duplicate data errors.

They are multiple source occurrences of the same economic fact.

That creates two separate lineage questions:

Fact identity

Are these occurrences the same underlying observation?

Source occurrence

Which appearance should be shown to the user as evidence?

The first is a semantic problem; the second is a citation and presentation problem. A robust provenance system should preserve both.

For the Amazon example, SourceState knows the repeated document positions, but the current anchor record does not attach a human-readable table heading to every occurrence. The filing itself remains the authority for assigning each occurrence to a specific presentation.

When the label is the same but the meaning is different

CoreWeave provides an even sharper example.

In its Q1 2026 filing, SourceState records two facts labeled:

Both use:

us-gaap:ConcentrationRiskPercentage1

Both refer to the same company-specific customer member.

But they mean different things.

Customer A — revenue concentration

Value:
45%

Benchmark axis:
RevenueFromContractWithCustomerMember

Context:
c-62

Source position:
380

Customer A — accounts receivable concentration

Value:
39%

Benchmark axis:
AccountsReceivableMember

Context:
c-65

Source position:
383

The displayed label is the same.

The broad XBRL concept is the same.

The customer member is the same.

The benchmark dimension changes the meaning.

A weak citation system might answer:

A stronger evidence chain answers:

and preserves the benchmark dimension explaining why.

There is also a data-quality caveat: the filing text describes the receivables measure as of March 31, while the stored record currently carries a duration context through March 31. That context should be validated before using the fact as an instant balance-sheet observation.

That is exactly the kind of issue provenance makes inspectable.

Source: CoreWeave Q1 2026 Form 10-Q, Note 2 — Significant Customers
SEC primary source ↗

Footnote facts need lineage too

The face financial statements are often the easiest place to trace a number.

Many of the most investment-relevant facts live in the notes.

CoreWeave's Customer A example is one.

Its Q1 income statement tells you revenue.

The note tells you that one customer represented:

45% of that revenue.

The evidence chain is therefore:

REPORTED FACT
Customer A
45%

        ↓

XBRL
ConcentrationRiskPercentage1

        ↓

CONTEXT
MajorCustomersAxis
→ CustomerAMember

ConcentrationRiskByBenchmarkAxis
→ RevenueFromContractWithCustomerMember

ConcentrationRiskByTypeAxis
→ CustomerConcentrationRiskMember

        ↓

FILING
CoreWeave Q1 2026 10-Q
accession 0001769628-26-000222

        ↓

SOURCE
Note 2
"Significant Customers"
position 380

This is a much richer source citation than:

It tells the analyst what the percentage is measuring, which customer role it refers to, what filing supplied it, and where the disclosure appears.

That becomes increasingly important for facts such as:

• customer concentration;
• debt maturities;
• contractual commitments;
• revenue disaggregation;
• RPO/backlog;
• capex detail;
• segment metrics;
• legal contingencies;
• restructuring charges.

The more specialized the fact, the more important the evidence chain becomes.

Custom concepts should preserve their identity

Oracle's FY2026 filing includes:

Reported label:
Cloud

Custom XBRL concept:
orcl:CloudRevenues

Value:
$33.989bn

SourceState does not assign this observation a standardized concept.

It does, however, preserve a broader ancestor relationship to the standard revenue concept.

That distinction matters.

The evidence chain should not silently rewrite:

Cloud = $33.989bn

as:

Revenue = $33.989bn

because Cloud is a revenue component, not total revenue.

A better representation is:

CUSTOM IDENTITY
orcl:CloudRevenues
"Cloud"
$33.989bn

        ↓ relates to

BROADER FAMILY
RevenueFromContractWithCustomerExcludingAssessedTax

        ↓ sourced from

Oracle FY2026 10-K

This is why provenance and normalization should remain separate: lineage can show where a company-specific fact belongs without pretending it is equivalent to a broader standardized field.

Source: Oracle FY2026 Form 10-K
SEC filing: Oracle FY2026 10-K ↗

Derived values need component-level provenance

Not every useful financial value is reported directly as one filing fact.

Sometimes the system derives a value from reported components.

CoreWeave's Q2 2026 debt-maturity data provides a clean example.

SourceState stores a derived total of:

$20.655 billion

Its provenance points to five reported maturity facts:

The five components come from the same filing and reproduce the derived total exactly.

Each component has its own SourceState fact ID and source position:

2026   fact 57981   position 942
2027   fact 57982   position 943
2028   fact 57983   position 944
2029   fact 57984   position 945
2030   fact 57985   position 946

This creates a different kind of lineage:

DERIVED VALUE
$20.655bn

        ↓

COMPONENT FACTS
5 maturity observations

        ↓

DIRECT XBRL FACTS
LongTermDebtMaturities... concepts

        ↓

FILING
CoreWeave Q2 2026 10-Q

        ↓

SOURCE
Debt maturity schedule

For derived metrics, citing only the filing is particularly weak.

The system should ideally be able to show which reported components produced the result.

Source: CoreWeave Q2 2026 Form 10-Q
SEC filing: CoreWeave Q2 2026 10-Q ↗

Version lineage: the source can change over time

Provenance also has a time dimension.

Valeant's six months ended June 30, 2015 had at least two relevant filing vintages.

Original filing

Filed:
July 28, 2015

Revenue:
$4.9233bn

Net income:
$22.9m

Later restated comparative

Filed:
August 9, 2016

Revenue:
$4.9025bn

Net income:
$46.9m

The later filing explicitly identifies the prior statements as restated.

So the lineage question is not only:

It is also:

For a latest-known historical series, the later restated value may be preferable.

For a point-in-time query dated July 2015, the original filing is the appropriate source.

SourceState stores both accession-specific fact sets, although this older example does not currently have the source-position anchors available for the newer examples above.

That limitation is useful to state explicitly:

Source: Valeant Q2 2016 Form 10-Q, Note 2 — Restatement of Previously Issued Financial Statements
SEC primary source ↗

Why provenance matters even more for AI systems

Consider an analyst asking an AI system:

A weak answer might say:

That number is correct but underspecified.

Forty-five percent of what?

Revenue?

Receivables?

Some other exposure?

A better answer can preserve the evidence:

Customer A represented 45% of Q1 2026 revenue.

Reported label:
Customer A

XBRL concept:
ConcentrationRiskPercentage1

Benchmark:
RevenueFromContractWithCustomerMember

Risk type:
CustomerConcentrationRiskMember

Source:
CoreWeave Q1 2026 10-Q
Note 2 — Significant Customers
accession 0001769628-26-000222
SourceState position 380

That is more than a citation; it is a compact representation of the fact's meaning.

AI increases the value of this kind of provenance because language models can turn structured facts into very fluent answers—and fluency can hide mistakes.

A system that can expose the underlying evidence gives the analyst a way to verify the answer without trusting the prose blindly.

The goal is not to make every user inspect every source manually.

The goal is to make inspection possible whenever the answer matters.

What good lineage should preserve

A strong financial-data evidence chain should preserve as much of the following as the source permits.

Analytical layer

standardized concept
standardized value
mapping / relationship status
direct vs derived

As-reported layer

reported label
raw XBRL concept
reported value
unit

Context layer

instant / duration
period start
period end
context ID
axes
members

Filing layer

form
filing date
accession
document

Source layer

statement / note / table where known
source occurrence
source position / anchor
displayed value
verification status

Version layer

original filing
later comparative
amendment
restatement
recast

Derived-value layer

component fact IDs
component values
component source lineage
calculation / reconciliation where supported

Not every filing or fact will populate every field.

The important principle is that the system should preserve the chain rather than collapse it prematurely.

How SourceState currently handles lineage

SourceState already supports a substantial portion of this evidence chain, but not every lineage step is universal.

Stored with strong coverage

Fact → accession

Accession is stored on fact and filing records.

This provides a stable link to the filing vintage.

Standardized concept → raw concept

For many facts, SourceState stores the standardized concept alongside the underlying XBRL concept.

Coverage has gaps, particularly for company-specific extensions.

Stored substantially, but incompletely

Standardized concept → reported label

Labels and occurrence-level original labels are available for many facts, but some roles or facts have missing labels.

Fact → dimensions

Axes and members are stored for substantial portions of the dimensional fact set.

Readable labels are not always complete.

Fact → context

Context references exist in occurrences and source anchors for many facts, but not universally.

Stored partially

Fact → document

Anchors identify documents, and document metadata maps some filings to cached source URLs.

Fact → source position

fact_anchors can preserve:

• document;
• context reference;
• position;
• displayed value;
• verification metadata;
• landing type.

The position is an internal document position, not an SEC page or line number.

Fact → exact row / table

Presentation roles, filing tables, and anchors provide useful evidence, but there is not currently a universally populated human-readable row/table field attached to every fact.

Fact → note

Statement type and role often identify the disclosure area, but exact note headings are not attached to every fact in a universal structured field.

Fact → prior/later filing vintage

Accession-specific facts preserve the separate versions.

Some curated comparisons link prior accessions, but there is no universal earlier/later version chain.

Supported for some derived values

Derived value → component facts

Some records in SourceState's derived-fact layer preserve component fact IDs.

The CoreWeave debt-maturity total is a clean example.

This capability is not universal across every derived metric.

Partial taxonomy lineage

Calculation ancestry

XBRL calculation and reconciliation structures exist for subsets of filings.

They should not be treated as a universal derivation graph for every financial fact.

Presentation ancestry

SourceState can retain filing presentation relationships where loaded.

Those relationships describe where the company presented the fact.

They are not automatically semantic equivalence.

The simplest way to think about financial-data provenance

A weak data record says:

Amazon Revenue
$716.924bn
Source: 10-K

A stronger one says:

STANDARDIZED
Revenue
$716.924bn

AS REPORTED
Total net sales

XBRL
RevenueFromContractWithCustomerExcludingAssessedTax

CONTEXT
FY2025
no dimensions

FILING
Amazon FY2025 10-K
accession 0001018724-26-000004

SOURCE
amzn-20251231.htm
position 189

And when the fact is more complicated, the evidence chain expands:

dimensions
version
custom concept
component facts
source occurrence

That is the difference between merely knowing a number and being able to show where it came from, what it meant, and which version of history it belonged to.