Both IFRS 15 and ASC 606 follow the same 5-step model. Here's each step explained with real SaaS examples and zero accounting jargon.
Before you recognize any revenue, you need a real contract. Not a handshake. Not a verbal agreement. A contract that meets specific criteria.
A "contract" under IFRS 15 / ASC 606 isn't just a PDF someone signed. It's any agreement that creates enforceable rights and obligations between you and your customer. That could be a signed MSA, an online Terms of Service click-through, or even an oral agreement (though good luck proving that to an auditor).
For the standard to kick in, the contract must meet five criteria: both parties approved it, you can identify each party's rights, you can identify payment terms, the contract has commercial substance (it changes future cash flows), and it's probable you'll collect what you're owed.
If any criterion isn't met, you don't have a contract yet under the standard. You just have a promise. Revenue waits.
"An entity shall account for a contract with a customer that is within the scope of this Standard only when all of the following criteria are met: (a) the parties to the contract have approved the contract (in writing, orally, or in accordance with other customary business practices) and are committed to perform their respective obligations..."
"You have a contract when five things are true: both sides agreed to it, you know what each side has to do, the payment terms are clear, you'll probably get paid, and the deal has real economic purpose. If any of those are missing, don't recognize revenue yet."
They click "Subscribe," enter payment info, and agree to your Terms of Service. The ToS outlines what you provide (software access, support, uptime SLA), payment terms ($1,000/month), and cancellation policy. The customer is a funded startup with a track record of paying bills.
The SOW is signed, services are defined, payment terms are net-60. But the customer just disclosed they're restructuring debt, and their last three payments to other vendors bounced. You know this because your sales team flagged it.
Now that you have a contract, figure out what you actually promised to deliver. Each distinct promise is a separate "performance obligation."
A performance obligation is a promise to deliver something to the customer. It could be your software, implementation services, customer support, training, or a data migration. The key question is: is each promise distinct?
A promise is "distinct" if two things are true: (1) the customer can benefit from it on its own or with other resources readily available, and (2) it's separately identifiable from other promises in the contract. Think of it as: could you sell this thing by itself, and does it make sense on its own?
This matters because each distinct obligation might have different timing for when you recognize revenue. Software access is recognized over the subscription period. A one-time data migration might be recognized when the migration is done.
"A good or service that is promised to a customer is distinct if both of the following criteria are met: (a) the customer can benefit from the good or service either on its own or together with other resources that are readily available to the customer, and (b) the entity's promise to transfer the good or service to the customer is separately identifiable from other promises in the contract."
"A deliverable is a separate obligation if the customer can use it on its own AND it's not deeply tangled with your other promises. If you sell software + training, and the training is generic (not required to use the software), those are two separate obligations. If you sell software + heavy custom integration, and the integration only makes sense with the software, they might be one combined obligation."
Your SaaS product works out of the box. The onboarding is a standard 3-session training that helps customers get started faster, but it's not required. You sell the software without onboarding all the time. Other consultants could also deliver this training using your public docs.
You sell an AI platform that includes building a custom fine-tuned model for the customer's specific data. The custom model only works within your platform, and the platform's value to this customer depends heavily on having the custom model. The model training is deeply integrated with the platform setup.
Figure out how much money you expect to receive. Sounds simple, but variable pricing, discounts, and usage-based models make this interesting for SaaS.
The transaction price is the total amount you expect to receive in exchange for delivering on your promises. For a flat-rate SaaS subscription, this is easy: it's the contract price. But modern SaaS pricing makes this more complex.
You need to think about variable consideration (usage fees, performance bonuses, volume discounts), significant financing (if payment terms are extended beyond normal), non-cash consideration (rare in SaaS), and amounts paid to the customer (rebates, credits).
For variable amounts, you estimate using either the "expected value" method (probability-weighted average of possible outcomes) or the "most likely amount" (the single most likely outcome). Then you apply the constraint: only include variable amounts to the extent it's "highly probable" you won't have to reverse revenue later.
"An entity shall consider the terms of the contract and its customary business practices to determine the transaction price. The transaction price is the amount of consideration to which an entity expects to be entitled in exchange for transferring promised goods or services to a customer, excluding amounts collected on behalf of third parties."
"Add up everything the customer will pay you. If some amounts are uncertain (usage fees, bonuses), estimate them but only include amounts where you're highly confident you won't have to give it back. Don't include sales tax or anything you're collecting on someone else's behalf."
A customer signs a 12-month contract. The base fee is fixed at $6,000/year. But overage charges depend on actual API usage. Based on similar customers and the customer's projected usage, you estimate they'll use about 500K calls/month, generating $4,000/month in overages.
Customer signs a 12-month deal starting with 200 seats. If they add more seats during the year and cross the 500-seat threshold, the per-seat price retroactively drops to $8 for all seats. The customer is growing fast and has told you they plan to be at 600 seats by Q3.
If you have multiple performance obligations, split the total contract value across each one based on their relative standalone selling prices.
If you identified multiple performance obligations in Step 2 (say, software access + onboarding), you now need to divide the total transaction price from Step 3 across each obligation.
The method: use relative standalone selling prices (SSP). The standalone selling price is what you'd charge if you sold that thing by itself. If you sell your software for $30K/year and your onboarding for $5K when sold separately, those are your SSPs. The allocation is proportional.
If you don't sell something separately and don't have an observable price, you estimate using: adjusted market assessment (what would the market pay?), expected cost plus margin (what does it cost you + your target margin?), or residual approach (total price minus the known SSPs = what's left for the remaining obligation).
"The objective when allocating the transaction price is for an entity to allocate the transaction price to each performance obligation (or distinct good or service) in an amount that depicts the amount of consideration to which the entity expects to be entitled in exchange for transferring the promised goods or services to the customer."
"Split the total contract value across each thing you promised to deliver. Each piece gets a share based on what it would cost if sold separately. If you sell software for $30K and onboarding for $5K standalone, and the contract is for $32K total, the software gets 30/35 of $32K and onboarding gets 5/35 of $32K."
You sell an annual SaaS subscription and a standard onboarding package together for $32K. When sold separately, the software is $30K and onboarding is $5K (total SSP = $35K). The customer is getting a $3K discount on the bundle.
You sell the AI platform for $50K standalone. The white-glove support tier has never been sold separately — it's only offered as a bundle. You estimate the cost to deliver the support is $6K/year and your target margin is 40%.
The finish line. Revenue is recognized when (or as) you satisfy each performance obligation — either over time or at a point in time.
This is where the money hits your income statement. For each performance obligation, you decide: do you recognize revenue over time, or at a single point in time?
You recognize over time if any of these are true: (1) the customer receives and consumes the benefit as you deliver (SaaS access = over time), (2) your work creates or enhances an asset the customer controls, or (3) your work doesn't create an asset with alternative use to you and you have a right to payment for work done so far.
If none of those apply, you recognize at a point in time — when control transfers. For SaaS, this is less common but applies to things like delivering a one-time data export or a completed custom report.
For over-time recognition, you need a method to measure progress: output-based (units delivered, milestones reached) or input-based (hours worked, costs incurred as a % of total expected costs). For SaaS subscriptions, it's usually straight-line over the subscription period because the customer receives roughly equal benefit each day.
"An entity shall recognise revenue when (or as) the entity satisfies a performance obligation by transferring a promised good or service (ie an asset) to a customer. An asset is transferred when (or as) the customer obtains control of that asset. For each performance obligation identified in accordance with paragraphs 22-30..."
"Book the revenue when you've actually delivered what you promised. For SaaS subscriptions, that means spreading it evenly over the subscription period (the customer gets value every day). For one-time deliverables like a data migration, book it when the migration is complete and the customer has the data."
The customer gets continuous access to your platform. They receive benefit every day they can log in and use the software. There's no significant setup period — they start using it on day one.
You're moving 5 years of the customer's historical data from their old system into your platform. The migration takes 6 weeks. The customer can't benefit from a half-finished migration — they need all their data moved to start using the platform effectively.