Remaining Performance Obligations (RPO): Formula and Examples

Justin (Do San Myung) is Expert Accountant at DualEntry with 20+ years of hands-on experience managing general ledgers, financial close processes, and ERP implementations for mid-market and enterprise companies. As a former Consulting CFO and Controller, he has personally overseen month-end closes, SOX compliance programs, and multi-entity consolidations across technology, manufacturing, and services industries. Justin specializes in transforming manual accounting workflows into automated, AI-driven processes.

Woosung Chun is the CFO of DualEntry with experience in corporate finance, accounting, strategy, and acquisitions. He previously grew from scratch and led the M&A and Finance teams at Benitago, where he completed more than 12 acquisitions in 2 years. He graduated with a BS from NYU Stern. At DualEntry, Woosung writes about AI in accounting, revenue recognition, foreign currency accounting, hedge accounting, and ERP modernization for finance teams navigating complex, multi-entity environments.

Remaining performance obligations, or RPO, is the total value of signed contracts a company hasn't delivered on yet. It's revenue the business has already won but hasn't earned, and for SaaS companies it's become one of the clearest signals of how much future revenue is locked in.
You'll run into it in public company filings, where it's a required disclosure, and in the board decks and investor updates that lean on it. It's forward-looking, contractual, and harder to inflate than a bookings number, because it's governed by ASC 606 and sits in the financial statement notes rather than in a company's own metric definitions.
What is a remaining performance obligation (RPO)?

A remaining performance obligation is the part of a customer contract a company has committed to deliver but hasn't recognized as revenue yet.
Add all of those up across every signed contract, and the total is the company's RPO: the future revenue it's contractually on the hook to earn.
RPO came out of ASC 606, the revenue recognition standard, which made it a required disclosure for public companies (ASC 606-10-50-13) [1]. In RPO accounting, the underlying question is how much of the transaction price is still allocated to performance obligations the company hasn't satisfied.
Before that, investors trying to gauge future revenue had to lean on deferred revenue, which only captures part of the picture, or on non-standard numbers like bookings and backlog that every company defined differently.
What makes the RPO metric useful is that it's a predictive indicator grounded in signed contracts. Bookings can be counted aggressively and annual recurring revenue (ARR) is an annualized run rate that each company defines for itself, but RPO rests on non-cancelable contracted revenue, so it's harder to dress up. [2] A rising RPO means a company is banking future revenue faster than it's working through the deals it already has.
How to calculate RPO
For a typical fixed-contract SaaS business, a useful shorthand is:
RPO = deferred revenue + contracted amounts not yet billed
Under ASC 606, the formal definition is the transaction price allocated to performance obligations that are still unsatisfied or partially unsatisfied. [1]
In practice, those amounts sit at different stages. Deferred revenue (a contract liability, in ASC 606's terms) [1] is money you've already invoiced but haven't earned yet because the service hasn't been delivered.
The rest is contracted revenue that hasn't been invoiced yet, often referred to as backlog (Salesforce, for one, calls it unbilled amounts) [3]. Add the two together and you get the value of signed business still waiting to be recognized.
A worked example
Take a SaaS company that signs a three-year contract with a total contract value (TCV) of $420,000 and an annual contract value (ACV) of $140,000, billed annually upfront. The service is delivered evenly across each year.
Here's what RPO looks like at two points in the contract. The figures are illustrative.
At signing, the whole $420,000 is RPO, because nothing has been delivered. The first year is invoiced, so it sits in deferred revenue; years two and three aren't billed yet, so they sit in backlog.
Six months in, the company has recognized $70,000 of revenue (half of the first year), which draws deferred revenue down to $70,000. Backlog hasn't moved, because year two hasn't been billed. So RPO falls to $350,000, the exact amount of contracted revenue still to come.
Splitting current and non-current RPO
Companies also disclose when they expect to recognize their RPO as revenue. For SaaS businesses, the portion expected within the next twelve months is often referred to as current RPO, or cRPO. [3], [4]
Current RPO (cRPO) is the part expected to be recognized in the next twelve months. Non-current RPO is everything beyond that.
In the example above, at signing the cRPO is $140,000 (year one) and the non-current RPO is $280,000 (years two and three).
Analysts watch cRPO most closely, because it's the near-term revenue that's already locked in, a cleaner read on the coming year than a total RPO number that stretches out several years. When a company's cRPO is growing faster than its revenue, the next few quarters are already filling up.
RPO vs. backlog vs. ARR vs. deferred revenue
RPO gets mixed up with the other forward-looking numbers a SaaS company tracks, and the differences matter, because they don't measure the same thing.
Here's how the four compare:
The short version is that RPO covers contracted revenue that hasn't yet been recognized, including deferred revenue and qualifying contracted amounts that haven't yet been billed.
ARR is a different animal, an annualized run rate of recurring revenue that each company defines for itself, isn't tied to specific contract terms, and isn't a GAAP figure, so a company's ARR and RPO measure different things and rarely match. [5] Bookings sit outside RPO too: a booking is the value of deals signed in a period, a flow that each company defines, while RPO is the contracted revenue still unrecognized at a point in time. A signed deal enters RPO only once it's an enforceable contract under ASC 606, and only for the part that hasn't been recognized yet. [1]
How finance teams actually produce RPO each quarter

RPO doesn't sit in one place waiting to be copied out. Finance teams assemble it every quarter from three sources: the contract data (what's been signed and for how long), the billing schedules (what's been invoiced), and the revenue schedules (what's been recognized).
Billings show how much has been invoiced during the period, while the revenue schedules show how much of that contracted amount has actually been recognized as revenue.
Deferred revenue comes off the ledger; backlog has to be pulled from the contracts that haven't been billed yet. The two are added, split into current and non-current, reconciled back to the ledger, and disclosed.
In spreadsheets, that's a quarterly scramble, and it's easy for the RPO number to drift away from the ledger it's supposed to reconcile to. When revenue recognition runs at the ledger level instead, the contract, billing, deferred revenue, and recognized revenue data needed to calculate RPO stays in one place. [6] In DualEntry, for example, the revenue waterfall report shows the remaining performance obligation by contract and period, and the rollforward report gives the deferred revenue roll-forward that reconciles to the trial balance. [7]
That gives finance teams a cleaner starting point each quarter, rather than rebuilding the underlying schedules from separate spreadsheets and systems.
How to read a public company's RPO disclosure

