XBRL Contexts Explained: How SEC Filing Facts Get Their Period, Entity, and Dimensions

Why context matters

Suppose a filing contains two facts:

Revenue     $2.575 billion
Revenue     $4.653 billion

Same company. Same XBRL concept. Same period-end date.

Which number is correct?

Both can be.

CoreWeave's Q2 2026 10-Q provides a clean real-world example. The filing reports revenue of $2.575 billion for the three months ended June 30, 2026 and $4.653 billion for the six months ended June 30, 2026 using the same XBRL revenue concept.

The difference is the duration encoded in the context:

Q2 revenue
April 1, 2026 → June 30, 2026
$2.575bn

Six-month YTD revenue
January 1, 2026 → June 30, 2026
$4.653bn

A system that keys only on concept and end date can easily return the six-month value when the user asks for the quarter—or treat the two values as duplicates.

Nothing is wrong with the filing.

The missing information is the context.

Source: CoreWeave, Q2 2026 Form 10-Q, Condensed Consolidated Statements of Operations and Comprehensive Loss, filed August 12, 2026.
https://www.sec.gov/Archives/edgar/data/1769628/000176962826000366/crwv-20260630.htm ↗

What is an XBRL context?

At the XBRL level, a fact references a context that identifies the reporting entity and period to which the fact applies. A context can also carry dimensional information that further qualifies the fact.

For financial-data work, three parts matter most:

Entity

Who does the fact describe?

Period

When does the fact apply?

Dimensions

Does the fact represent the consolidated company or a particular slice of it?

A simplified mental model looks like this:

XBRL FACT
│
├── Concept
│     Revenue
│
├── Value
│     $2.575bn
│
├── Unit
│     USD
│
└── Context
      ├── Entity
      │     CoreWeave, Inc.
      │
      ├── Period
      │     Apr. 1, 2026 → Jun. 30, 2026
      │
      └── Dimensions
            none

The value alone is not enough.

The concept helps, but the context is what locates the observation in the company's reporting structure.

1. Entity: whose fact is this?

Every XBRL fact applies to a reporting entity.

For a typical public-company filing, the entity identifier corresponds to the filer. In more complex filings, however, entity resolution can become less trivial.

Examples include:

• co-registrants;
• multiple legal entities;
• subsidiary issuers or guarantors;
• fund series;
• separate classes or securities;
• disclosures involving parent and subsidiary entities.

For ordinary company fundamentals, the key idea is simple:

This sounds obvious, but it becomes important when the data model expands beyond one ticker and one consolidated statement.

2. Period: when does the fact apply?

Period handling is one of the easiest ways to select the wrong financial number.

XBRL distinguishes between two broad types of periods.

Instant facts

An instant fact is measured at a point in time.

Typical examples include:

• cash;
• total assets;
• debt;
• shareholder equity.

A cash balance might apply:

as of June 30, 2026

There is no meaningful three-month or six-month duration for that balance-sheet observation.

Duration facts

A duration fact applies over a span of time.

Typical examples include:

• revenue;
• operating income;
• net income;
• cash flow.

A revenue observation therefore needs both a start and an end date:

April 1, 2026 → June 30, 2026

The distinction is fundamental.

Cash = $5bn needs to answer:

Revenue = $5bn needs to answer:

Quarterly versus year-to-date: a common context trap

CoreWeave's Q2 2026 filing shows the problem clearly.

Both of these observations use the same standardized revenue concept and end on June 30:

The six-month amount includes the quarter.

A naïve pipeline might:

• return $4.653bn as "Q2 revenue";
• compare a six-month figure with another company's quarter;
• add the quarterly and YTD values together;
• deduplicate one because both facts share the same concept and end date.

All four would be wrong.

Oracle provides the same lesson on a different fiscal calendar. In Oracle's FY2026 Q3 filing, quarterly revenue was $17.190 billion for December 1, 2025 through February 28, 2026, while nine-month revenue was $48.173 billion for June 1, 2025 through February 28, 2026.

