⚠
Educational content only. This module is for informational purposes and does not constitute professional accounting, legal, or financial advice. Consult a qualified CPA for specific accounting decisions. RevLucid is not affiliated with IFRS Foundation, FASB, or NASBA.
1. The Core Question: When Does the Customer Get Control?
All the prior steps have built to this: you have obligations, a transaction price, and allocations. Now you ask: when does the customer obtain control of the good or service?
Control means the ability to direct the use of, and obtain substantially all the remaining benefits from, the asset. Under both IFRS 15 and ASC 606, you recognize revenue when or as control is transferred — not when cash is received, not when you deliver the product, and not when the customer uses it.
There are two categories:
- Over time: Control transfers continuously as you perform — recognize revenue as you go
- Point in time: Control transfers at a specific moment — recognize revenue at that instant
Default is point in time. Over-time recognition requires meeting at least one of three specific criteria. If none apply, the obligation is satisfied at a point in time. Many SaaS obligations ARE over-time — but the analysis must be performed, documented, and auditable.
2. The Three Over-Time Criteria
An obligation is satisfied over time if the entity meets at least one of the following three criteria. You only need one — but you must test all three before concluding the obligation is point-in-time.
Criterion 1 — IFRS 15.35(a) / ASC 606-10-25-27(a)
The Customer Simultaneously Receives and Consumes Benefits
The customer receives and consumes the benefit of the entity's performance as the entity performs. Another entity stepping in to complete the work would not need to substantially re-perform what has been done.
Classic SaaS example: CRM software like Salesforce. The customer uses the platform every day — each day of access consumed cannot be recovered if Salesforce were replaced mid-contract. Revenue recognized ratably over the subscription term.
AI example: An AI data processing service running continuous inference jobs. Each processed job benefits the customer immediately and cannot be "unprocessed."
Also applies to: Data feeds, continuous monitoring services, recurring analytics, API access with real-time responses.
Criterion 2 — IFRS 15.35(b) / ASC 606-10-25-27(b)
Entity Creates or Enhances a Customer-Controlled Asset
The entity's performance creates or enhances an asset (e.g., work in process) that the customer controls during the creation process — not just upon completion.
Example: A software development firm building a module directly into the customer's proprietary codebase. The customer controls the code repository and can direct changes throughout. Each commit enhances an asset the customer already controls.
AI example: Fine-tuning an AI model on the customer's infrastructure and data, where the model weights are stored in the customer's own cloud environment throughout the fine-tuning process.
NOT this criterion: Building something in your own environment and delivering it at the end — that's typically Criterion 3 territory, not 2.
Criterion 3 — IFRS 15.35(c) / ASC 606-10-25-27(c)
No Alternative Use + Enforceable Right to Payment for Work Completed to Date
This is a two-part test — both parts must be met simultaneously:
- No alternative use: The entity's performance creates an asset that has no alternative use to the entity — it cannot be redirected to another customer (due to practical or contractual limitations)
- Right to payment: The entity has an enforceable right to payment for performance completed to date throughout the contract term (including if the customer terminates without cause)
Example (over time): Custom enterprise software built for Customer A's unique workflow. The code cannot be reused for other customers (no alternative use). The contract requires Customer A to pay for all work completed to date if terminated. Both criteria met → over-time recognition.
Both parts are required — either alone fails. A custom asset with no alternative use but NO right to payment for work-in-progress → point-in-time. An asset with right to payment but that CAN be sold to other customers → point-in-time. This is the most commonly misapplied criterion in AI/bespoke development contracts.
3. Point-in-Time Recognition: Five Indicators
If none of the three over-time criteria are met, recognize revenue at a point in time. The standards provide five indicators of when a customer has obtained control:
| # |
Indicator |
SaaS / Tech Example |
| 1 |
Present right to payment — customer is obligated to pay |
Software license payment is due and collectible |
| 2 |
Legal title has transferred to the customer |
Perpetual license transfer, sold IP rights |
| 3 |
Physical possession transferred (less relevant for SaaS) |
On-premise software delivered; hardware shipped |
| 4 |
Significant risks and rewards transferred to customer |
Customer bears obsolescence risk on perpetual license |
| 5 |
Customer accepted the asset |
UAT sign-off, go-live acceptance, formal acceptance clause triggered |
No single indicator is determinative. You assess all five holistically. Indicator #5 (customer acceptance) is frequently the most meaningful in SaaS and AI implementations — if a formal acceptance clause exists, revenue typically cannot be recognized until acceptance is received.
4. Measuring Progress for Over-Time Obligations
Once you determine an obligation is satisfied over time, you must measure progress toward complete satisfaction — and recognize revenue in proportion to that progress. You choose between two broad approaches:
Approach A
Output Methods
Recognize revenue based on direct measures of value transferred to the customer relative to remaining performance.
Methods include:
- Units delivered (API calls processed, reports generated)
- Milestones reached (if each milestone independently represents a discrete portion of the total value)
- Surveys of performance completed
- Appraisals of work performed
Best when: There is a direct, observable relationship between outputs and value transferred. Most usage-based SaaS naturally uses output methods.
Example:
AI image generation API — recognize revenue per image rendered. Each output (image) is a direct measure of value transferred.
Approach B
Input Methods
Recognize revenue based on entity's inputs (effort, costs, time) relative to total expected inputs required to satisfy the obligation.
Methods include:
- Costs incurred (percentage-of-completion based on cost-to-cost ratio)
- Labor hours expended
- Time elapsed (ratable/straight-line — a specific form of input method)
- Machine hours used
Best when: Outputs are difficult to measure but inputs correlate well to value transferred. Common in implementation services, consulting, and long-term development contracts.
Example:
Enterprise software implementation — recognize revenue based on labor hours incurred relative to total estimated labor hours (cost-to-cost input method).
The Ratable (Straight-Line) Method
For subscription services with consistent availability (like SaaS licenses), straight-line recognition over the subscription period is generally the most appropriate measure — recognizing equal revenue each period the service is available. This is technically an input method (time elapsed) but is so common in SaaS that it's worth calling out explicitly.
Beware of "time elapsed" as a proxy. Ratable recognition is only appropriate when the entity stands ready to provide service equally throughout the period. If performance is front-loaded or back-loaded (e.g., heavy implementation work in month 1, then light maintenance), ratable recognition may not faithfully represent transfer of control. Auditors scrutinize this.
5. SaaS & AI Revenue Recognition Patterns
Pattern 1: Pure SaaS Subscription
Cloud Platform — Monthly/Annual License
Over-time via Criterion 1 (customer simultaneously receives and consumes). Recognize ratably over the subscription period.
Timing note: If payment is annual upfront but service is monthly, recognize $10K/month on a $120K annual contract. The upfront payment creates a contract liability (deferred revenue), drawn down monthly.
Recognition:
Straight-line over the subscription term.
Pattern 2: Usage-Based / Consumption Model
API Calls, Data Processing, Token Consumption
Over-time via Criterion 1. Revenue recognized as usage occurs (each API call, each token processed). Subject to the sales-based royalty exception if the usage fee is based on licensed IP (see Section 6).
Measurement: Output method — units consumed. Monthly billing based on actual usage is the most common approach.
Recognition:
As usage occurs — typically monthly based on actual consumption data.
Pattern 3: Professional Services / Implementation
Custom Configuration, Onboarding, System Integration
Often point-in-time if there is no right to payment for work-in-progress OR if the output can be reused for other customers. Can be over-time via Criterion 3 if no alternative use + enforceable right to payment for WIP.
Measurement (if over-time): Input method — labor hours or cost incurred relative to total estimated cost. Requires frequent re-estimation of total project cost.
Recognition:
Depends on contract terms. Analyze Criterion 3 carefully — particularly the right-to-payment clause.
Pattern 4: AI Model Training / Fine-Tuning
Custom ML Model Development
The most nuanced pattern. Analysis depends on: (a) who controls the model weights during training, (b) whether the model can be reused for other customers, and (c) payment terms on termination.
- Customer controls weights throughout: Over-time via Criterion 2
- No alternative use + right to payment for WIP: Over-time via Criterion 3
- Neither: Point-in-time at delivery/acceptance
Recognition:
Requires careful contract review. Most bespoke AI development contracts settle on point-in-time absent explicit right-to-payment language for WIP.
6. The Sales-Based and Usage-Based Royalty Exception
This is one of the most specific and practically important rules in Step 5 for technology companies. It overrides the general variable consideration rules (Module 4) for a specific category of fees.
What the Exception Says
If a license of intellectual property is the predominant item in a contract, and the customer pays a sales-based or usage-based royalty on that IP, you must recognize revenue only when (or as) the usage/sales occurs — not earlier, even if you could estimate the amount reliably.
This exception is a recognition prohibition, not just a constraint on estimation. Unlike general variable consideration (where you apply the constraint and recognize an estimated amount), the royalty exception prevents any recognition of usage fees until the usage actually occurs. No probability weighting. No estimates. Wait for the usage event.
When it Applies
Three conditions must all be present:
- The contract includes a license of intellectual property (software license, patent rights, trade secrets, franchise)
- The variable consideration is structured as a royalty specifically tied to sales or usage by the customer
- The license is the predominant item to which the royalty relates (or the royalty relates to both a license and other goods/services and the license is predominant)
SaaS / AI Practical Examples
| Contract Type |
Exception Applies? |
Why |
| Per-token AI API fee (licensed model) |
Typically YES |
Usage-based royalty on licensed IP (the AI model); recognize per token processed |
| % of revenue share for SaaS platform |
Likely YES |
Sales-based royalty on licensed software; recognize as customer's sales occur |
| Per-seat SaaS subscription (fixed per user) |
NO |
Not sales/usage-based — fixed per seat; normal variable consideration rules apply |
| Service fee based on client's revenue (consulting) |
Depends |
Only if the fee is tied to a license of IP, not pure service performance. If it's for services, exception doesn't apply. |
IFRS 15 vs ASC 606 — same rule: Both standards contain the identical sales/usage-based royalty exception. This is one of the areas of complete convergence between the standards.
7. Practical Expedients in Step 5
Right-to-Invoice Practical Expedient
If the entity has a right to invoice the customer for an amount that directly corresponds to the value the customer received to date (e.g., $200/hour for 10 hours = $2,000 billed = $2,000 revenue), the entity may recognize revenue equal to the amount it has the right to invoice.
When available: Only for over-time obligations. The invoiced amount must correspond directly to value delivered — a common hurdle for milestone-based billing where milestone amounts don't correspond to proportional value.
Shipping and Handling After Control Transfers
Entities may elect to treat shipping/handling activities occurring after control transfers to the customer as fulfillment costs rather than as a separate performance obligation. This is a practical expedient that reduces complexity for companies that ship hardware as part of their SaaS bundle.
8. Step 5 Recognition Decision Tree
OVER-TIME OR POINT-IN-TIME?
Performance Obligation Identified
Does customer simultaneously receive
and consume benefits as you perform?
(Criterion 1)
YES
OVER-TIME
Recognize as performance occurs
(usually ratable or output method)
NO
Does your performance create/enhance
an asset the customer controls
during creation? (Criterion 2)
YES
OVER-TIME
Recognize as asset is
created/enhanced
NO
Does the asset have NO alternative use
AND do you have an enforceable right
to payment for WIP? (Criterion 3)
BOTH YES
OVER-TIME
Recognize as performance
occurs (input method typical)
EITHER NO
POINT-IN-TIME
Recognize when control
transfers (use 5 indicators)
9. Real Company Case Studies
Salesforce's core CRM products (Sales Cloud, Service Cloud, Marketing Cloud) are subscription-based SaaS. Under ASC 606, Salesforce recognizes subscription revenue ratably over the subscription term via Criterion 1 — customers receive and consume CRM access equally throughout the subscription period.
Deferred revenue: Annual or multi-year subscriptions billed upfront create contract liabilities (deferred revenue). As of Salesforce's recent 10-K, deferred revenue exceeds $20 billion — representing future subscription revenue already billed but not yet recognized.
Professional services: Implementation and configuration services are generally recognized over time as work is performed (input method — hours incurred), OR at point-in-time for discrete deliverables when the right-to-payment test under Criterion 3 is not met. Salesforce distinguishes carefully between customer-controlled implementations (Criterion 2 potentially) and generic implementations that Salesforce could reuse methodologies from (point-in-time).
From Salesforce 10-K (paraphrased): "We recognize subscription and support revenues ratably over the contract terms beginning on the commencement dates of each contract. Amounts billed in advance of the subscription term are recorded as deferred revenue and recognized over the remaining subscription period."
Zoom's core video communications platform (Zoom Meetings) is recognized ratably over the subscription term under Criterion 1. However, Zoom's product mix has expanded to include Zoom Phone, Zoom Webinars, Zoom Revenue Accelerator (AI sales tool), and hardware bundles.
Usage-based components: Zoom Phone includes per-minute charges for outbound PSTN calls. These fees are recognized as the calls occur (output method / usage-based). If the per-minute fee relates to licensed IP (the Zoom Phone software), the usage-based royalty exception may apply — recognizing revenue as minutes are consumed.
AI features: Zoom's AI Companion (meeting summaries, conversation intelligence) is bundled into the platform subscription. Since it's part of the core service the customer continuously receives and consumes (Criterion 1), revenue is recognized ratably — no separate performance obligation treatment needed if the AI features aren't distinct.
Key takeaway: As AI features become bundled into SaaS platforms (rather than sold separately), they typically fold into the Criterion 1 over-time pattern of the host subscription. When sold as standalone AI services with usage fees, the royalty exception triggers — recognize as usage occurs.
10. IFRS 15 vs. ASC 606: Step 5 Comparison
| Topic |
IFRS 15 |
ASC 606 |
| Over-time criteria |
Three criteria, same as ASC 606 (IFRS 15.35) |
Three criteria, same as IFRS 15 (ASC 606-10-25-27) |
| Point-in-time indicators |
Five indicators, same as ASC 606 (IFRS 15.38) |
Five indicators, same as IFRS 15 (ASC 606-10-25-30) |
| Progress measurement methods |
Output and input methods (IFRS 15.41) |
Output and input methods (ASC 606-10-25-36) |
| Sales/usage-based royalty exception |
Applies to licenses of IP (IFRS 15.B63) |
Applies to licenses of IP (ASC 606-10-55-65) |
| Right-to-invoice expedient |
Available for over-time obligations (IFRS 15.B16) |
Available (ASC 606-10-55-18) |
| Licenses of IP — more detailed guidance |
Principles-based; less detailed on functional vs. symbolic license distinction |
Provides explicit guidance on functional vs. symbolic licenses (ASC 606-10-55-54 through 55-65A) |
| Licenses: Functional vs Symbolic |
Not explicitly categorized; use judgment on nature of promise |
Functional license (right to use IP as it exists at grant date) = point-in-time. Symbolic license (access to ongoing IP) = over-time. Significant practical difference for software licenses. |
The functional vs. symbolic license distinction is a key area where ASC 606 US GAAP provides more explicit guidance than IFRS 15. For SaaS companies reporting under both standards, the analysis of whether a software license is "functional" (static — recognize at delivery) vs. "symbolic" (ongoing — recognize over time) can lead to different revenue timing under each framework. Most SaaS perpetual licenses are functional; most subscription licenses are symbolic.
Flashcard Drill
Click any card to flip it. Final set — 10 cards completing the 5-step model.
Over-Time vs. Point-in-Time
The Step 5 choice
tap to flip ↻
Default is point-in-time. Over-time recognition requires meeting at least one of three criteria. If none apply, recognize at the point when control transfers to the customer.
Over-Time Criterion 1
Simultaneous receipt and consumption
tap to flip ↻
The customer simultaneously receives and consumes the benefits as the entity performs. Another entity would not need to substantially re-perform completed work. Most SaaS subscriptions and API access services qualify.
Over-Time Criterion 2
Creates/enhances customer-controlled asset
tap to flip ↻
The entity creates or enhances an asset the customer controls during the creation process — not just upon completion. Customer must control the asset throughout (e.g., code committed directly to customer's repo; model trained on customer's infrastructure).
Over-Time Criterion 3
No alternative use + right to payment for WIP
tap to flip ↻
TWO-part test — both required: (1) No alternative use: asset cannot be redirected to another customer. (2) Right to payment: entity has enforceable right to compensation for work completed to date if customer terminates. Failing either condition = point-in-time.
Output Method (Progress Measurement)
Measuring over-time progress
tap to flip ↻
Measure progress based on direct value transferred to customer: units delivered, milestones reached, API calls processed. Best when a direct relationship exists between entity's outputs and value received by customer. Common for usage-based services.
Input Method (Progress Measurement)
Measuring over-time progress
tap to flip ↻
Measure progress based on entity's inputs: costs incurred, labor hours, time elapsed (ratable). Most appropriate when inputs correlate well to value transferred. Time elapsed (straight-line) is the most common approach for SaaS subscriptions. Cost-to-cost is standard for long-term contracts.
Sales/Usage-Based Royalty Exception
License of IP + royalty fee
tap to flip ↻
When a license of IP is the predominant item and consideration is a sales or usage-based royalty, recognize revenue ONLY when (or as) the usage or sale occurs. No estimates allowed — must wait for the actual event. Applies to both IFRS 15 and ASC 606 identically.
Functional vs. Symbolic License (ASC 606)
US GAAP distinction not in IFRS 15
tap to flip ↻
Functional license: customer has right to use IP "as it exists" at grant date — recognize revenue at point in time (delivery). Symbolic license: customer accesses evolving IP over time (ongoing updates, platform — typical SaaS) — recognize over the access period. IFRS 15 does not use these terms but reaches similar conclusions through principles.
Right-to-Invoice Expedient
Practical expedient for over-time obligations
tap to flip ↻
If the invoiced amount directly corresponds to the value delivered to date, entity may recognize revenue equal to the amount invoiced. Only available for over-time obligations. The invoice amount must faithfully represent value transferred — milestone billing that doesn't correspond to proportional value does NOT qualify.
Control — Step 5 Definition
The central concept
tap to flip ↻
Control = the ability to direct the USE of, and obtain substantially all the remaining BENEFITS from, an asset. Revenue recognition is triggered by transfer of control — not delivery, not billing, not cash receipt. The five point-in-time indicators help identify when control has transferred.
Knowledge Check
Final three questions. Put the full 5-step model to work.
Question 1 of 3
A SaaS company provides a cloud-based CRM platform to enterprise customers under annual subscription contracts billed upfront. Customers access the platform continuously throughout the year. Which over-time criterion applies, and how should revenue be recognized?
A
Point-in-time — control transfers when the customer first logs into the platform
B
Over-time via Criterion 1 — customer simultaneously receives and consumes CRM access; recognize ratably over the subscription term
C
Over-time via Criterion 3 — no alternative use because the CRM is configured for this specific customer
D
Point-in-time — recognize all revenue at the start of the subscription because the customer paid annually upfront
Correct: B — Over-time via Criterion 1, ratable recognition.
CRM platform subscriptions are the textbook example of Criterion 1 (simultaneously receives and consumes). Each day of CRM access consumed cannot be reversed — if the vendor switched mid-year, a replacement vendor would need to start fresh. Revenue is recognized ratably: $120K annual = $10K/month regardless of upfront billing.
Why C is wrong: Configuration for a specific customer doesn't meet Criterion 3. "No alternative use" means the underlying asset can't be redirected — but a CRM platform can serve many other customers. Configuration is entity-performed setup, not an asset transferred to the customer's control. Criterion 3 requires BOTH no alternative use AND right to payment for WIP, and even then it wouldn't apply here.
Why D is wrong: Billing timing doesn't determine revenue recognition timing. Annual upfront billing creates deferred revenue (a contract liability), drawn down each month as the performance obligation is satisfied.
Question 2 of 3
An AI company is contracted to build a custom fraud detection model for a bank. The model will be built on the AI company's own servers, trained on the bank's historical transaction data (uploaded by the bank). The contract includes: (a) no right to payment if the bank terminates before delivery, and (b) the AI company is prohibited from using the resulting model for any other customer. The project takes 6 months. When should the AI company recognize revenue?
A
Over-time via Criterion 1 — the bank receives benefit from the AI training process as it progresses
B
Over-time via Criterion 2 — the model is an asset the bank controls throughout training because the bank owns the data
C
Over-time via Criterion 3 — the model has no alternative use (contractual restriction) plus the no-alternative-use condition is met
D
Point-in-time — Criterion 3 fails because there is no enforceable right to payment for work completed to date
Correct: D — Point-in-time recognition.
This tests Criterion 3 carefully. The no-alternative-use condition IS met (contractual restriction prevents using the model for other customers). However, the contract explicitly states no right to payment if the bank terminates before delivery. This fails the second required element of Criterion 3.
Both parts of Criterion 3 are required: No alternative use alone is not sufficient. Without an enforceable right to payment for work completed to date, the criterion fails entirely — and the obligation is point-in-time. The AI company recognizes revenue when control transfers at delivery/acceptance.
Why B is wrong: Criterion 2 requires the customer to control the asset during creation. The bank owning its data does not mean it controls the model being developed on the AI company's servers. Control of source data ≠ control of the work-in-progress model.
Why C is wrong: Only half of Criterion 3 is met. No alternative use is necessary but NOT sufficient. The missing right-to-payment element is fatal to Criterion 3.
Question 3 of 3
An AI platform company licenses its proprietary language model to enterprise clients. The contract includes a $50K base annual access fee plus $0.005 per token processed by the client using the licensed model. At contract inception, the company estimates the client will process approximately 10 million tokens ($50K variable fees). How should the $0.005/token usage fees be recognized?
A
Include the estimated $50K variable fee in the transaction price at inception, subject to the variable consideration constraint — recognize ratably with the base fee over the contract year
B
Recognize the estimated $50K variable fee at contract inception (the estimate meets the "highly probable not to reverse" threshold given the client's history)
C
Recognize token-based fees ONLY as tokens are actually processed — the sales/usage-based royalty exception applies and prohibits earlier recognition regardless of estimation confidence
D
Recognize token fees at year-end when actual annual usage is fully known and revenue can be measured reliably
Correct: C — Recognize as tokens are processed (usage-based royalty exception).
This is the critical application of the sales/usage-based royalty exception (IFRS 15.B63 / ASC 606-10-55-65). All three conditions are met:
1. There is a license of IP (the proprietary language model)
2. The variable fee is a usage-based royalty ($0.005/token)
3. The license is the predominant item
The exception overrides normal variable consideration rules. Even if you could estimate the $50K reliably (which you might), and even if it were highly probable not to reverse, the exception prohibits recognizing token fees before the tokens are actually processed. This is a recognition prohibition, not just an estimation constraint.
Why A and B are wrong: Both rely on general variable consideration principles (Module 4). However, the royalty exception takes precedence and explicitly prohibits earlier recognition than the point of actual usage for license royalties.
Why D is wrong: You don't wait until year-end. Recognize as usage occurs — typically monthly based on actual token consumption reported in billing data. Monthly recognition of actual usage is standard practice for usage-based AI API contracts.
🎉 Course Complete!
You've worked through all 6 modules of the IFRS 15 / ASC 606 CPE course — the full 5-step model from contract identification to revenue recognition. You've covered 60 flashcards, 18 quiz questions, and applied the framework to real-world SaaS, AI, and tech company scenarios.