Backlog Is Not Revenue: What RPO, Backlog, and Deal Value Actually Tell You

The future-demand normalization problem

Financial databases are comfortable with historical facts.

Revenue happened.

Cash exists.

Debt is outstanding.

Future-demand metrics are different.

They describe economic activity that is somewhere between a commercial relationship and recognized revenue.

Depending on the metric, that future activity might involve:

• an unexercised customer option;
• a signed contract;
• a non-cancelable performance obligation;
• a purchase order;
• an estimated amount under a committed contract;
• an order that can still be rescheduled;
• a contract whose delivery depends on infrastructure becoming available;
• or revenue that is already deferred and waiting for the performance obligation to be satisfied.

The labels vary:

Total Remaining Deal Value
Revenue Backlog
Backlog
Remaining Performance Obligations
Current RPO
Bookings
Contracted Revenue
Orders

It is tempting to map them all into:

future_revenue

That is useful for discovery.

It is dangerous for analysis.

The same reported dollar of "future demand" can sit at a very different contractual, operational, or accounting stage depending on the metric.

A useful normalization therefore needs two layers:

CANONICAL FAMILY
future-demand visibility

              +

CONTRACTUAL ATTRIBUTES
optionality
cancellability
accounting scope
delivery dependencies
recognition timing
definition vintage
source

The family tells us that the metrics answer related questions.

The attributes tell us whether their values can actually be compared.

Why there is no universal certainty ladder

It would be convenient to draw:

Deal Value
    ↓
Backlog
    ↓
RPO
    ↓
Deferred Revenue
    ↓
Revenue

and say each step is more certain than the one above it.

The filings do not support that as a universal model.

Different metrics are defined along different dimensions.

Palantir's Total Remaining Deal Value includes contractual options under assumptions about exercise and termination.

Palantir RPO excludes cancelable revenue and, under an ASC 606 expedient, certain contracts with original terms of 12 months or less.

CoreWeave Revenue Backlog can include RPO plus estimated future revenue from committed customer contracts.

Vertiv backlog is an operational order measure based on received purchase orders or purchase commitments, but those orders may still be cancelled or rescheduled.

Oracle RPO is an accounting-defined measure, but its disclosed RPO excludes certain variable consideration under an accounting election.

The categories overlap conceptually.

They are not guaranteed to be strict subsets of one another.

A better representation is a map of attributes:

This leads to a more precise question:

One screen: what still has to happen before revenue?

The table makes the central problem visible.

These metrics all provide future-demand visibility, but the residual uncertainty is different in each row.

That is why a cross-company "backlog multiple" can look mathematically precise while mixing different contractual and operational states.

Palantir: $11.2B of deal value versus $4.1B of RPO

Palantir is the cleanest example because it removes cross-company differences from the problem.

At December 31, 2025:

Total Remaining Deal Value      $11.2bn
Remaining Performance Obligations 4.1bn
                                 -------
Difference                       $7.1bn

TRDV / RPO                       ~2.73×

The company's definitions explain why the numbers can diverge.

Total Remaining Deal Value

Palantir describes Total Remaining Deal Value as the remaining value of contracts that have been awarded or entered into.

The calculation assumes:

• all available customer contract options are exercised;
• no contracts terminate.

That matters because the same filing says many contracts contain termination provisions, including termination for convenience.

Palantir also excludes unfunded value under indefinite-delivery, indefinite-quantity contracts.

So TRDV should not be interpreted as:

$11.2bn of unavoidable future revenue

It is a broader company-defined representation of remaining deal economics under stated assumptions.

Remaining Performance Obligations

Palantir's RPO is more accounting-constrained.

It represents non-cancelable contracted revenue not yet recognized.

It includes deferred revenue and, in some cases, amounts that have not yet been invoiced.

The company also uses the ASC 606 practical expedient that allows it not to disclose RPO for contracts with an original expected duration of one year or less.

So:

TRDV
can include value under options / broader contract assumptions

RPO
focuses on non-cancelable contracted revenue
within accounting disclosure scope

The recognition schedule adds another layer

At December 31, 2025, Palantir expected to recognize:

