The Remaining Performance Obligation (RPO) SaaS Metric for the AI Industry

By Eric Mersch

[Editorial note: This previously published article, written by Eric Mersch, has been updated to reflect the RPO SaaS metric and its relevance specifically to the artificial intelligence industry.]

RPO Explained: From Accounting Rules to SaaS KPI

The Remaining Performance Obligation (RPO) reporting requirement arose from the adoption of ASC 606 / IFRS 15. 

This SaaS metric is defined as the sum of Deferred Revenue and Backlog. Deferred Revenue for SaaS companies is the non-cancellable contractual obligation to deliver the SaaS product for the period invoiced. 

The term Backlog refers to consideration due from future non-cancellable contractual obligations. A derivative of this metric, called the Current Remaining Performance Obligation (cRPO), refers to the service obligations over the next twelve months from the reporting period.

• Remaining Performance Obligation (RPO) – the sum of Deferred Revenue and Backlog, or more technically, total Remaining non-cancelable Performance Obligations.
• Current Remaining Performance Obligation (cRPO) – the sum of Deferred Revenue and Backlog that the company must deliver over the next twelve months.

The RPO Reporting Requirement

Prior to ASC 606 / IFRS 15, revenue guidance was governed by ASC 605 under US GAAP and IAS 18 / IAS 11 under the international standard IFRS. The two frameworks were materially inconsistent, which is precisely why the joint project created 606 / 15 and introduced RPO.

The then-current US GAAP and IFRS revenue recognition rules treated contracts differently, resulting in different revenue outcomes, and the new rules addressed this inconsistency. 

However, neither US GAAP nor IFRS addresses backlog disclosure. At that time, Deferred revenue was the only forward-looking balance sheet item, while remaining performance disclosure was not defined. Investors relied on Billings (non-GAAP), Bookings (non-standardized), and Backlog, which lacked standardized definitions. 

US GAAP and IFRS fixed these issues by defining RPO and requiring disclosure. This is the specific ASC 606 paragraph: 

An entity shall disclose the aggregate amount of the transaction price allocated to performance obligations that are unsatisfied (or partially unsatisfied) at the end of the reporting period, and an explanation of when the entity expects to recognize that amount as revenue. This is the formal definition of what practitioners call RPO.

To better understand the RPO concept, let’s look at a hypothetical example and then at real-world company reporting. 

Theoretical B2B Subscription Company

For our theoretical example, we will use a Business-to-Business (B2B) company because these companies typically have contract terms longer than one year. 

Assume that our theoretical company closes a three-year contract with an average Annual Contract Value (ACV) of $120,000. The contract is non-cancellable and requires a one-year upfront payment. When this company issues an invoice, the Billings date, it debits Accounts Receivable (AR) and credits Deferred Revenue (DR) by $120,000. 

At this point, the company has a contractual obligation to deliver the SaaS product for three years. However, only the first year’s economic activity is reflected in its financials. 

The Backlog, which is the dollar value of the remaining two years of the contract, is the sum of the contract’s second two years, or $240,000. The Backlog value is not recorded on the balance sheet. 

The Remaining Performance Obligation is the sum of the Deferred Revenue ($120,000) and the Backlog ($240,000), or $360,000.

Venture-backed companies have long tracked this dynamic, though not with RPO. We use the average Total Contract Value (TCV) and the TCV-to-ACV ratio to assess future revenue opportunities. In the example above, TCV is the value of the three-year deal ($360,000), and the TCV/ACV metric is 3.0x.

Public Company Example: Okta, Inc. (Nasdaq: OKTA)

Okta is a publicly traded technology company that offers subscription-based software products. 

As we saw in the example above, RPO is not a GAAP number and, therefore, does not appear on the balance sheet. Instead, companies report it in the Revenue from Contracts with Customers section of the public filings. The amounts are reported in millions, so not at the same level of detail as GAAP numbers. Companies often report RPO by revenue line item. 

Let’s review standard SEC reporting language for RPO and cRPO: Okta’s RPO definition states that RPO represents all future, non-cancelable, contracted revenue under our subscription contracts with customers that has not yet been recognized, inclusive of deferred revenue that has been invoiced and non-cancelable amounts that will be invoiced and recognized as revenue in future periods.

Current RPO represents the portion of RPO expected to be recognized during the next 12 months. Let’s break down these terms:

• Future – Revenue that will be recognized from contracts, but has not yet been earned or is not yet fully earned.
• Non-cancellable, Contracted revenue: ASC 606 only allows the inclusion of enforceable consideration; it explicitly excludes month-to-month customers, opt-out clauses such as termination for convenience, usage minimums without commitments, and pipeline/renewals.
• Subscription contracts: A subscription is a monthly price for access to software. Pricing schemes such as usage-based pricing and outcome-based pricing revenue do not qualify.
• Recognized as revenue in future periods: RPO only counts enforceable future revenue.
• Current RPO: cRPO is an estimate of revenue for the next 12 months. While cRPO is a twelve-month metric, it’s not the same as ARR. cRPO is a more valuable metric because it assumes contract enforceability, whereas ARR assumes 100% renewal.

Why Investors Care

RPO provides a high-probability estimate of future revenue. If the contractability of all contracts in the RPO calculation holds, which is a good assumption, then RPO describes guaranteed future revenue. Public companies valued based on revenue, in whole or in part, demonstrate support for their valuation. 