Oracle's fiscal year ends in May, so its Q3 year-to-date period begins in June rather than January.

That is another reason not to infer period structure from calendar dates alone.

Source: Oracle, FY2026 Q3 Form 10-Q, filed March 11, 2026.
https://www.sec.gov/Archives/edgar/data/1341439/000119312526101045/orcl-20260228.htm ↗

Context is not the same thing as filing date

A financial period tells you what economic period the fact describes.

It does not tell you when the market learned the information.

Suppose a company has:

Quarter end:
March 31

10-Q filed:
May 6

The XBRL context can correctly describe:

January 1 → March 31

But the reported number was not necessarily public on March 31.

These are different time concepts:

FINANCIAL CONTEXT
What period does the number describe?

vs.

FILING VINTAGE
When did this disclosure become public?

This distinction matters for point-in-time analysis.

A historical model that assigns a reported value to the period-end date without accounting for the filing date can inadvertently introduce information that was not yet available at the time.

So context answers:

It does not by itself answer:

A robust historical financial database needs both.

3. Dimensions: what slice of the company does the fact describe?

Periods are only one part of context.

XBRL can also qualify a fact using dimensions—commonly represented as axes and members.

Examples include:

Geography axis
    United States
    Non-U.S.

Business segment axis
    AWS
    North America
    International

Product or service axis
    Product sales
    Service sales

The concept can remain the same while the dimensional context changes the meaning of the fact.

This is where XBRL begins to describe the structure of a business, not merely its headline financial statements.

CoreWeave: consolidated revenue versus geography

CoreWeave's Q2 2026 filing provides an unusually clean example.

For the three months ended June 30, 2026:

Consolidated revenue                 $2.575bn

The same revenue concept is also reported by geography:

United States                       $2.389bn
Non-U.S.                              0.186bn
                                    --------
Total                               $2.575bn

The geographic members reconcile exactly to the consolidated figure.

That means all three observations are valid:

Revenue = $2.575bn
context: consolidated

Revenue = $2.389bn
context: geography = United States

Revenue = $0.186bn
context: geography = Non-U.S.

A naïve system could add all three and report $5.150 billion of revenue.

Again, the filing is not inconsistent. The system has counted the same economics at two levels of the reporting structure.

Source: CoreWeave, Q2 2026 Form 10-Q, Note 15, Geographic Information.
https://www.sec.gov/Archives/edgar/data/1769628/000176962826000366/crwv-20260630.htm ↗

One concept can have multiple independent views

Dimensions become even more important when the same economic total is broken down in several different ways.

Amazon's FY2025 net sales were $716.924 billion.

The filing provides multiple complete views of that same total.

Product versus service

Product sales                       $296.266bn
Service sales                        420.658bn
                                    ----------
Total net sales                     $716.924bn

Business segment

North America                       $426.305bn
International                        161.894bn
AWS                                  128.725bn
                                    ----------
Total net sales                     $716.924bn

Geography

United States                       $489.657bn
Germany                               45.900bn
United Kingdom                        43.212bn
Japan                                 30.688bn
Rest of world                        107.467bn
                                    ----------
Total net sales                     $716.924bn

Each breakdown is internally valid.

But the members across those axes are not additive to one another.

AWS revenue and U.S. revenue, for example, are not disjoint categories. They answer different questions about the same economic activity.

This is why a flat representation such as:

Revenue
Value
Period

is insufficient.

It discards the information needed to know whether two facts belong to the same breakdown or to entirely different analytical views.

Source: Amazon, FY2025 Form 10-K, Consolidated Statements of Operations and Note 10, Segment Information, filed February 6, 2026.
https://www.sec.gov/Archives/edgar/data/1018724/000101872426000004/amzn-20251231.htm ↗

Oracle: dimensionless totals, dimensioned totals, and member facts

Oracle's FY2026 Q3 filing shows another subtlety.

