Company-Specific XBRL Extensions Explained: Why Companies Create Custom Tags—and When They Should Stay Distinct

What is an XBRL extension?

The US-GAAP taxonomy contains a broad set of standard concepts, axes, members, and relationships.

But no standard taxonomy can anticipate every way every company will describe its business.

Companies therefore create extensions when the standard taxonomy does not adequately capture a reported concept or dimensional category.

An extension can be:

• a custom concept;
• a custom member on a standard axis;
• a custom axis;
• a custom axis with custom members;
• or a combination of those structures.

For example:

Standard concept:
RevenueFromContractWithCustomerExcludingAssessedTax

Standard axis:
ProductOrServiceAxis

Company-specific member:
SubscriptionsandServicesMember

or:

Company-specific concept:
RecourseDebtCurrent

or:

Company-specific axis:
FinanceLeaseTransactionAxis

Company-specific members:
DCSPFinancingObligationMember
DCSPFinancingLeasesMember

The fact that an item is company-specific tells us something about its taxonomy origin.

It does not tell us whether the underlying economics are unique, redundant, comparable, or important.

That requires interpretation.

Why companies create custom tags

A company may create an extension because:

• the standard taxonomy has no concept that matches the disclosure closely enough;
• the company reports a business-specific revenue or expense category;
• a standard concept exists at a broader level, but the company wants to preserve more detail;
• the company needs a segment, product, customer, or transaction category not available as a standard member;
• an operational KPI has no natural standardized financial-statement concept;
• the disclosure describes a transaction mechanism that would lose meaning if reduced to a generic field.

Some extensions are highly specific.

Amazon, for example, reports a company-specific concept for Technology and Infrastructure Expense. In fiscal 2025, the value was $108.521 billion. SourceState places that disclosure within the broader costs-and-expenses presentation family, but the parent category is too broad to replace Amazon's own line item.

Source: Amazon, FY2025 Form 10-K.
https://www.sec.gov/Archives/edgar/data/1018724/000101872426000004/amzn-20251231.htm ↗

Likewise, Oracle reports Cloud Revenues as a company-specific concept. The annual value was $33.989 billion in FY2026 and $24.506 billion in FY2025. Its presentation parent is the standard revenue concept, but Cloud remains a revenue component—not an alternate label for total revenue.

Source: Oracle, FY2026 Form 10-K.
https://www.sec.gov/Archives/edgar/data/1341439/000119312526277521/orcl-20260531.htm ↗

Extensions often exist because the economically interesting detail begins where the generic taxonomy ends.

Extensions are not all the same

It is tempting to treat extensions as one quality problem:

That is too simplistic.

Consider three different cases.

Case A: company-specific wording for an otherwise standard economic concept

A custom tag might genuinely mean the same thing as a standard taxonomy concept.

That can potentially be normalized directly.

Case B: more specific economics beneath a standard family

A custom concept might clearly belong under a broader standard concept but contain additional meaning.

It should remain distinct even if it participates in a common hierarchy.

Case C: genuinely company-specific economics

A custom concept may describe a transaction, KPI, or business category for which forcing a standard mapping would be misleading.

That extension should be preserved.

The challenge is deciding which case you are looking at.

Three possible treatments: Map, Relate, Preserve

For a normalization system, a useful decision framework is:

These are normalization decisions, not official XBRL classifications.

1. MAP

Use when the extension is genuinely equivalent to a standard economic concept.

The custom identity may still be retained for lineage, but the standardized observation can safely use the common concept.

2. RELATE

Use when the extension belongs under a broader standardized family but is more specific than the parent.

Examples include:

• cloud revenue under revenue;
• recourse debt under a liability/debt family;
• technology and infrastructure expense under costs and expenses.

3. PRESERVE

Use when the extension represents economics that would be distorted by forcing it into a standard field.

Examples include:

• a specialized financing reclassification;
• an operational capacity measure;
• a company-specific non-cash transaction.

This framework is deliberately conservative.

In the SourceState data slice reviewed for this article, no company-specific concept had a confirmed, reviewed extension-to-standard mapping. That means the examples below support RELATE and PRESERVE clearly, but not a real production MAP case.

That absence is itself instructive.

A normalization system should not manufacture certainty merely because a label looks familiar.

RELATE: CoreWeave recourse and non-recourse debt

CoreWeave provides the cleanest example of why an extension can belong to a broader family without becoming identical to it.

At June 30, 2026:

SourceState retains all four custom concepts.

It also records broader lineage:

RecourseDebtCurrent
NonRecourseDebtCurrent
        ↓
LiabilitiesCurrent

and:

RecourseDebtNonCurrent
NonRecourseDebtNonCurrent
        ↓
Liabilities

That relationship is useful.

It tells us where the observations belong in the balance-sheet structure.

But it does not mean:

RecourseDebtCurrent = LiabilitiesCurrent

or:

NonRecourseDebtNonCurrent = TotalDebt

