Performance Obligations Under ASC 606: A Practical Guide

You've signed a contract, collected the cash, and booked the revenue ratably because that's how the subscription works. Then your auditor asks why onboarding, implementation, support, or a success fee wasn't analyzed separately. The issue isn't whether the customer paid. It's whether you've identified every promise in the contract and recognized revenue only as each promise is satisfied.

For companies between $500K and $20M in revenue, that judgment affects more than the income statement. It changes deferred revenue, MRR presentation, gross margin by offering, investor reporting, and the support you'll need during diligence. Performance obligations are an operating process, not a year-end footnote exercise.

Table of Contents

• Why Performance Obligations Decide Your Real Revenue Number
  • The founder's contract view versus the accounting view
  • Why auditors focus on this judgment
• How to Identify a Performance Obligation Using the Two-Part Test
  • First test, can the customer benefit?
  • Second test, is the promise separately identifiable?
  • Setup fees need substance, not a label
• Allocating Transaction Price Across Multiple Obligations
  • Choosing a standalone selling price method
• Recognizing Revenue When Each Obligation Is Satisfied
  • The over-time criteria
  • A worked SaaS timing example
• When Remaining Performance Obligations Mislead Investors
  • Why the headline can overstate certainty
  • Questions to ask before presenting RPO
• Red Flags and Internal Controls for Month-End Close
  • The five controls that prevent recurring errors
• Your Audit-Ready Documentation Template and Next Steps

Why Performance Obligations Decide Your Real Revenue Number

A SaaS founder signs a $120,000 annual contract that includes software access and implementation. The founder assumes the entire amount should be recognized ratably across the subscription term. During the audit, the finance team concludes that implementation is a separate performance obligation. The allocation sends $30,000 into deferred revenue, while the remaining $90,000 is recognized over the service period.

The cash hasn't changed. The customer hasn't changed. The P&L and balance sheet have.

That distinction matters because ASC 606 requires revenue recognition when, or as, each performance obligation is satisfied by transferring control to the customer. The standard's five-step model includes identifying the contract, identifying performance obligations, determining transaction price, allocating that price, and recognizing revenue as obligations are satisfied. The ASC 606 revenue recognition framework is therefore driven by the promises you've made, not by your invoice schedule.

The founder's contract view versus the accounting view

Founders usually read contracts commercially. They see one customer, one order form, one annual fee, and one relationship. ASC 606 asks a different question: what distinct goods or services did you promise to transfer?

That difference creates recurring problems:

• MRR distortion: An implementation amount recognized immediately can inflate the period's recurring revenue even though the work is nonrecurring.
• Deferred revenue errors: A service paid upfront but not yet delivered can remain incorrectly classified as earned revenue.
• Margin confusion: If the contract price isn't allocated across deliverables, software margins can absorb implementation labor and project margins become meaningless.
• Due diligence friction: Buyers and investors will challenge revenue schedules that don't reconcile to contract promises and delivery evidence.

IFRS 15 made performance obligation a central unit of account globally. Issued in May 2014 and effective for annual reporting periods beginning on or after 1 January 2018, it replaced six older sources of revenue guidance, including IAS 11, IAS 18, IFRIC 13, IFRIC 15, IFRIC 18, and SIC-31. The IFRS 15 standard defines a performance obligation as a promise to transfer a distinct good or service, or a series of distinct goods or services that are substantially the same and have the same pattern of transfer.

Why auditors focus on this judgment

Auditors don't just inspect your invoice. They inspect the contract, sales materials, implementation statements of work, pricing history, acceptance terms, renewal language, and evidence that delivery occurred. A setup fee labeled “implementation” doesn't automatically become a separate obligation, and a bundled invoice doesn't automatically create one combined obligation.

Practical rule: If your revenue schedule starts with invoices rather than contract promises, your analysis is already pointed at the wrong source document.

ASC 606 became effective for public entities for interim periods within annual reporting periods beginning after 15 December 2017, with nonpublic entities receiving an additional year. The timing of adoption is historical, but the operating lesson remains current. Your accounting policy needs to work every month, across new deals, amendments, renewals, credits, and cancellations.

How to Identify a Performance Obligation Using the Two-Part Test

ASC 606 uses a two-part test for distinctness. A promised good or service is a separate performance obligation only when both conditions are met:

1. The customer can benefit from it on its own or with readily available resources.
2. The promise is separately identifiable within the context of the contract.

