You closed $2 million in signed contracts this year, yet your balance sheet shows only $400,000 of deferred revenue. An investor looks at the two numbers, does the subtraction in her head, and asks the question that decides whether your pipeline is real: where is the other $1.6 million, and when does it turn into revenue? If your answer is a spreadsheet of contract end dates and a shrug, you have just told her your backlog is a rumor. The number that answers her precisely is remaining performance obligations — RPO — and ASC 606 requires public companies to disclose it in their footnotes every quarter.
This guide explains what RPO measures, how it differs from deferred revenue and ARR, what the disclosure rules actually demand, and how to track it in your own books without a revenue-operations team.
What RPO actually measures
A remaining performance obligation is the transaction price allocated to a promise you have not kept yet. Under ASC 606, every customer contract is broken into distinct performance obligations — the platform access, the support plan, the onboarding project, each a separately identifiable promise — and the contract's total price is spread across them by standalone selling price. Whatever portion sits in obligations that are wholly or partially unsatisfied at the reporting date is your RPO: the aggregate dollar value of contracted work still to be delivered.
Three properties of that definition do most of the work:
- It is contractual, not forecasted. Pipeline, projections, and expected renewals are excluded. If the customer has not signed, it is not RPO.
- It is limited to the enforceable period. Only the window in which the contract binds both sides counts, which is why termination rights and renewal options matter so much (more on that below).
- It is a disclosure, not a balance sheet line. You will not find RPO in your chart of accounts. It lives in the footnotes to the financial statements, reconciling what you have contracted with what you have recognized.
For a SaaS business, RPO is the closest thing accounting gives you to a contracted order backlog: every dollar of it should become revenue as you deliver, provided the customer stays and pays.
The two halves: deferred revenue and unbilled backlog
The shorthand formula is simple:
RPO = deferred revenue + unbilled backlog
Deferred revenue — a contract liability in ASC 606's vocabulary — is the part you have already invoiced but not yet earned. The cash or receivable is in hand; the service is still owed. Unbilled backlog is the mirror image: contracted revenue you have not invoiced yet, usually because a multi-year deal bills annually or ramps over time. It never touches the balance sheet, which is exactly why investors ask for it. Deferred revenue shows the tip of the iceberg; RPO shows the whole thing.
Walk through a concrete contract and the relationship becomes obvious. Suppose you sign a three-year deal worth $420,000 total, billed $140,000 annually upfront, with service delivered evenly:
- At signing, before the first invoice, RPO is $420,000 — all of it backlog, none of it deferred revenue.
- After the year-one invoice, RPO is still $420,000, but its composition flips: deferred revenue is $140,000 and backlog is the remaining $280,000. Invoicing moves dollars between the two halves without changing the total.
- At the end of January, you have delivered one month of service and recognized $11,666.67 of revenue. RPO falls to $408,333.33: deferred revenue of $128,333.33 plus the untouched $280,000 backlog.
- Six months in, roughly $70,000 has been recognized and RPO stands near $350,000.
Notice the lifecycle these RPO dollars follow: each starts as backlog, passes through deferred revenue when invoiced, and lands on the income statement as revenue when earned. That invoice-first rhythm covers most SaaS contracts, so RPO and deferred revenue should always reconcile — and when they don't, something in your billing or recognition process is broken. (The exception proves the pattern: when you deliver before you bill, as in milestone-billed projects, earned-but-unbilled amounts travel through a contract asset instead of deferred revenue.)
What ASC 606 requires you to disclose
The disclosure rule sits at ASC 606-10-50-13, and it asks for two things: the aggregate transaction price allocated to remaining performance obligations, and an explanation of when you expect to recognize it. IFRS 15 carries the mirror requirement in paragraphs 120 through 122, so the shape below is the same for international filers.
The quantitative half is the headline number plus a timing breakdown in bands — most filers use amounts expected within one year, between one and two years, and beyond two years, with longer-dated businesses adding further buckets. The bands must add back to the aggregate figure, and similar contracts must use the same time frames so analysts can compare across segments and periods.
The qualitative half is the narrative that keeps the number honest:
- The nature of the obligations — what the RPO actually consists of, such as subscription access versus professional services versus support, since each converts to revenue on a different rhythm.
- Significant judgments — how you decided when obligations are satisfied, including the method you use to measure progress on obligations completed over time.
- Variable consideration — how uncertain amounts like usage overages, performance bonuses, or service-level (SLA) credits were estimated, and what was left out because a significant revenue reversal was possible.
- Material rights — options granted to customers, such as discounted renewals, that were counted as obligations in their own right.
One more requirement hides in the next paragraph of the standard: if you use any of the practical expedients described below, you must say so and describe the contracts they were applied to. The footnote has to admit what the number leaves out.
The one-year practical expedient — and the invoicing exception
ASC 606-10-50-14 offers two escape hatches that shrink most companies' disclosed RPO, and both must be disclosed when used.
The one-year exception lets you omit any contract whose original expected duration is one year or less, measured from the date the enforceable agreement begins. For a SaaS business selling monthly and annual plans, this expedient swallows nearly everything: if all your contracts run twelve months or under, your disclosed RPO may be zero or close to it even while deferred revenue is substantial. The assessment turns on the non-cancellable period, so a one-year contract with an automatic renewal still qualifies — the renewal is a future choice, not a current obligation — while a multi-year deal with a customer termination right counts only through the period the customer cannot walk away from. Contracts terminable at will without a substantive penalty are effectively excluded for the same reason: the enforceable duration is negligible.
The right-to-invoice exception applies when you bill in direct proportion to value delivered — the classic time-and-materials engagement or monthly billing on hours worked. There your receivable already captures what you have earned, and projecting the unperformed remainder would add paperwork without insight, so the standard excuses you from disclosing it.
The practical consequence is that two companies' RPO figures are rarely perfectly comparable. A vendor with three-year enterprise deals and no expedients reports a number dense with committed backlog; a product-led competitor on monthly terms reports almost nothing. Both are complying. Reading the footnote's expedient disclosure before comparing is not optional diligence — it is the only way to know what you are looking at.
cRPO: the number analysts actually model
Total RPO stretches as far as your longest contract, which makes it a bookings trophy and a forecasting headache in equal measure. Analysts solve this by zooming in on the first timing band: current RPO, or cRPO, the portion expected to be recognized within the next twelve months. It is the near-term revenue already locked in by signature, and it reads as a cleaner year-ahead indicator than either total RPO or ARR.
In the three-year, $420,000 example above, cRPO at signing is $140,000 — the first year's recognition — with $280,000 sitting in non-current RPO. As each month is delivered, cRPO burns down and is replenished by new signings and by last year's non-current slice rolling forward. The trend is the signal: when cRPO grows faster than recognized revenue, the next few quarters are already filling up; when it stalls while revenue climbs, growth is leaning on current consumption rather than new commitments.
Public filings show how this reads in practice. Snowflake, in its quarter ended July 31, 2026, reported $9.0 billion of total RPO with 54 percent expected to be recognized over the next twelve months — roughly $4.9 billion of cRPO — while total RPO grew 30 percent year over year against 35 percent revenue growth. (RPO figures move every quarter, so check the company's latest filing rather than quoting these.) The same filing carries the caveat that matters for consumption businesses: RPO is not necessarily indicative of future product revenue, because it cannot capture when customers will actually consume or whether they will consume beyond their contracted capacity. A straight-subscription vendor's RPO converts on a schedule; a usage-based vendor's converts on customer behavior.
Why investors read RPO before ARR
ARR gets the headlines, but seasoned SaaS investors open the footnotes first. The reason is definitional discipline. ARR is a company-defined run rate — annualized, often adjusted, unaudited, and computed a dozen different ways across the industry. RPO is GAAP-defined, contractually grounded, and audited: every dollar traces to a signed obligation with an enforceable price. When the two disagree, RPO is the one with receipts.
That discipline is also why RPO sees what ARR cannot. A three-year, $3 million deal and a one-year, $1 million deal can show identical ARR in year one, but their RPO differs by $2 million of committed future revenue. RPO rewards the multi-year enterprise motion that ARR flattens into a run rate, and it does so with the auditor looking over management's shoulder.
The rough ordering practitioners use puts the three headline metrics in size order:
RPO > ARR > deferred revenue
RPO spans all contract years, billed or not. ARR annualizes one year of contract value regardless of where you stand in the term. Deferred revenue holds only what has been invoiced and not yet earned. Each answers a different question — what is committed, what is the run rate, what is owed — and confusing one for another is how backlog gets double-counted or missed entirely.
Two neighboring metrics complete the vocabulary. Bookings measure deals signed in a period — sales activity, not future revenue — and a bookings record with flat RPO means contracts are churning out as fast as they sign. Billings, approximated as revenue plus the change in deferred revenue, measure what you invoiced. The chain from signature to cash runs bookings to RPO to billings to revenue, and each link answers for the one before it.
Four ways RPO misleads
RPO's contractual grounding makes it trustworthy, not truthful in every reading. Four traps catch even careful readers:
Comparing across different expedients. As noted above, the one-year and right-to-invoice exceptions mean disclosed RPO reflects contract structure as much as business momentum. Normalize for billing terms and read the expedient disclosure before ranking vendors.
Treating it as guaranteed revenue. RPO assumes customers stay, pay, and consume as contracted. It excludes renewals that have not been signed, constrains variable consideration that might reverse, and says nothing about credit risk. A customer bankruptcy converts backlog into a write-off, not revenue. Discount RPO the way you would any promise: by the promisor.
Ignoring consumption timing. For usage-based and hybrid businesses, the contract sets a ceiling while behavior sets the pace. A customer can hold a large commit and draw it slowly, or burn through early and keep spending past it. Pair RPO with consumption and net-retention data before forecasting.
Letting it drift from the ledger. RPO computed in a side spreadsheet from sales data quietly diverges from deferred revenue and recognized revenue in the books — different contract lists, different modification handling, different timing. The number that reconciles to the trial balance is the one worth disclosing; the one that doesn't is a second set of books wearing a footnote costume.
Contract modifications deserve a special mention inside that last trap. Adding distinct goods at their standalone price creates a separate contract and leaves existing RPO alone; anything else forces a prospective reallocation or a cumulative catch-up that rewrites the remaining obligation. Every mid-term upsell, extension, and downsell is an RPO event, and a process that captures them late reports stale backlog all quarter.
Tracking RPO in your own books
You do not need an enterprise revenue system to keep honest RPO. You need two schedules and the discipline to reconcile them: a revenue waterfall that shows each contract's remaining obligation by period, and a deferred revenue rollforward that ties billed-but-unearned balances back to the trial balance every close. If the waterfall's recognized column plus its remaining column does not equal each contract's total price, or if the rollforward does not tie to the ledger, stop and fix the plumbing before quoting any number to an investor.
A plain-text ledger makes the mechanics visible. Here is the three-year, $420,000 contract from above — year-one invoice, cash receipt, and January's straight-line recognition — exactly as it would post:
2026-01-01 open Assets:Cash:Operating USD
2026-01-01 open Assets:Receivable:Customers USD
2026-01-01 open Liabilities:Deferred-Revenue USD
2026-01-01 open Income:SaaS-Subscriptions USD
2026-01-05 * "Acme Corp" "Year 1 invoice on 3-year 420000 USD contract"
Assets:Receivable:Customers 140000 USD
Liabilities:Deferred-Revenue -140000 USD
2026-01-12 * "Acme Corp" "Year 1 payment received"
Assets:Cash:Operating 140000 USD
Assets:Receivable:Customers -140000 USD
2026-01-31 * "January revenue recognition" "1/12 of year 1"
Liabilities:Deferred-Revenue 11666.67 USD
Income:SaaS-Subscriptions -11666.67 USDAt month-end the ledger tells the RPO story directly: deferred revenue holds $128,333.33 of the invoiced year, the uninvoiced years two and three sit off-ledger as $280,000 of backlog, and RPO is their sum at $408,333.33. If you keep your books this way, the plain-text accounting docs show how to extend the pattern — one deferred-revenue account per customer or cohort keeps the rollforward a single query rather than a forensic exercise.
Close the loop monthly with three checks. First, every signed contract appears in the waterfall with its enforceable term and allocated price — nothing committed lives only in the CRM. Second, every invoice moves its amount from backlog to deferred revenue, and every recognition entry moves deferred revenue to income, so RPO always equals the two balances combined. Third, cRPO — the next twelve months of the waterfall — gets its own line in your board pack, because it is the number your investors will compute anyway. The month you can produce all three from reconciled books is the month your backlog stops being a rumor and starts being an asset.