38% of RPO     next 12 months
36%            months 13–36
26%            thereafter

That immediately separates:

TOTAL FUTURE CONTRACTED AMOUNT

from:

NEAR-TERM REVENUE CONVERSION

Even a comparatively strict accounting metric such as RPO is not synonymous with next-year revenue.

What the $7.1B gap does not tell us

The filing provides the conceptual reasons that TRDV and RPO differ.

It does not provide:

customer options                 $X
cancelable contract value        $Y
short-duration contracts         $Z
other differences                $W
                                ----
total gap                      $7.1bn

That bridge would be invented.

The correct interpretation is more restrained:

That distinction is exactly what good financial normalization should preserve.

Primary source:

• Palantir FY2025 Form 10-K
  SEC primary source ↗

CoreWeave: when backlog is explicitly larger than RPO

CoreWeave provides an even cleaner mechanical relationship.

In its Q1 2025 earnings disclosure:

Remaining Performance Obligations        $14.7bn
Estimated future revenue from
committed customer contracts             +11.2bn
                                         -------
Revenue Backlog                          $25.9bn

This is powerful because the company gives us the additive bridge directly.

Approximately 43% of the reported backlog came from the additional estimated-future-revenue component, based on the rounded disclosed values.

So for CoreWeave:

The additional amount represented estimated future revenue from existing committed customer contracts, subject to delivery and service-availability requirements.

That means the difference is not merely accounting taxonomy.

There is an operational condition between the contract and revenue realization.

COMMITTED CUSTOMER CONTRACT
        │
        ├── RPO component
        │
        └── estimated future revenue
             subject to delivery /
             service availability
        │
        ▼
REVENUE BACKLOG
        │
        ▼
capacity / service delivered
        │
        ▼
revenue recognition

The relationship changed dramatically over time

CoreWeave's SEC-filed presentation shows Revenue Backlog rising:

Dec. 31, 2023       $9.9bn
Dec. 31, 2024       15.1bn
Dec. 31, 2025       66.8bn
Jun. 30, 2026      104.2bn

Its RPO also rose dramatically.

SourceState's stored series shows:

Mar. 31, 2025       $14.7bn
Dec. 31, 2025        60.7bn
Jun. 30, 2026       103.7bn

By June 30, 2026, the gap between the two measures had become much smaller.

A later SEC-filed presentation gives:

RPO                                  $103.7bn
Other estimated future revenue         0.5bn
                                      -------
Revenue Backlog                      $104.2bn

Using the rounded reported amounts, the non-RPO estimated component fell from roughly 43% of backlog in Q1 2025 to roughly 0.5% at June 30, 2026.

That is a striking change in composition.

It does not by itself prove that the definition changed.

The stronger conclusion is that the mix of what sat inside the reported backlog changed dramatically.

Why the distinction matters

An analyst might see:

Revenue Backlog = $104.2bn

and treat it as an enormous future-revenue number.

But the filing asks several additional questions:

• How much is already inside RPO?
• How much is an additional estimate?
• When is it expected to convert?
• What delivery conditions remain?
• Does service availability constrain realization?

CoreWeave's RPO itself also contains estimates.

Its filing describes transaction price allocated to undelivered or partially undelivered performance obligations, net of estimated variable consideration. That variable consideration includes items such as expected service credits, delivery-delay effects, and committed compute capacity that CoreWeave can resell.

So even an accounting-defined number can contain estimation.

The timing profile is long

At June 30, 2026, CoreWeave expected its RPO to be recognized approximately:

41%     initial 24 months
39%     months 25–48
20%     months 49–78

Again:

$103.7bn RPO
        ≠
$103.7bn near-term revenue

The size of the number and the duration of the number are separate analytical facts.

A SourceState provenance caveat

The Q1 2025 $14.7B + $11.2B = $25.9B reconciliation is fully reconstructable from the locally stored SEC-filed earnings exhibit.

The later June 30, 2026 $103.7B + $0.5B = $104.2B exact reconciliation is SEC-verifiable, but the specific later presentation containing that exact bridge is not currently in the local SourceState corpus.