RPO also provides insight into a company’s revenue quality. A high RPO typically implies a high average Annual Contract Value, while a low RPO may signal short-term contracts or hybrid subscription/usage contracts. 

RPO and cRPO are also monitored over time. If revenue increases over the prior period but RPO and cRPO decline, the company is shifting revenue from RPO and cRPO, which lowers future revenue prospects. If RPO and cRPO are increasing faster than revenue, investors gain assurance that future revenue growth will be higher.

I use a metric I call the Revenue Visibility Horizon, defined as RPO/cRPO divided by Annual Revenue, specifically the Trailing Twelve Month Revenue.

In my experience, investors typically consider a range of eighteen to thirty months suitable for a business-to-business (B2B) subscription SaaS company. A result below 12 months indicates a dependence on renewals over the next year. 

From a SaaS perspective, ensure that you report on, and for investors, insist upon, a report of Renewal Rate in addition to Gross Revenue Retention and Net Revenue Retention. Conversely, a result above 1.5 to 2.5 years may indicate slower growth and/or greater uncertainty about earning revenue from the company’s RPO. 

Caution is Warranted

Like any metric, RPO is subject to factors that introduce variability, some of which are valid and some are, let’s say, not necessarily valid. 

You should be aware of the following dynamics. 

• A multi-year subscription deal will create a step-function increase in RPO. For example, a three-year contract with an Annual Contract Value (ACV) of $120,000 will increase RPO by $360,000.The magnitude of the change will depend on the term and the ACV compared to the RPO base.
• Usage contracts are not included in RPO, although I’ve seen this happen. For hybrid pricing (i.e., usage with a minimum commitment), the minimum commitment should be the only term in the RPO. But, again, I’ve seen usage added to RPO (as well as to Annual Recurring Revenue, ARR)
• Credit-based contracts, while not SaaS pricing models, should be included in RPO, provided they are non-cancellable. All hyperscalers offer credit-based pricing. Their customers purchase credits upfront, which do not expire, resulting in large RPO amounts and longer timeframes. For example, Google Cloud ended 2025 with $58 billion in revenue and $242 billion in RPO. 50% of Google Cloud’s RPO is expected to be earned beyond 24 months.
• The RPO metric does not capture counterparty risk. Although contracts must be non-cancellable to be included in the RPO metric, the customer(s) may lack the funds to meet their obligations, in whole or in part. You will find this dynamic when the RPO is abnormally high compared to annual revenue. Another warning sign is an unusually long conversion period from RPO to revenue. Oracle exemplifies both dynamics: its cloud revenue run rate is ~$35 billion, and its RPO is ~$523 billion, or 15x annual revenue. Additionally, about one-third of RPO is expected to be earned between 37 months and 60 months.
• RPO can also be misinterpreted as an understatement of growth for a company that offers usage with minimums or hybrid pricing, because the RPO-to-Annual Revenue ratio will be very small. Additionally, several AI-native companies are finding that customers purchase fewer credits in advance than they ultimately use. This has been the case for AI “vibe coding” companies such as Lovable and Cursor. 

A Better Framework for the AI Industry

AI-native companies and SaaS companies with AI features are increasingly using pay-as-you-go (PAYG) usage-based pricing and will not report RPO.  Lovable and Cursor are in this category. 

Many of these companies, including two of my AI clients, offer usage-plus-commitment pricing. For these companies, RPO is valuable only as a signal of customer willingness to commit to a specific capacity, i.e., commitment visibility. We can incorporate this metric into our reporting as RPO (or cRPO) divided by the next twelve months’ revenue estimate.

Results vary by business model, but a B2B SaaS company should operate in the 60% to 80% range. A company that sells to the federal, state, and local government will have a ratio above 80%, while a Product-Led Growth (PLG) model should operate in the 20% to 40% range. The benchmark is highly industry-specific. 

AI-native companies will also benefit from a non-RPO metric I call Usage Stability, which calculates the standard deviation (σ) of the monthly growth trend for a single cohort. Aggregate multiple cohorts for the best fit.

The formula is:

The calculation is more complex than common SaaS metrics, but the AI industry demands greater rigor in its calculations. 

To calculate Usage Stability, create a two-column table showing % monthly growth in spend by customer cohort. Then use the Excel formula =STDEV.S(range) to calculate the Standard Deviation. Subtract this number from one to get your answer. 

You will most likely get a number in the range from 0.70 (chaotic, highly variable usage) to 0.97+ (Hyperscaler operations).  SaaS companies that offer hybrid pricing, with usage-based pricing for AI features on their platform, should operate in the 0.90-0.94 range. 

RPO Still Matters, but the Rules Are Changing 

The Remaining Performance Obligation (RPO) metric is a valuable KPI for assessing the business’s momentum. Since its introduction in 2018, RPO and the next twelve-month’s RPO, Current RPO, or cRPO are invaluable metrics for investors and management teams. The best-in-class companies excel at reporting on these metrics and their derivatives. 

Companies that sell software on a usage-based pricing model can also benefit from RPO and cRPO, although these metrics are better used for measuring commitment visibility and behavioral predictability. Exercise caution because, as AI shifts monetization from commitment to embedded compute usage, RPO will increasingly underestimate forward revenue visibility.

If you are an operator at a subscription software company with multi-year deals, you should master using RPO as a key performance indicator.