For the quarter ended February 28, 2026, Oracle reported consolidated revenue of:

$17.190bn

That total appears in a non-dimensioned context.

The filing also contains a dimensioned operating-segment total of the same $17.190 billion, as well as individual segment facts:

Cloud and Software                  $15.033bn
Services                              1.443bn
Hardware                              0.714bn
                                    --------
Total                               $17.190bn

The same broad revenue concept is also represented through geography:

Americas                            $11.361bn
EMEA                                  3.964bn
Asia Pacific                          1.865bn
                                    --------
Total                               $17.190bn

And through product or service offerings including:

• Cloud Applications;
• Cloud Infrastructure;
• Software Support;
• Software License;
• Services;
• Hardware.

Those offering-level facts also reconcile to total revenue when the leaf values are used.

This example matters because an extractor can encounter:

• a dimensionless consolidated total;
• a dimensioned total;
• individual segment members;
• geographic members;
• product or service members;

all associated with the same broad revenue concept.

None should be assumed to be duplicates merely because their concept and period match.

Source: Oracle, FY2026 Q3 Form 10-Q, filed March 11, 2026.
https://www.sec.gov/Archives/edgar/data/1341439/000119312526101045/orcl-20260228.htm ↗

Why duplicate-looking facts may both be correct

Suppose a query returns:

Revenue     $17.190bn
Revenue     $17.190bn
Revenue     $15.033bn
Revenue      $3.964bn
Revenue      $4.888bn

At first glance, this looks messy.

But the contexts might reveal:

$17.190bn    consolidated
$17.190bn    operating-segment total
$15.033bn    segment = Cloud and Software
$3.964bn     geography = EMEA
$4.888bn     offering = Cloud Infrastructure

The values were never contradictory.

The query discarded information needed to interpret them.

A useful rule is:

Context identity needs more than concept and date

For reliable financial data, a fact identity needs something closer to:

concept
+ entity
+ period
+ dimensions
+ unit
+ filing vintage

rather than:

concept
+ end date

Why?

Because the same concept can be:

• quarterly or YTD;
• consolidated or segment-level;
• reported across multiple independent axes;
• denominated in different units;
• repeated in later filings;
• recast or restated.

Context is therefore not auxiliary metadata.

It is part of the financial meaning of the observation.

Advanced example: context can qualify operational facts too

Contexts are not limited to familiar accounting measures such as revenue or assets.

CoreWeave's Q2 2026 filing contains a company-specific fact describing 393 MW of electrical power access not yet commenced at a single-site data center.

The fact uses:

• a custom CoreWeave concept;
• an instant date of June 30, 2026;
• a property, plant and equipment type axis;
• a company-specific single-site data-center member;
• MW as the unit.

The filing explains that the 393 MW represented power that remained undelivered at the site and was expected in phases.

Without the context, a reader or machine could easily misinterpret the number as:

• total company power capacity;
• operating capacity already in service;
• a standardized GAAP financial metric.

It is none of those.

The context makes the scope explicit.

Source: CoreWeave, Q2 2026 Form 10-Q, lease disclosure, "Leases Not Yet Commenced."
https://www.sec.gov/Archives/edgar/data/1769628/000176962826000366/crwv-20260630.htm ↗

Multi-axis facts can become even more specific

Some observations require several dimensions simultaneously.

CoreWeave's customer-concentration disclosure is a useful example.

For Q2 2026, the filing reports customer concentration percentages of:

Customer A     36%
Customer B     26%
Customer C     10%

Each observation is qualified by multiple dimensions describing:

• which major customer;
• which benchmark the percentage is measured against;
• which type of concentration risk is being reported.

Those axes together explain what the percentage actually means.

A simple field such as:

Concentration percentage = 36%

would lose most of the information required to interpret it.

This is why high-quality XBRL systems must preserve combinations of dimensions, not merely a single optional "segment" field.