The test prevents two opposite mistakes. You shouldn't split a highly integrated bundle into artificial components, and you shouldn't combine services that the customer can use independently.

First test, can the customer benefit?

Start with the customer's ability to use the item. Software access, standard training, onboarding, support, and implementation each need their own analysis.

A customer can benefit from standard onboarding if the customer can use the SaaS product without that onboarding, or can obtain comparable assistance from another resource. Premium support can also be distinct when it doesn't modify the underlying platform and provides a separately identifiable service.

But benefit isn't limited to standalone use. The customer can benefit from a promised service together with resources that are readily available. For example, a standard data migration service may be usable with an existing system, even if the customer prefers the vendor to perform it.

Second test, is the promise separately identifiable?

The second test examines the contract as a whole. Ask whether one promise significantly modifies another, whether the promises are highly integrated, and whether the vendor is providing one combined output rather than separate deliverables.

Consider a SaaS agreement that includes:

If implementation is highly integrated with the software and the software cannot function for the customer without the implementation, the promises may form one combined performance obligation. If implementation is routine, separately usable, and doesn't significantly modify the platform, it may be a separate obligation.

Setup fees need substance, not a label

A setup fee isn't automatically revenue when billed. If the setup activity only prepares the customer to receive the underlying SaaS service and doesn't transfer a distinct service, the amount generally belongs with the related obligation. If the setup work creates a distinct deliverable the customer can benefit from independently, separate treatment becomes more supportable.

The ASC 606 revenue recognition discussion for SaaS arrangements is useful as a practical reminder: review the actual work performed, not just the product names used by sales.

Allocating Transaction Price Across Multiple Obligations

Once you identify separate performance obligations, allocate the transaction price using relative standalone selling prices. The allocation isn't based on which deliverable appears first in the contract or which invoice line carries the largest amount.

Assume an agency signs a contract with a total transaction price of $90,000, consisting of:

• Website build
• Monthly strategy and maintenance retainer
• Performance bonus

Management estimates the standalone selling prices as follows:

The $90,000 transaction price is allocated proportionally:

That allocation gives you the accounting answer. It doesn't determine the recognition pattern. The website amount follows the satisfaction pattern for the website obligation, the retainer follows the service period, and the bonus follows the related performance obligation if the variable consideration criteria are met.

Choosing a standalone selling price method

Observable separate-sale pricing is the strongest evidence when it exists. If you sell website builds to similar customers under similar conditions, those contracts can support the standalone price. When no direct observable price exists, ASC 606 expects estimation methods that maximize observable inputs.

The guidance on variable consideration allocation matters when the bonus relates specifically to one deliverable. ASC 606 permits allocating a variable amount entirely to one performance obligation only when the amount relates specifically to that obligation or outcome, and the result remains consistent with the overall allocation objective.

For example, a bonus tied only to successful website launch can remain with the website obligation when the criteria are satisfied. Don't spread it across unrelated retainer services just because the contract contains multiple lines.

Audit reality: Your allocation model is only as defensible as the pricing evidence behind it. A spreadsheet with clean formulas won't compensate for unsupported standalone selling prices.

Recognizing Revenue When Each Obligation Is Satisfied

Identifying and pricing obligations answers only part of the question. You still need to determine when control transfers.

A SaaS subscription is commonly recognized over time because the customer receives access and benefits throughout the service period. An agency website project may be recognized at a point in time when the customer obtains control of the completed deliverable. The contract language matters, but the delivery pattern matters more.

The over-time criteria

A performance obligation qualifies for over-time recognition when one of the applicable control-transfer patterns exists:

• The customer simultaneously receives and consumes benefits as you perform.
• You create or enhance an asset the customer controls while the work occurs.
• The asset has no alternative use to you, and you have an enforceable right to payment for performance completed to date.

SaaS access generally follows a ratable pattern when the vendor continuously provides stand-ready access over the contract term. A milestone-based agency project requires closer analysis. If the customer controls the work in progress, or if the agency has no alternative use for the customized asset and can enforce payment for work completed, over-time recognition may be appropriate.

A worked SaaS timing example

Assume a $60,000 annual SaaS contract includes a distinct $15,000 implementation obligation. For illustration, the remaining $45,000 relates to software access.

If implementation is satisfied upfront, the revenue pattern is:

