Revenue Recognition for SaaS Companies
Revenue Recognition for SaaS Companies — How IFRS 15 applies to every SaaS contract type — multi-element bundles, setup fees, usage-based pricing, professional services, free trials, discounts, and the judgements that determine when each euro is earned.
5 Key Takeaways From This Page
IFRS 15 (Revenue from Contracts with Customers) has been effective since 2018 and applies to any Estonian company that reports under IFRS or that has investor or lender requirements specifying IFRS-compliant accounts. It replaced all previous revenue standards with a single comprehensive framework.
A performance obligation is a distinct promise to transfer a good or service to a customer. Identifying all the separate promises in a SaaS contract — access to software, setup, support, training, professional services — determines how the total price is split and when each portion is recognised.
When a contract contains multiple performance obligations, the total transaction price is allocated based on each obligation’s standalone selling price (SSP) — the price the company would charge if it sold that obligation independently. SSP is estimated using observable data where possible.
Performance obligations are satisfied either over time (continuously, like subscription access) or at a point in time (one-off, like a setup completion or software delivery). These produce fundamentally different revenue timing patterns.
Usage-based pricing, volume discounts, refund rights, and performance bonuses create variable consideration — amounts the company may receive but cannot be certain of. IFRS 15 requires these to be estimated and constrained to amounts unlikely to reverse.
What does IFRS 15 mean for a SaaS company’s revenue recognition? Every contract with a customer must be analysed through the five-step model: identify the contract, identify distinct performance obligations within it, determine the transaction price, allocate the price to each obligation based on standalone selling prices, and recognise revenue as each obligation is satisfied. For most SaaS businesses, the core challenge is handling the mix of subscription access (over time), setup fees (point in time or over time), and variable elements like usage-based pricing. This page works through each scenario in full.
Section 1 — The IFRS 15 Five-Step Model Applied to SaaS
Each step in detail — what it means and how it applies to a typical SaaS contract
Step 1 — Identify the Contract
A contract under IFRS 15 is an agreement that creates enforceable rights and obligations. For SaaS, this is typically: a signed MSA (Master Service Agreement) plus an order form, an accepted online terms of service at the time of payment, or a click-through agreement at checkout. The contract must have commercial substance — there must be a genuine exchange of consideration. Free plans with no payment are not contracts under IFRS 15.
Important: IFRS 15 requires that it be probable the company will collect the consideration it is entitled to. If there are serious doubts about collectability, the contract does not qualify and no revenue is recognised until collection is probable.
| Contract Element | Examples in SaaS | Revenue Recognition Implication |
|---|---|---|
| Signed MSA + order form | Enterprise customers; annual contracts > €5,000 | Full IFRS 15 analysis; likely multi-element |
| Online checkout (click-through ToS) | SMB and self-serve customers; monthly plans | Simpler single-element; standard recognition |
| Free trial with auto-conversion | Customer signs up free, converts to paid | Contract starts at first payment; free period excluded |
| Verbal or email agreement | Informal arrangements with early customers | Risky — document as written contract as soon as possible |
| Letter of intent (not yet binding) | Pre-sales negotiations | Not a contract — no revenue until binding agreement |
Step 2 — Identify Performance Obligations
A performance obligation exists for each distinct good or service promised in the contract. A good or service is distinct if: (a) the customer can benefit from it on its own or together with other readily available resources, and (b) it is separately identifiable from other promises in the contract. In SaaS, most contracts contain multiple promises — the question is which of these are distinct enough to be separate performance obligations.
| Promise in SaaS Contract | Distinct? | Reasoning | Performance Obligation? |
|---|---|---|---|
| Access to the SaaS platform (subscription) | Yes | Customer can use it independently; core value | Yes — over time |
| Onboarding session (1 x video call) | Likely No | Customer cannot separately benefit; highly interdependent with subscription | Bundle with subscription — same recognition |
| Implementation / migration services | Yes — if substantial | Customer gets a configured system they could transfer to another provider | Yes — point in time at completion |
| Dedicated customer success manager | Maybe | If generic support: No. If specific deliverables agreed: Yes | Analyse case by case |
| Training materials (self-serve knowledge base) | No — usually | Included in subscription; not separately sold | Part of subscription obligation |
| Custom integrations / API development | Yes | Customer receives a distinct software component | Yes — point in time or over time per project timeline |
| Technical support SLA (premium tier) | Yes — if distinct tier sold | Separately priced; customer can benefit independently | Yes — over time across the support period |
Step 3 — Determine the Transaction Price
The transaction price is the amount of consideration the company expects to be entitled to in exchange for delivering the promised goods or services. For simple fixed-price SaaS, this is straightforward — the contract value is the transaction price. Complexity arises when the contract contains variable elements: discounts, refund rights, usage-based components, milestone payments, or consideration payable to the customer.
| Pricing Element | Transaction Price Impact | Recognition Approach |
|---|---|---|
| Fixed monthly/annual fee | Equal to contract value | Recognise ratably over contract term |
| Volume discount (e.g. 20% off above 100 seats) | Reduce transaction price by expected discount | Estimate discount expected and apply to full contract price |
| Refund right (no-questions-asked 30-day refund) | Constrain by probability of refund | Create refund liability; release if refund period expires |
| Usage-based overage (€10 per API call above limit) | Variable — must estimate | Constrain to cumulative amount not likely to reverse; update monthly |
| Noncash consideration (equity in exchange for SaaS) | Fair value of equity received | Record at fair value of equity at contract inception |
| Customer loyalty points / future discounts | Separate performance obligation | Allocate portion of price to future discount; recognise when redeemed |
Step 4 — Allocate the Transaction Price
When a contract has multiple performance obligations, the transaction price is allocated to each obligation in proportion to its standalone selling price (SSP). The SSP is the price at which the company would sell that obligation separately to a standalone customer. If the company sells each element independently, observable SSPs can be used. If not, SSP must be estimated.
Transaction Price Allocation — €12,000 Enterprise Contract (12-Month Subscription + Implementation)
| Performance Obligation | SSP (Standalone) | Allocation % | Allocated Amount | Recognition |
|---|---|---|---|---|
| SaaS subscription (12 months @ €800/month) | €9,600 | 73.8% | €8,856 | €738/month over 12 months |
| Implementation project (estimated 40 hrs @ €120/hr) | €4,800 | 26.2% | €3,144 | Recognised at implementation completion |
| Total contract price | €12,000 (discounted from €14,400) | 100% | €12,000 | — |
In this example, the customer received a €2,400 discount on the combined package vs standalone prices. IFRS 15 requires the discount to be allocated proportionally to both obligations — not entirely to the subscription or entirely to the implementation. The implementation is allocated €3,144 rather than its €4,800 SSP, reflecting its share of the combined discount. If the company recognised the full €4,800 implementation revenue at project completion, it would overstate revenue in the implementation period and understate it over the subscription term.
Step 5 — Recognise Revenue as Performance Obligations Are Satisfied
Revenue is recognised when (or as) each performance obligation is satisfied — when control transfers to the customer. The critical question is: is this obligation satisfied over time or at a point in time?
Satisfied continuously as the customer has access to the software. Recognised ratably (1/n per period) unless another method better reflects delivery.
If services are delivered over a project period and the customer receives value as work progresses, use percentage-of-completion method based on hours or milestones.
If the customer receives a distinct deliverable (a configured system, a completed migration), recognise at the point of delivery and acceptance.
A perpetual licence to use software as-it-stands, with no ongoing update obligation, is recognised at the point the licence is granted and the customer can use it.
Section 2 — Revenue Recognition Timing by Contract Type
Visual timelines showing when different SaaS contract components generate revenue
Monthly vs Annual vs Multi-Year — Recognition Timing
The timing of revenue recognition varies significantly across contract types. The visual below shows how each contract type generates P&L revenue across a 12-month period for a contract starting 1 January.
| Contract / Item | Jan | Feb | Mar | Apr | May | Jun | Jul | Aug | Sep | Oct | Nov | Dec |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Monthly sub (€100/month × 12) | €100 | €100 | €100 | €100 | €100 | €100 | €100 | €100 | €100 | €100 | €100 | €100 |
| Annual sub paid upfront (€1,200) | €100 | €100 | €100 | €100 | €100 | €100 | €100 | €100 | €100 | €100 | €100 | €100 |
| Setup fee at Jan delivery (€400) | €400 | |||||||||||
| Implementation (50% done Mar, 100% Jun) | €300 | €300 | ||||||||||
| 2-year contract (€600/year × 2) | €50 | €50 | €50 | €50 | €50 | €50 | €50 | €50 | €50 | €50 | €50 | €50 |
An interesting feature of the table above: a monthly subscriber and an annual subscriber paying the same amount per month generate identical P&L revenue each month. The only difference is that the annual subscriber’s cash was received upfront (creating a deferred revenue liability that releases monthly), while the monthly subscriber’s cash arrives in the same month as recognition. From a revenue recognition perspective, the two are identical. From a cash flow perspective, annual billing is significantly better — which is why SaaS companies typically offer a discount to encourage annual plans.
Multi-Element Contract — Full Recognition Schedule
When a contract contains multiple performance obligations allocated at different amounts with different timing, the recognition schedule becomes the central document for the engagement. The schedule below illustrates a €12,000 enterprise contract with both subscription and implementation components.
Multi-Element Contract — Revenue Recognition Schedule (12 Months)
Contract: Enterprise customer, €12,000 total
Performance Obligation 1: SaaS subscription
Allocated: €8,856 | Monthly recognition: €738 (months 1–12)
Performance Obligation 2: Implementation project
Allocated: €3,144 | Method: milestone completion
Milestone 1 (50% complete, end of month 2): €1,572 recognised in M2
Milestone 2 (100% complete, end of month 3): €1,572 recognised in M3
Month 1: Subscription €738 + Implementation €0 = €738
Month 2: Subscription €738 + Implementation M1 €1,572 = €2,310
Month 3: Subscription €738 + Implementation M2 €1,572 = €2,310
Month 4 onwards: Subscription €738 only
Months 4–12 (9 months × €738): €6,642
Total 12-month recognition: €738 + €2,310 + €2,310 + €6,642 = €12,000
* Equals total contract price — confirms schedule is complete
* Cash received on contract signing (month 1): €12,000
* Balance of cash that is deferred revenue at end of month 1:
€12,000 received − €738 recognised = €11,262 deferred
Section 3 — Setup Fees and Onboarding Revenue
The most commonly mis-recognised element — when setup fees are distinct and when they are not
The Central Question: Is the Setup Fee Distinct?
Setup and onboarding fees are one of the most judgment-intensive revenue recognition areas in SaaS. Whether they are recognised at completion or spread over the subscription term depends entirely on whether the setup constitutes a distinct performance obligation — meaning whether the customer could benefit from the setup independently, separate from the ongoing subscription.
| Setup Fee Type | Distinct? | Recognition Method | Journal Entry Timing |
|---|---|---|---|
| Simple account creation (automated) | No — inseparable from subscription | Spread over expected subscription life | Release to revenue monthly; not at activation |
| Manual data migration (customer’s data transferred) | Yes — customer has a configured system they control | At completion of migration and acceptance by customer | Recognise when customer confirms acceptance |
| Custom configuration with customer-specific rules | Usually Yes — complex build | At substantial completion of configuration | Recognise when feature-complete and delivered |
| Standard onboarding call (1 hour introduction) | No — routine setup support | Spread over subscription term | Bundle with subscription; do not separate |
| Technical integration build (API connections) | Yes — distinct deliverable | At go-live of integration | Recognise when integration is live and tested |
| Training programme (5 sessions, own team) | Yes if separately priced; No if included | At each session if separately priced; spread if included | Per-session recognition if distinct; otherwise with subscription |
Non-Distinct Setup Fee — Amortisation Example
Setup fee received: €500 (not distinct — bundled with subscription)
Monthly subscription: €99/month
Total contract consideration: €500 + (€99 × 12) = €1,688
Option A: Recognise setup fee at contract inception (INCORRECT under IFRS 15)
Month 1: €500 + €99 = €599 (overstates month 1 revenue)
Months 2–12: €99 each (understates ongoing revenue)
Option B: Spread over expected customer life (CORRECT under IFRS 15)
Historical data: average customer stays 24 months
Setup fee monthly amortisation: €500 ÷ 24 months = €20.83/month
Subscription monthly recognition: €99/month
Total monthly recognised: €99 + €20.83 = €119.83/month for 24 months
If customer churns after 12 months:
Remaining setup fee deferred: €500 − (12 × €20.83) = €250 released at cancellation
* The deferred portion is a liability until the subscription and expected life passes
* Update expected customer life estimate annually based on actual churn data
Section 4 — Variable Consideration and Usage-Based Pricing
How to estimate, constrain, and update variable revenue components
What Counts as Variable Consideration
Variable consideration is any element of the transaction price that is not fixed. In SaaS, the most common sources are: usage-based overages (customer pays more if usage exceeds a base amount), volume discounts on seats or transactions, performance bonuses tied to outcomes, refund rights, and penalties for service level failures. Each must be estimated and constrained under the variable consideration constraint.
| Variable Element | Example | Estimation Approach | Constraint Test |
|---|---|---|---|
| Usage overages | €0.05 per API call above 10,000/month | Expected value based on customer’s historical usage | Constrain to amount not highly probable to reverse — use conservative estimate for new customers |
| Volume discounts | 10% off if customer exceeds 50 seats | Most likely amount (will they exceed 50 seats this year?) | If highly probable customer will reach threshold, apply discount to whole contract; otherwise reassess |
| Refund rights | 30-day money-back guarantee | Expected value of refunds based on historical refund rate | Recognise net of expected refunds; release when refund period expires |
| Performance SLA credits | 5% rebate if uptime falls below 99.9% | Expected value based on historical uptime performance | Unlikely to reverse: include if uptime reliably high; exclude if genuinely uncertain |
| Early termination fees | Customer pays 3 months of remaining fees if cancels early | Most likely outcome (usually recognise on termination) | Recognise when cancellation confirmed and amount fixed |
Usage-Based Revenue — The Practical Approach
Pure usage-based pricing (like pay-per-API-call or per-minute pricing with no minimum) creates a specific recognition challenge: the consideration depends entirely on the customer’s future behaviour, which cannot be fully estimated at contract inception. IFRS 15 provides a practical expedient for this: when an entity has the right to bill for performance completed to date (usage invoiced monthly in arrears), it can recognise revenue equal to what it has the right to invoice — i.e., actual usage-based revenue each month.
Usage-Based Revenue Recognition — Monthly Actual Basis
Contract: Pay-per-use API platform, €0.05/call, billed monthly in arrears
January actual API calls: 48,000
January revenue recognised: 48,000 × €0.05 = €2,400
February actual API calls: 62,000
February revenue recognised: 62,000 × €0.05 = €3,100
* No estimation required — invoice equals delivery
* But: if contract has a minimum monthly fee (€500/month minimum):
Minimum fee is recognised regardless of actual usage
If usage billing exceeds minimum: recognise higher amount
January: max(€500, €2,400) = €2,400 recognised
Minimum fee acts as floor; usage billing is variable above it
Hybrid model (flat fee + overages):
Base subscription: €299/month (recognise €299 each month)
Included: 5,000 API calls/month
Overage: €0.05/call above 5,000
March actual calls: 8,200 = 3,200 overage calls
March overage revenue: 3,200 × €0.05 = €160
March total recognised: €299 + €160 = €459
Section 5 — Multi-Year Contracts and Significant Financing
When long-term contracts contain a financing component — and how to account for it
Multi-Year Contracts — Recognition Over the Full Term
Multi-year SaaS contracts (2-year, 3-year) are common at the enterprise tier and are often offered with a total price discount relative to purchasing individual years. Recognition is straightforward: the total contract price is allocated to each year (or to each performance obligation across years) and recognised ratably. The deferred revenue balance at any point represents the remaining unearned contract value.
| Contract Type | Recognition Pattern | Deferred Revenue Behaviour | Key Accounting Risk |
|---|---|---|---|
| Monthly rolling contract | Month by month — no deferral | No deferred revenue — cash = recognition | Churn creates immediate revenue loss; no smoothing |
| Annual contract, upfront payment | €1,200 ÷ 12 = €100/month | Balance starts at €1,200, reduces by €100/month, zero at year-end | If cancellations spike, deferred balance needs adjustment |
| 2-year contract, upfront payment | Total ÷ 24 months | Balance starts at 24 months’ value; reduces monthly | Long deferred revenue window; document expected customer life |
| 2-year contract, annual invoicing | Recognise as billed if allocated per year | Year 1 deferred: invoice 1 value; Year 2 invoiced in month 12 | Ensure Y2 invoice is not premature revenue recognition |
| Enterprise with annual true-up | Base + variable usage | Deferred for base; variable recognised monthly as usage occurs | Separate fixed and variable elements; apply constraint test |
The Significant Financing Component — When It Applies to SaaS
IFRS 15 requires adjustment for a significant financing component when there is a significant difference between the amount of promised consideration and the cash selling price of the goods or services. In SaaS, this arises if a company collects a multi-year contract payment significantly in advance and the time value of money is material.
A practical expedient in IFRS 15 allows companies to ignore the financing component if the period between when the customer pays and when the good or service is transferred is one year or less. Most SaaS contracts — even annual ones — fall within this one-year window, making the adjustment unnecessary. Multi-year upfront contracts may require analysis.
| Scenario | Financing Component? | Practical Action |
|---|---|---|
| Monthly subscription — payment and delivery same month | No | No adjustment needed |
| Annual subscription — payment at start, delivery over 12 months | No — one-year practical expedient applies | No adjustment needed; use expedient |
| 2-year subscription — full payment at start | Maybe — analyse if interest rate and amount are material | Compare NPV of 24-month delivery vs upfront cash; if material difference, adjust revenue and interest income |
| 3-year+ contract with full upfront payment | Likely yes at large contract values | IFRS 15.63 adjustment: revenue = cash price equivalent; imputed interest = separate interest income over term |
| Instalment plan slower than delivery (customer pays over 3 years for 1-year service) | Financing exists — seller is financing the customer | Revenue = total contract; interest expense (not income) over payment period |
Section 6 — Free Trials, Discounts, and Promotional Pricing
How to handle revenue recognition when the commercial price is not what it appears
Free Trial Periods
Free trials require careful handling: are they part of the contract or a separate pre-contract marketing activity? Under IFRS 15, if the trial is unconditional (the customer can leave after the trial with no obligation), the trial is a marketing activity — no contract exists during the trial period, and no revenue is recognised. The contract begins only when the customer agrees to pay.
If the trial is conditional — for example, the trial requires a credit card that will be charged unless the customer cancels — a contract exists from the start of the trial. The consideration is the probability-weighted expected payment (adjusted for expected cancellations). In practice, most SaaS companies use the probability that the customer converts to paid and recognise zero revenue during the trial period, with revenue beginning at the first payment.
| Trial Type | Contract During Trial? | Revenue During Trial | Revenue After Conversion |
|---|---|---|---|
| Free trial, no credit card required | No — no enforceable obligation | None | Begin recognition from first payment date |
| Free trial with credit card, auto-convert | Yes — conditional contract exists | Constrained to zero (conversion probability uncertain) | Recognise from start of paid period; revisit trial accounting if material |
| Freemium plan (permanent free tier) | Yes — terms are accepted | Zero (no consideration for free tier) | Premium plan revenue begins at upgrade; do not allocate any free-tier value |
| Trial with guaranteed refund option | Yes — but constrained by refund right | Constrain by refund probability; recognise when refund period expires | Full recognition after refund window closes |
Discounts and Promotional Pricing
When a company charges a discounted price — a launch promotion, a customer referral discount, an annual plan saving — the transaction price is the discounted amount. There is no separate revenue recognition for the ‘undiscounted’ value of the service. The discount is the commercial price agreed; the undiscounted price is not relevant to revenue recognition.
The complexity arises when a discount on one element is effectively a material right for a future purchase — for example, a SaaS company offering a 40% discount on a second year of subscription if the customer renews. This renewal option at a meaningful discount may be a separate performance obligation: the customer is effectively receiving an option to renew at a below-market price, and a portion of the year-one price must be allocated to this option and deferred until the option is exercised or lapses.
If your SaaS contract offers a renewal at a price that is meaningfully below the then-current market price (not just a standard loyalty discount), IFRS 15 requires you to assess whether this constitutes a material right — a separate performance obligation. The test: would the customer pay the original contract price specifically to get the right to renew at the discounted price? If yes, you must allocate a portion of the original transaction price to this option and recognise it only when the option is exercised or expires. For most early-stage SaaS with standard renewal pricing, this is not material. For enterprise contracts with significant locked-in renewal discounts, it requires analysis.
Section 7 — Journal Entries for Common SaaS Revenue Scenarios
The complete accounting entries for the scenarios most SaaS companies encounter
Scenario A — Monthly Subscription, Payment and Recognition in Same Month
Monthly Subscription — €199 Paid and Recognised
| Account | Debit (DR) | Credit (CR) |
|---|---|---|
| Cash / Stripe | €199.00 | |
| Revenue — Monthly Subscriptions | €159.85 | |
| VAT Payable — KMD (24% on €163.11) | €39.14 |
* Payment received and revenue recognised in the same month. No deferred revenue. VAT of 24% applied if customer is Estonian; reverse charge if EU B2B; no VAT if non-EU or UK.
Scenario B — Annual Subscription, Upfront Payment
Annual Subscription — €2,388 Paid on 1 January (Monthly rate €199)
| Account | Debit (DR) | Credit (CR) |
|---|---|---|
| Cash / Stripe | €2,388.00 | |
| Deferred Revenue — Annual Subs | €1,814.88 | |
| VAT Payable — KMD (24% — if Estonian client) | €573.12 |
* Cash received upfront. Revenue deferred in full. €1,814.88 ÷ 12 = €151.24 recognised each month as subscription service is delivered. VAT on full invoice amount collected immediately and remitted on January KMD.
Annual Sub — Monthly Revenue Release (each month Jan–Dec)
| Account | Debit (DR) | Credit (CR) |
|---|---|---|
| Deferred Revenue — Annual Subs | €163.05 | |
| Revenue — Annual Subscriptions | €163.05 |
* No cash movement — just deferred to recognised. Repeated 12 times. After month 12, deferred balance is zero.
Scenario C — Multi-Element: Subscription + Implementation
Contract Received — €12,000 (Subscription + Implementation)
| Account | Debit (DR) | Credit (CR) |
|---|---|---|
| Cash | €12,000.00 | |
| Deferred Revenue — Annual Subs (allocated €8,856) | €8,856.00 | |
| Deferred Revenue — Implementation (allocated €3,144) | €3,144.00 |
* Full cash received. Both performance obligations deferred. Note: VAT treatment depends on timing of supply — consult accountant for jurisdiction-specific VAT on multi-element contracts.
Implementation Milestone 1 — 50% Complete (Month 2)
| Account | Debit (DR) | Credit (CR) |
|---|---|---|
| Deferred Revenue — Implementation | €1,572.00 | |
| Revenue — Professional Services | €1,572.00 |
* 50% of implementation value recognised at milestone 1 completion and customer acceptance. Milestone 2 (remaining €1,572) recognised at full completion.
Monthly Subscription Release — Each Month
| Account | Debit (DR) | Credit (CR) |
|---|---|---|
| Deferred Revenue — Annual Subs | €738.00 | |
| Revenue — Annual Subscriptions | €738.00 |
* Subscription portion (€8,856 ÷ 12) released monthly. Simultaneous with milestone recognition in months 2 and 3.
Scenario D — Usage Overage (Hybrid Model)
Month with Usage Overage — Base €299 + €160 Overage
| Account | Debit (DR) | Credit (CR) |
|---|---|---|
| Cash / Stripe (base + overage invoice) | €459.00 | |
| Revenue — Monthly Subscriptions | €299.00 | |
| Revenue — Usage Add-ons | €160.00 |
* Base subscription recognised as agreed; overage recognised in month of usage (invoiced in arrears). Both are fixed and determinable at invoice date — no estimation required once usage is measured.