The extension is more specific than its broader ancestor.

Flattening it would lose:

• recourse status;
• non-recourse status;
• current versus non-current classification;
• the company's own financing structure.

So the right treatment is:

Source: CoreWeave, Q2 2026 Form 10-Q, Condensed Consolidated Balance Sheets, filed August 12, 2026.
https://www.sec.gov/Archives/edgar/data/1769628/000176962826000366/crwv-20260630.htm ↗

Why label similarity is not enough to MAP

Oracle provides an important counterexample.

Its FY2026 Q1 filing contains a custom concept labeled:

The value for the quarter was $5.607 billion.

At first glance, this looks like an obvious candidate for mapping to a standard pre-tax-income concept.

But the current SourceState lineage does not contain a reviewed alias or standard mapping proving that equivalence.

The fact's presentation parent is NetIncomeLoss.

That tells us something about where the line appears.

It does not prove concept identity.

A naïve normalizer might decide:

label contains "income before income taxes"
→ map to standard pretax income

without checking:

• taxonomy definition;
• statement role;
• calculation relationships;
• filing semantics;
• reviewed mapping history.

The apparent match may ultimately be correct.

But the evidence in the current store does not support claiming that it is.

So the responsible treatment is:

This is a useful principle far beyond this one Oracle fact:

Source: Oracle, FY2026 Q1 Form 10-Q, Condensed Consolidated Statements of Operations, filed September 11, 2026.
https://www.sec.gov/Archives/edgar/data/1341439/000119312526389274/orcl-20260831.htm ↗

PRESERVE: CoreWeave OEM financing reclassification

Some extensions should remain explicitly unmapped because their economic meaning is unusually specific.

CoreWeave reports a custom cash-flow concept:

ReclassificationOfLiabilitiesRelatedToPropertyAndEquipment
AdditionsToDebtUponExecution

For the six months ended June 30, 2026, the amount was:

$1.469 billion

The disclosure describes liabilities related to property-and-equipment additions being reclassified to debt when OEM financing arrangements are executed.

This is not simply:

• debt proceeds;
• capital expenditures;
• a generic non-cash adjustment;
• financing cash flow.

Each of those labels captures only part of the economic event.

Forcing the fact into one of them would erase the transaction's mechanism and timing.

SourceState therefore keeps the extension identity explicitly unmapped.

This is a strong PRESERVE case:

A standardized database can still make the fact searchable, traceable, and related to other financing disclosures without pretending it is equivalent to a more generic metric.

Source: CoreWeave, Q2 2026 Form 10-Q, Condensed Consolidated Statements of Cash Flows.
https://www.sec.gov/Archives/edgar/data/1769628/000176962826000366/crwv-20260630.htm ↗

Custom members on standard axes

Not every extension is a custom financial concept.

Companies also create custom members inside standard dimensional structures.

AMD's fiscal 2025 revenue disclosure provides a useful example.

The company uses standard axes including:

StatementBusinessSegmentsAxis
ProductOrServiceAxis

but company-specific members such as:

ClientAndGamingMember
ClientMember
GamingMember

For fiscal 2025:

Client revenue               $10.640bn
Gaming revenue                 3.910bn
                              --------
Client and Gaming segment     $14.550bn

The custom members preserve AMD's own business organization.

The full dimensional structure matters because the observations sit at different levels.

A naïve system could add:

$10.640bn
+ $3.910bn
+ $14.550bn

and report $29.100 billion.

The error would not come from the custom members themselves.

It would come from losing the hierarchy they participate in.

Source: AMD, FY2025 Form 10-K, segment revenue disclosure, filed February 4, 2026.
https://www.sec.gov/Archives/edgar/data/2488/000000248826000018/amd-20251227.htm ↗

Custom axes and custom members

Companies can also extend the dimensional structure itself.

CoreWeave reports current finance lease liabilities using the standard concept:

FinanceLeaseLiabilityCurrent

The consolidated balance is:

$7 million

But the filing further distinguishes:

$3m  DCSP financing obligation
$4m  DCSP financing leases

using:

FinanceLeaseTransactionAxis

with custom members:

DCSPFinancingObligationMember
DCSPFinancingLeasesMember

The two member facts reconcile to the $7 million consolidated balance.

Here the financial concept is standard.

The way the company subdivides that concept is company-specific.

Dropping the custom dimensional structure would preserve the headline balance while losing the distinction between the two financing categories.

The right treatment is to retain the axis/member vocabulary while relating the observations back to the standard finance-lease concept.

Source: CoreWeave, Q2 2026 Form 10-Q, Condensed Consolidated Balance Sheets.
https://www.sec.gov/Archives/edgar/data/1769628/000176962826000366/crwv-20260630.htm ↗

Extensions can carry operational data too

Extensions are not limited to familiar financial-statement categories.

CoreWeave's Q2 2026 filing includes the company-specific concept:

ElectricalPowerAccessNotYetCommenced