If implementation is itself satisfied over the setup period, you recognize the allocated amount as the work progresses rather than booking it at launch. The total revenue doesn't change. The timing does, and that timing affects monthly results, deferred revenue, forecast accuracy, and management's interpretation of growth.

A contract that includes a milestone payment doesn't automatically support point-in-time recognition. You need evidence that the customer obtained control, that acceptance requirements were met, and that the obligation was satisfied.

The deferred revenue explanation for growing businesses provides the practical balance-sheet perspective. Cash received before satisfaction remains a contract liability until the related obligation is fulfilled.

When Remaining Performance Obligations Mislead Investors

Remaining performance obligations, or RPO, represent contracted future revenue that hasn't yet been recognized. That makes RPO useful as a pipeline disclosure, but RPO is not a guarantee of future cash or revenue quality.

One SEC filing reported approximately $27.9 million of expected revenue from RPO as of 31 March 2025, including about $10.9 million expected within the next 12 months. The SEC filing demonstrates the distinction between a total contracted balance and the portion expected to convert in the near term.

Why the headline can overstate certainty

RPO can change when customers terminate contracts, reduce scope, amend terms, or fail to renew optional services. Currency changes and estimated variable consideration can also affect the reported balance. If customers can cancel without a substantive penalty, the contractual amount carries less predictive weight than the headline suggests.

You should also inspect whether the company uses invoicing practical expedients for certain arrangements. An amount invoiced doesn't always represent a clean forecast of future recognized revenue, especially when billing timing and service delivery don't match.

Questions to ask before presenting RPO

Use RPO as a contract-quality discussion, not a vanity metric. Ask:

• Cancellation: Can the customer terminate for convenience, and what penalty applies?
• Scope: Does the balance include committed services or estimates subject to revalidation?
• Timing: What portion is expected within the next 12 months?
• Variable consideration: How much depends on milestones, usage, bonuses, or customer outcomes?
• Conversion: Does the recognition schedule reconcile to the contract ledger and delivery plan?

A smaller RPO balance with firm terms, clear delivery schedules, and limited variable consideration can be more informative than a larger balance exposed to cancellations and scope revisions. Investors should see the quality and timing of the obligation, not just the aggregate number.

Red Flags and Internal Controls for Month-End Close

Month-end close becomes unreliable when the contract review happens after the revenue entry. Your control should force the team to analyze promises, pricing, and satisfaction evidence before posting revenue.

The five controls that prevent recurring errors

• Contract intake: Route every material new contract, amendment, credit, and renewal through finance.
• Obligation memo: Record each promise, the distinctness conclusion, and the evidence supporting it.
• Pricing file: Maintain standalone selling price inputs, comparable contracts, cost assumptions, and approval.
• Recognition schedule: Link each obligation to a delivery event, service period, milestone, or progress measure.
• Balance-sheet reconciliation: Reconcile deferred revenue and RPO schedules to the general ledger and contract system.

Your close checklist should also capture sales and delivery communication. Finance may know the invoice changed, while the implementation team knows the scope changed. Neither fact alone gives you the complete accounting conclusion.

The month-end close best-practices guide can help you formalize ownership, review deadlines, and reconciliation evidence around the close. The important point is consistency. A well-designed policy applied only to large contracts still leaves smaller amendments capable of changing the revenue pattern.

Your Audit-Ready Documentation Template and Next Steps

For each material contract, create a revenue recognition memo with five sections:

1. Contract summary: Customer, term, consideration, amendments, cancellation rights, and promised deliverables.
2. Performance obligations: Each identified promise, the two-part distinctness analysis, and the reason for combining or separating items.
3. Standalone selling prices: Observable pricing or the selected estimation method, with supporting contracts, market evidence, cost assumptions, and approvals.
4. Allocation: Transaction price, relative standalone selling price calculation, and treatment of variable consideration.
5. Recognition timing: Point-in-time or over-time conclusion, satisfaction evidence, progress measure, and deferred revenue schedule.

Then take four practical actions. Review your top 10 contracts by revenue, document the distinctness analysis for each, reconcile deferred revenue to the performance-obligation schedule, and brief your auditor on the methodology before year-end. This process exposes unsupported assumptions while you still have time to fix them.

---

Jumpstart Partners provides outsourced controller and bookkeeping support for SaaS, agency, and professional-services businesses, including ASC 606 workflows, deferred revenue reconciliations, KPI reporting, and audit-ready financial packages. Visit Jumpstart Partners to discuss your contract review process, month-end close, and revenue recognition support.