Most SaaS investors first meet RPO in a 10-K or 10-Q, tucked into the revenue note, or in the earnings release that comes out ahead of it. Once you know how to read it, it's one of the more useful lines in the filing.
Snowflake is a good example. As of its quarter ended July 31, 2026, it reported $9.0 billion in total RPO, with 54% expected to be recognized as revenue over the next twelve months, based on its customers' historical consumption patterns. [2]
Read together, those figures say the company had $9.0 billion of contracted revenue still to deliver, and roughly $4.9 billion of it (the 54%) should land within a year, what analysts would call its current RPO.
Three things to take from a disclosure like that:
- The split. A high current RPO relative to total means revenue is weighted toward the near term; a lower one means more of the contracted revenue sits further out. Snowflake's 54% points to a bit more than half its contracted revenue landing in the coming year, with the rest booked further out.
- The trend. Compare RPO growth to revenue growth. When RPO grows faster than revenue, the contracted pipeline is building ahead of what's being recognized; when it lags, growth is leaning more on current consumption than new commitments. Snowflake's RPO grew 30% year over year that quarter, a shade behind its 35% total revenue growth (product revenue grew 37%). [8]
- What it leaves out. RPO isn't a clean revenue forecast. Snowflake, a consumption-based business, says outright that RPO “is not necessarily indicative of future product revenue growth because it does not account for the timing of customers' consumption or their consumption of more than their contracted capacity” [8], so it's a weaker predictor of revenue than it would be for a straight subscription company. ASC 606 also lets companies leave out contracts with an original expected duration of a year or less (ASC 606-10-50-14) [1] and some variable consideration, [9] and requires them to say which exemptions they've used, so two companies' RPO figures aren't perfectly comparable.
Note: RPO figures change every quarter. The Snowflake figures above are from its quarter ended July 31, 2026 (reported September 2, 2026), so always check them against the company's latest filing.