with a value of:

393 MW

The fact is qualified by:

PropertyPlantAndEquipmentByTypeAxis
→ SingleSiteDataCenterMember

The filing explains that this represents electrical power that remained undelivered at a single-site data center and was expected to arrive in phases.

That fact should not be mapped to:

• PP&E;
• total power capacity;
• operating capacity;
• a financial-statement amount.

Its meaning is operational.

This is exactly the kind of disclosure where forcing everything into a conventional fundamentals schema can destroy investment-relevant information.

The extension is not an obstacle to analysis.

It is the thing that makes the disclosure analytically useful.

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

Extensions can create hierarchy and double-counting traps

Extension handling is not only a semantic problem. It is also a structural one.

The AMD example above shows why. Client revenue and Gaming revenue sum to the $14.550 billion Client and Gaming segment subtotal. The subtotal is not additional revenue. Flattening the custom members into a list of normalized revenue fields without preserving their hierarchy would double count the same economics.

The same issue appears in other extension-heavy disclosures:

• company-specific product categories beneath a standard revenue concept;
• custom segment members beneath a segment total;
• custom liability buckets beneath a broader balance-sheet line;
• extension concepts representing transaction mechanics rather than cash flows themselves.

A good extension model therefore needs more than a dictionary:

custom tag → standard tag

It needs to preserve relationships.

Extensions across time

A second challenge is temporal consistency.

A company can:

• keep the same extension for years;
• rename a custom concept;
• change its definition;
• replace it with a standard taxonomy concept;
• restructure segments and members;
• introduce a new custom axis.

That creates a time-series normalization problem.

Oracle's CloudRevenues concept is a useful example of a stable custom tag:

FY2025      $24.506bn
FY2026       33.989bn
FY2026 Q1    11.607bn

The concept is useful for longitudinal analysis precisely because the company-specific identity is preserved.

But this example does not demonstrate an extension changing over time. In the SourceState data slice reviewed for this article, no verified custom concept, axis, or member change was found.

That distinction matters.

A stable extension can support a clean company-level time series.

A changing extension requires additional work to determine whether two differently tagged observations really represent the same economics.

Source: Oracle FY2026 Form 10-K and FY2026 Q1 Form 10-Q.
https://www.sec.gov/Archives/edgar/data/1341439/000119312526277521/orcl-20260531.htm ↗
https://www.sec.gov/Archives/edgar/data/1341439/000119312526389274/orcl-20260831.htm ↗

How to work with extensions safely

When an XBRL extension appears, ask at least the following questions.

1. What type of extension is it?

• custom concept?
• custom member?
• custom axis?
• several at once?

2. What does the filing say it means?

Do not infer semantics only from the machine-readable name.

3. Is there a standard concept that is genuinely equivalent?

If yes, a direct mapping may be appropriate.

If not, do not force one.

4. Does the extension have a broader ancestor?

An ancestor can help locate the fact in the financial structure.

It does not necessarily establish identity.

5. Is the extension a component, subtotal, or total?

Preserve hierarchy.

6. Does it belong to a dimensional breakdown?

Keep every axis/member pair.

7. What information would a generic mapping remove?

Examples include:

• recourse status;
• business category;
• financing mechanism;
• customer identity role;
• operational scope.

8. Is the extension stable across periods?

Do not automatically stitch changing custom concepts into one time series.

9. Is the value financial or operational?

A custom KPI in MW, users, units, or capacity should not be forced into a dollar-based fundamentals schema.

10. Can the interpretation be traced back to the filing?

If not, the mapping should be treated as uncertain.

How SourceState treats extensions

SourceState treats extension identity and standardized interpretation as related but distinct.

A custom observation can retain:

• the original concept;
• label;
• value;
• period;
• unit;
• dimensions;
• source filing;
• source location;
• presentation or lineage relationships;
• standardized family where supported.

That makes it possible to represent:

CRWV RecourseDebtCurrent
$6.235bn

as:

CUSTOM IDENTITY
RecourseDebtCurrent

BROADER RELATIONSHIP
LiabilitiesCurrent

TREATMENT
RELATE

without silently rewriting the fact as:

Total debt = $6.235bn

Likewise:

ORCL CloudRevenues
$33.989bn

can remain its own company-specific revenue category while still participating in broader revenue analysis.

And a transaction-specific fact such as CoreWeave's OEM financing reclassification can remain explicitly unmapped when there is no safe standard equivalent.

The objective is not to maximize the percentage of extensions that receive a standardized tag.

It is to preserve enough meaning for the data to remain economically correct.

The simplest way to think about XBRL extensions

A company-specific extension asks the data system a question:

There are three possible answers:

MAP
Same economics.
Use the common concept.

RELATE
Belongs to a common family,
but preserve the extra meaning.

PRESERVE
Distinct economics.
Do not force equivalence.

Detecting that a tag is custom is straightforward. The difficult part is deciding what the extension means without losing the information the company used it to express.