That difference should remain visible rather than being hidden behind one seamless-looking time series.

Primary sources:

• CoreWeave Q1 2025 earnings-release exhibit
  SEC primary source ↗

• CoreWeave Q2 2026 earnings release
  SEC primary source ↗

• CoreWeave SEC-filed 2026 presentation
  SEC primary source ↗

Oracle: a huge RPO number can be a long-duration number

Oracle provides the cleanest example of why headline RPO and near-term revenue are different variables.

At August 31, 2026, Oracle reported:

RPO: $664 billion

That was up from $455 billion a year earlier—about 46%—driven primarily by significant cloud contracts.

The headline growth is enormous.

The recognition schedule is what tells you how to interpret it.

But Oracle also disclosed when it expected the RPO to convert.

Next 12 months          13%
Months 13–36            37%
Months 37–60            34%
Thereafter               16%

Only 13% was expected to become revenue during the next 12 months.

Applying the company's rounded percentage to its rounded RPO:

$664bn × 13%
≈ $86.3bn

That $86.3 billion is a derived approximation.

It is not a company-reported revenue forecast.

It simply illustrates the scale difference between:

TOTAL RPO
$664bn

and:

SHARE EXPECTED TO BE RECOGNIZED
OVER THE NEXT 12 MONTHS
~13%

Three months earlier, the same lesson was already visible

At May 31, 2026, Oracle reported:

RPO                  $638bn
Expected next 12m       12%

So even as the total RPO rose substantially, most of the balance remained long-dated.

This matters when analysts use RPO growth as shorthand for near-term revenue growth.

A company can sign very large long-duration contracts and produce:

RPO ↑↑↑

without generating anything close to the same proportional increase in next-12-month recognized revenue.

What Oracle's RPO includes

Oracle describes RPO as contracted revenue not yet recognized.

It includes:

• deferred revenue;
• invoiced but uncollected amounts not yet recognized;
• amounts expected to be invoiced and recognized in future periods.

But even here, the accounting population is not literally "every dollar of future contract economics."

Oracle elects not to disclose certain variable consideration allocated entirely to wholly unsatisfied performance obligations.

So RPO is more standardized than a company-defined backlog metric.

It is not a universal measure of every possible future dollar.

Primary sources:

• Oracle Q1 FY2027 Form 10-Q, period ended August 31, 2026
  SEC filing: Oracle 10-Q · Aug. 2026 period ↗

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

Vertiv: physical order backlog is a different kind of future demand

Vertiv shows why an industrial or physical-infrastructure backlog should not be treated as an RPO substitute.

At December 31, 2025, Vertiv reported approximately:

$15.0 billion of backlog

A year earlier:

$7.2 billion

The company described the increase as 109%.

That sounds like a powerful future-demand signal.

It is.

But what sits inside the number?

Vertiv defines backlog using product and service orders for which it has received a customer purchase order or purchase commitment but has not yet delivered the product or service.

Conceptually:

CUSTOMER PURCHASE ORDER / COMMITMENT
        │
        ▼
UNDELIVERED PRODUCT OR SERVICE
        │
        ▼
ORDER BACKLOG
        │
        ▼
shipment / delivery
        │
        ▼
revenue recognition

This is an operational pipeline.

Not an accounting RPO definition.

Orders can still change

Vertiv says orders can be cancelled or rescheduled.

Customers may sometimes reduce or defer even firm orders, generally with penalties or other termination consequences.

The company said the majority of backlog was considered firm and expected to ship within approximately 12 to 18 months.

Those words matter:

majority

not:

all

and:

expected to ship

not:

guaranteed revenue

Vertiv's 2025 10-K also notes that acquisitions added to backlog and that acquired contracts may have different reduction or termination terms.

That creates another common analytical trap.

Backlog growth can come from:

organic order growth
+
acquired backlog
+
changes in timing
+
changes in cancellations / rescheduling

It is not automatically a clean measure of organic future revenue growth.

Why Vertiv is especially useful in the AI era

Vertiv sells physical infrastructure into data-center and other end markets.

That means backlog has an operating path that differs materially from software RPO.

A software contract may convert as performance obligations are satisfied over time.