Source: CoreWeave, Q2 2026 Form 10-Q, Note 2, Revenue — Significant Customers.
https://www.sec.gov/Archives/edgar/data/1769628/000176962826000366/crwv-20260630.htm ↗

Context is necessary, but not sufficient

It would be tempting to conclude that once context is handled correctly, choosing the right financial fact becomes easy.

Not always.

Two facts can still require interpretation based on:

• statement location;
• presentation hierarchy;
• calculation relationships;
• accounting definition;
• company-specific extensions;
• filing vintage;
• restatement or recast status.

For example, two observations might display the same human-readable label while serving different statement roles.

So reliable financial-data interpretation requires a broader structure:

Concept
+
Context
+
Statement role
+
Taxonomy relationships
+
Source evidence

Context solves a major part of the problem.

It does not replace the rest.

Context and the SEC's data APIs

Context-related issues also appear when working through SEC APIs.

A single taxonomy concept can contain many historical observations across filings and periods. The SEC's APIs organize these facts to make them easier to consume, but the underlying period and reporting structure still matter.

The SEC's Frames API goes further by grouping company facts into comparable calendar frames. This is useful for cross-company analysis, but fiscal calendars still vary.

Oracle's quarter ending February 28 and CoreWeave's quarter ending June 30 illustrate why a calendar label alone cannot fully describe the underlying reporting interval.

The broader principle remains:

SEC EDGAR APIs:
https://www.sec.gov/search-filings/edgar-application-programming-interfaces ↗

A practical checklist for choosing a financial fact

When several XBRL facts appear to represent the same metric, inspect at least the following.

1. Concept

What economic or accounting concept is being reported?

2. Entity

Which reporting entity does the fact describe?

3. Period type

Is it an instant or duration observation?

4. Start and end dates

For duration facts, is this a quarter, year-to-date period, full year, or another interval?

5. Dimensions

Does the fact represent:

• consolidated data;
• a business segment;
• a product or service;
• a geography;
• a customer;
• another dimensional member?

6. Axis

Which analytical breakdown does that member belong to?

A segment member and a geographic member may both describe the same revenue total from different perspectives.

7. Unit

USD? Shares? USD per share? Percentage? MW?

8. Filing vintage

Which filing supplied the observation?

9. Statement or disclosure role

Where does the fact appear in the filing?

This checklist eliminates many of the most common XBRL extraction errors before more sophisticated interpretation is required.

How SourceState treats contexts

SourceState preserves context as part of the identity of an as-reported fact rather than treating it as disposable XBRL metadata.

That means a value can remain connected to:

• reporting entity;
• start and end dates;
• instant or duration period;
• unit;
• axes;
• members;
• source filing;
• filing location.

This allows SourceState to distinguish, for example:

CoreWeave Revenue
$2.575bn
Q2 2026
Consolidated

from:

CoreWeave Revenue
$2.389bn
Q2 2026
Geography = United States

and from:

CoreWeave Revenue
$4.653bn
Six months ended June 30, 2026
Consolidated

even though all three observations belong to the same broader revenue concept.

Likewise, Amazon's segment, geography, and product/service views remain separate dimensional representations of the same consolidated business rather than being flattened into one list of revenue values.

The goal is not merely to retain XBRL metadata.

It is to preserve enough structure to understand what the financial fact actually means.

That structure can then support:

• standardized financials;
• peer comparison;
• disclosure breakdowns;
• time-series construction;
• filing-change analysis;
• custom datasets;
• financial screening;
• APIs and machine workflows.

The simplest way to think about XBRL context

An XBRL concept answers:

The context answers:

For example:

Concept:
Revenue

Entity:
CoreWeave

Period:
April 1 → June 30, 2026

Dimension:
Geography = United States

Value:
$2.389bn

Remove the context and you are left with:

Revenue = $2.389bn

That statement is technically recognizable but financially incomplete.

This is why context is not secondary metadata.

It is part of the meaning of the number.