A physical order can depend on:

• production;
• supply availability;
• shipment;
• project scheduling;
• installation or delivery timing;
• customer rescheduling.

The same broad phrase—

—therefore hides very different operational mechanics.

Do not force Vertiv backlog into RPO

SourceState contains several Vertiv XBRL facts using the standard RevenueRemainingPerformanceObligation concept for expected satisfaction beginning in 2027, 2028, and 2029.

Those disclosed facts sum to $107.6 million.

But the filing does not provide a verified reconciliation from those facts to Vertiv's $15 billion operational backlog.

So it would be wrong to show:

$15bn backlog
        =
$107.6m RPO
+
something else

The evidence does not support that bridge.

That is another important principle:

Primary source:

• Vertiv FY2025 Form 10-K
  SEC primary source ↗

Five dimensions that determine what a future-demand metric means

The four examples suggest a reusable framework.

When an analyst sees:

Backlog = $X

or:

RPO = $Y

the first task is not to rank the number.

It is to decompose the metric.

1. Accounting scope

Ask:

RPO is anchored in revenue-recognition accounting.

Palantir TRDV, CoreWeave Revenue Backlog, and Vertiv order backlog are company-defined or operational metrics.

That does not make the company-defined metrics inferior.

It means their definitions must travel with the values.

2. Optionality

Ask:

Palantir TRDV explicitly assumes all available customer options are exercised.

That makes optionality central to the metric.

RPO may exclude amounts that do not yet meet its accounting population.

A value that depends on future option exercise is analytically different from one already represented by a non-cancelable obligation.

3. Cancellability and termination rights

Ask:

Palantir says many contracts contain termination provisions.

Vertiv says orders may be cancelled or rescheduled.

Palantir RPO, by contrast, is based on non-cancelable contracted revenue.

These are different contractual states.

But even here, avoid oversimplifying.

A cancellable order with penalties is not economically equivalent to an unqualified sales lead.

A non-cancelable obligation may still take years to convert.

The attributes matter together.

4. Estimates and delivery dependencies

Ask:

CoreWeave's Revenue Backlog can include estimated future revenue beyond RPO.

That additional component is subject to delivery and service-availability requirements.

CoreWeave RPO itself is net of estimated variable consideration.

So "accounting" and "estimated" are not opposites.

The right distinction is:

What is estimated?
Why?
Under which rules?
What condition remains?

5. Recognition timing

Ask:

This may be the most neglected dimension.

Palantir's RPO has a multi-year schedule.

CoreWeave's RPO stretches as far as 78 months.

Oracle's $664 billion RPO is overwhelmingly expected after the next 12 months.

Vertiv says the majority of its backlog is expected to ship within 12–18 months.

Two companies can therefore report the same nominal amount of "future demand" while having radically different duration profiles.

Backlog growth is not the same thing as revenue growth

A large future-demand number is attractive because it appears to offer visibility.

But the path from backlog to revenue has several moving parts.

Consider four different reasons the number can rise.

More underlying customer demand

The cleanest interpretation.

new contracts / orders ↑
        ↓
future-demand metric ↑

Longer contract duration

A customer signs more years rather than more near-term consumption.

total contract value ↑
RPO ↑

but

near-term revenue
may change much less

Oracle's recognition schedule makes this especially important.

Acquisitions

Vertiv says acquisitions contributed to its backlog growth.

A company can therefore report:

backlog +109%

without implying:

organic demand +109%

Metric composition changes

CoreWeave's Q1 2025 backlog contained a large estimated-future-revenue component beyond RPO.

By June 2026, RPO accounted for nearly all of the reported backlog.

So backlog growth over time needs to be interpreted together with the composition of the metric.

This leads to a useful decomposition:

FUTURE-DEMAND GROWTH
        │
        ├── new customer demand
        ├── larger contracts
        ├── longer duration
        ├── acquisitions
        ├── pricing / mix
        ├── estimated components
        └── definition / population changes

Without that decomposition, a large growth rate can create more confidence than the metric deserves.

The conversion path matters more than the label

The four companies illustrate four different paths from reported future demand to revenue.

Palantir Total Remaining Deal Value

remaining deal value
        │
        ├── customer option exercised?
        ├── contract remains in force?
        ▼
relevant performance obligation
        │
        ▼
service / performance delivered
        │
        ▼
revenue

Not every dollar necessarily passes through those stages in exactly the same way.

The point is that TRDV can include contractual economics that still depend on future assumptions.

Palantir RPO

non-cancelable contracted revenue
        │
        ▼
performance obligation satisfied
        │
        ▼
revenue

The accounting population is more constrained, but the recognition path may still stretch over several years.

CoreWeave Revenue Backlog

RPO
+
other estimated future revenue
from committed contracts
        │
        ▼
delivery / service availability
        │
        ▼
performance delivered
        │
        ▼
revenue

The operational dependency is particularly important for infrastructure-intensive businesses.

Oracle RPO

contracted revenue not yet recognized
        │
        ▼
performance obligation satisfied
        │
        ▼
revenue

The main analytical challenge is duration.

Vertiv Backlog

purchase order / commitment
        │
        ├── order remains active?
        ├── rescheduled?
        ├── reduced?
        ▼
product / service delivered
        │
        ▼
revenue

The label "backlog" is therefore only the starting point. The conversion mechanics underneath it carry the analytical meaning.

RPO is standardized accounting disclosure—but not a complete picture

RPO deserves special treatment because it is more standardized than most backlog KPIs.

Under ASC 606, it reflects transaction price allocated to remaining performance obligations, subject to the accounting rules and disclosure elections that apply.

That gives RPO an advantage:

RPO across companies

is generally a better starting point for cross-company comparison than:

company-defined backlog across companies

But "better starting point" is not the same as perfectly comparable.

The examples here show several reasons.

Short-duration disclosure expedients

Palantir uses the practical expedient that allows it not to disclose RPO for contracts with original expected durations of one year or less.

So RPO can omit economically real future business by design.

Variable consideration

Oracle elects not to disclose certain variable consideration allocated entirely to wholly unsatisfied obligations.

CoreWeave's RPO is net of estimated variable consideration, including expected service credits and delivery-delay effects.

Recognition schedules differ

Palantir:
38% next 12 months

Oracle:
13% next 12 months

CoreWeave:
41% in initial 24 months

Those percentages use different disclosure windows, but the broader lesson is clear:

A $10 billion RPO balance that converts rapidly is analytically different from a $10 billion RPO balance weighted toward years four and five.

RPO is not cash

RPO can include amounts not yet invoiced.

So it is not:

accounts receivable

and not:

cash collected

The sequence matters:

contract
→ performance obligation
→ RPO
→ invoice timing
→ revenue recognition
→ cash collection

Those events can occur in different orders depending on contract structure.

How to normalize future-demand metrics without flattening them

A useful data model should resist collapsing these measures into one numerical field called:

normalized_backlog

Instead, normalize hierarchically.

Layer 1 — reported metric

Preserve the company's exact label.

Total Remaining Deal Value
Revenue Backlog
Remaining Performance Obligations
Order Backlog

Layer 2 — analytical family

Map related metrics to:

metric_family:
    future_contracted_demand

This allows discovery:

Layer 3 — metric subtype

metric_subtype:
    accounting_rpo
    operational_backlog
    remaining_deal_value
    revenue_backlog
    bookings
    other

Layer 4 — contractual attributes

Preserve fields such as:

accounting_defined
noncancelable_required
customer_options_included
unexercised_options_included
termination_for_convenience
purchase_order_required
signed_contract_required
estimated_future_amounts_included
variable_consideration_treatment

Layer 5 — operating dependencies

delivery_dependency
service_availability_dependency
capacity_dependency
customer_acceptance_dependency

Layer 6 — recognition profile

expected_within_12_months
expected_months_13_36
expected_months_37_60
expected_thereafter

When companies disclose different buckets, preserve the reported schedule rather than forcing every issuer into fabricated standardized periods.

Layer 7 — definition vintage and provenance

filing_date
period_end
form
accession
section
definition_text
source_position
definition_vintage

This makes it possible to distinguish:

the metric changed

from:

the metric stayed the same but the amount changed

and:

the disclosure became more detailed

CoreWeave's SEC correspondence provides a useful example of the last case: later filings added detail about variable consideration and recognition timing, but that does not by itself prove the calculation methodology changed.

A five-question analyst test

Before using any backlog-like metric in a valuation, screen, or cross-company comparison, ask:

1. What gets into the number? Contract, option, purchase order, estimate, or accounting performance obligation?
2. Can the customer still change it? Cancel, terminate, reduce, defer, or reschedule?
3. What must the company still do? Deliver capacity, ship equipment, provide service, or satisfy another performance obligation?
4. When can it convert? Next year, over several years, or on an undisclosed schedule?
5. Is the definition stable? Same metric population and methodology as the historical observation being compared?

If those five answers are not aligned, the numerical comparison should carry an explicit caveat—or not be made at all.

How SourceState approaches future-demand visibility

The useful object is not:

Oracle backlog = $664bn

It is:

COMPANY
Oracle

REPORTED METRIC
Remaining Performance Obligations

METRIC FAMILY
Future-demand visibility

SUBTYPE
Accounting RPO

VALUE
$664bn

DATE
2026-08-31

DEFINITION
Contracted revenue not yet recognized

INCLUDES
Deferred revenue
Issued but uncollected invoices
Future amounts to be invoiced

DISCLOSURE ELECTION
Certain variable consideration excluded

RECOGNITION PROFILE
13% next 12 months
37% months 13–36
34% months 37–60
16% thereafter

SOURCE
Q1 FY2027 10-Q
Accession 0001193125-26-389274

For Palantir TRDV:

SUBTYPE
Remaining deal value

CUSTOMER OPTIONS
Assumed exercised

TERMINATION
Assumes contracts do not terminate

KNOWN CAVEAT
Many contracts contain termination provisions

RECOGNITION SCHEDULE
Not disclosed with the metric

For CoreWeave Revenue Backlog:

SUBTYPE
Revenue backlog

COMPONENTS
RPO
+
estimated future revenue from
committed contracts

DEPENDENCIES
Delivery
Service availability

For Vertiv:

SUBTYPE
Operational order backlog

ENTRY CONDITION
Purchase order or purchase commitment received

STATE
Product / service not yet delivered

CANCELLATION / RESCHEDULING
Possible

EXPECTED CONVERSION
Majority expected to ship within 12–18 months

That is far more useful than assigning all four values the same standardized label.

What SourceState can reconstruct today

The current four-company dataset supports several important layers of this model.

There are also important coverage limits.

CoreWeave has public-filing history only from 2025 onward.

The document-family event corpus is not complete for Palantir, Oracle, and Vertiv.

And several company-defined metrics exist primarily in narrative disclosure rather than standardized XBRL.

Those are not reasons to discard the data.

They are reasons to preserve provenance and data state explicitly.

The simplest way to think about backlog

When an analyst sees:

Backlog = $100bn

the number answers only the first question.

The next questions are:

What is included?
        │
        ├── signed contracts?
        ├── purchase orders?
        ├── customer options?
        ├── estimates?
        └── variable consideration?
        │
Can it change?
        │
        ├── cancellation?
        ├── termination?
        ├── rescheduling?
        └── service credits?
        │
What must happen?
        │
        ├── capacity delivered?
        ├── service available?
        ├── product shipped?
        └── performance obligation satisfied?
        │
When?
        │
        ├── next 12 months?
        ├── years 2–3?
        └── later?
        │
        ▼
REVENUE

That is the real structure of future-demand analysis.

Palantir's $11.2 billion TRDV and $4.1 billion RPO show that two numbers from the same company can answer different versions of the future-business question.

CoreWeave shows that backlog can be an explicit sum of accounting RPO and an additional estimated component.

Oracle shows that an enormous RPO balance can mostly represent revenue expected beyond the coming year.

Vertiv shows that operational backlog can be based on real customer orders while still allowing cancellation or rescheduling.

None of those observations makes the metric bad.

They make the definition indispensable.

That is the level at which future-demand metrics become genuinely comparable.