Audit Considerations for SaaS Companies

Why SaaS audits differ from traditional software or services audits

Traditional software companies sell a licence. The customer pays, receives the software, and the vendor recognises revenue when control transfers. SaaS companies sell access. The customer never owns the software. They pay for the right to use it, and the vendor retains control of the underlying asset throughout the contract.

This distinction drives nearly every accounting judgment on a SaaS engagement. Under IFRS 15.B58, a licence that provides a right of access to intellectual property (rather than a right to use it) is satisfied over time. Most SaaS subscriptions meet this definition because the customer’s ability to use the software depends on the vendor continuing to host and maintain it. If the vendor stops operating, the customer has nothing.

The consequence for the audit is that the default revenue recognition pattern for a SaaS subscription is straight-line over the contract term. That part is usually straightforward. Where SaaS audits get complicated is in the periphery: implementation fees, onboarding services, custom configurations, usage-based pricing tiers, and contract modifications mid-term. Each of these creates a judgment that the client may not have documented and that the prior auditor may not have challenged.

One more structural difference matters. SaaS companies tend to be younger, growing fast, and raising capital. Their finance functions are often understaffed relative to the complexity of their contracts. A €12M ARR company might have a two-person finance team that handles everything from billing to financial reporting. The internal control environment is weaker than what you’d find at a manufacturing or retail client of comparable size, and ISA 315.14 requires you to assess that weakness explicitly in your risk assessment.

Revenue recognition: the performance obligation question

IFRS 15.22 requires the entity to identify the performance obligations in a contract. For a pure SaaS subscription with no add-ons, there’s typically one obligation: providing access to the software over the contract period. Revenue recognised straight-line. Simple.

The complexity appears when the contract includes additional deliverables. Implementation services, data migration, training, custom API integrations, premium support tiers. Under IFRS 15.27, a promised good or service is distinct if the customer can benefit from it on its own (or with other readily available resources) and if it is separately identifiable from other promises in the contract.

Implementation services are where most SaaS clients get the analysis wrong. The question under IFRS 15.27(b) is whether the implementation is separately identifiable from the subscription. If the implementation significantly modifies or customises the software for that specific customer, it’s not distinct. The implementation and subscription form a single performance obligation, and the combined fee is recognised over the contract term. If the implementation is a standard onboarding that any third party could perform (connecting existing APIs, importing data, basic configuration), it’s distinct and the fee is recognised when the service is delivered.

Most SaaS companies fall somewhere in between. The implementation includes both standard setup and some customer-specific configuration. In that grey zone, you need to evaluate which element dominates. Document the specific activities included in the implementation scope for a sample of contracts, not at the product level. Two customers buying the same subscription tier may have very different implementation scopes.

Variable consideration adds another layer. Many SaaS contracts include usage-based components (per-user pricing above a threshold, API call volumes, storage overages). IFRS 15.50 requires the entity to estimate variable consideration and include it in the transaction price only to the extent that it is highly probable that a significant revenue reversal will not occur. Most SaaS clients include the variable component in revenue when invoiced rather than when estimated. For material contracts, test whether the client has assessed the constraint under IFRS 15.56 and documented their conclusion.

Contract costs under IFRS 15.91–94 deserve attention too. SaaS companies often pay sales commissions that are directly attributable to obtaining a contract. IFRS 15.91 requires capitalisation of incremental costs of obtaining a contract if the entity expects to recover those costs. The amortisation period should match the period of benefit, which for SaaS typically extends beyond the initial contract term if renewal rates are high. Many SaaS clients expense commissions immediately or amortise them only over the initial contract period, both of which can be incorrect.

Key metrics and management representations

SaaS companies report metrics that don’t appear in traditional financial statements: annual recurring revenue, monthly recurring revenue, net revenue retention, customer lifetime value, churn rate. These metrics aren’t defined by IFRS and aren’t audited in the financial statements. But they influence the audit indirectly.

ARR is the metric investors care about most, and clients have strong incentives to present it favourably. If the client’s ARR calculation includes contracts that have been signed but not yet activated, or includes multi-year contracts at their full annual value even when usage-based components haven’t materialised, the gap between reported ARR and IFRS 15 revenue creates a risk. The client’s management team may resist accounting treatments that reduce revenue (like deferring implementation fees or constraining variable consideration) because of the downstream impact on ARR.

This pressure doesn’t change the accounting. But it changes the risk assessment under ISA 240.A1 (fraud risk factors related to management incentives). A SaaS company preparing for a fundraise has a specific, identifiable pressure to recognise revenue earlier rather than later. Document this incentive in your fraud risk assessment and design procedures that respond to it. Testing cut-off for contracts signed near period end is the minimum. Testing whether the client’s ARR reconciles to IFRS 15 revenue (and explaining the differences) is a useful additional procedure that surfaces any systematic overstatement.

ISA 580.10 requires written representations from management on matters material to the financial statements. For SaaS engagements, the representation letter should specifically cover: completeness of contract modifications disclosed, accuracy of the standalone selling price allocation used for bundled arrangements, the basis for determining the capitalisation start point for development costs, and whether any side agreements or verbal commitments exist that modify the written contract terms. Side letters (informal extensions, verbal discounts, guaranteed renewal terms) are common in SaaS sales and can change the accounting for a contract entirely.

Contract modifications and upgrades

SaaS contracts get modified frequently. A customer on a 50-user plan upgrades to 100 users midway through the year. Someone else adds a new module. Another negotiates a discount at renewal.

IFRS 15.18 requires the entity to account for a contract modification as a separate contract if two conditions are met: the modification adds distinct goods or services, and the price of those additional services reflects their standalone selling price. A customer adding 50 users at the standard per-user rate is a separate contract. Revenue on the additional users is recognised from the modification date.

If the modification doesn’t meet both conditions, IFRS 15.21 requires the entity to account for it as a termination of the old contract and creation of a new one (or as part of the existing contract if the remaining services form a single performance obligation). In practice, this means reallocating the transaction price and adjusting the revenue recognition pattern from the modification date.

Most SaaS companies treat all mid-contract changes as simple add-ons, recognising the incremental revenue from the change date without performing the IFRS 15.18 two-condition test. For material modifications, test whether the client evaluated both conditions and documented the conclusion.

Capitalised development costs under IAS 38

SaaS companies spend heavily on product development. A €12M ARR company might spend €2M–€3M annually on engineering. The question for the auditor is how much of that spend meets the capitalisation criteria under IAS 38.57.

IAS 38.57 sets out six criteria that must all be met for development costs to be recognised as an intangible asset: technical feasibility of completing the asset, intention to complete it, ability to use or sell it, demonstration that it will generate probable future economic benefits, availability of adequate resources to complete it, and ability to measure the expenditure reliably during development. All six must be satisfied simultaneously. If any one fails, the entire spend for that project is expensed.

In practice, three of these criteria cause most of the audit issues at SaaS companies.

First, technical feasibility. SaaS companies develop features incrementally using agile methodology. A feature moves from concept to backlog to sprint to release in two to six weeks. The point at which “technical feasibility of completing the asset” is established is genuinely ambiguous when development happens in rapid iterations. Some firms argue technical feasibility exists when the feature enters a sprint (the team has committed to building it). Others argue it exists only when the feature passes QA. The client must define the point and apply it consistently. Document their policy and test whether it’s actually followed.

Second, probable future economic benefits. A new feature added to an existing SaaS platform doesn’t generate revenue independently. It contributes to the overall subscription value. IFRS 15 doesn’t allocate subscription revenue to individual features. The client needs to demonstrate that the feature either attracts new customers, retains existing ones, or enables a price increase. Generic assertions like “this feature improves the product” are insufficient under IAS 38.57(d).

Third, reliable measurement of expenditure. SaaS engineering teams don’t naturally track time by project in the way a construction company tracks costs by job. Developers work on multiple features in the same sprint, rotate between bug fixes and new development, and participate in activities (code review, standups, architecture planning) that don’t map neatly to a single capitalised asset. If the client’s time tracking system can’t reliably separate capitalised development time from maintenance and operational time, criterion (f) of IAS 38.57 fails and the costs must be expensed.

Worked example: auditing CloudDijk B.V.

Scenario: CloudDijk B.V. is a Rotterdam-based SaaS company providing logistics management software. Annual recurring revenue: €14.2M. 380 enterprise clients on annual contracts. Average contract value: €37K. CloudDijk charges a one-time implementation fee (average €8K per client) and recognises it at contract signing. Development costs of €2.8M were capitalised in the current year. Total capitalised development on the balance sheet: €6.1M.

Step 1: Evaluate implementation fee recognition

Select a sample of 20 new contracts from the year. For each, obtain the implementation scope document. Of the 20 sampled, 14 involve standard onboarding (data import, basic configuration, user training) that a third-party implementer could perform. Six involve custom workflow builds specific to the client’s logistics operations.

Step 2: Test subscription revenue recognition

Select 25 contracts covering €3.1M of the €14.2M ARR. For each, verify the contract start date, end date, total contract value, and monthly revenue recognised. Recalculate straight-line recognition and compare to the client’s revenue schedule. Test for cut-off: verify that contracts signed in the last week of the year have revenue recognised only from the service activation date, not the contract signature date.

Step 3: Evaluate capitalised development costs

Obtain CloudDijk’s capitalisation policy. The policy states that development costs are capitalised from the point a feature enters the sprint backlog. Review the time tracking system: CloudDijk uses Jira for project management but does not have a separate time tracking integration. Developers self-report hours by project category in a monthly spreadsheet.

Step 4: Review amortisation of capitalised development

CloudDijk amortises capitalised development costs over five years. Test whether five years reflects the useful life of features in a rapidly evolving SaaS product. Review the feature release history: how many features released five years ago are still in active use? If significant features have been retired or rebuilt within two to four years, the amortisation period may overstate the asset.

Practical checklist

1. Classify implementation services per contract. Obtain a sample of new contracts and read the implementation scope for each. Classify each implementation as distinct (standard onboarding) or not distinct (custom build) under IFRS 15.27, and verify the client’s revenue recognition matches the classification.
2. Test variable consideration. For contracts with usage-based tiers, overage charges, test whether the client has applied the constraint under IFRS 15.56 or is recognising variable revenue only when invoiced.
3. Test contract modifications. Test a sample of mid-year contract modifications against the two conditions in IFRS 15.18. If the client treats all modifications as simple add-ons without performing the test, document the finding.
4. Evaluate capitalised development costs. Assess each of the six IAS 38.57 criteria independently. Pay particular attention to technical feasibility (when does it start under agile methodology), probable future economic benefits (evidence beyond “it improves the product”), and reliable measurement (can the time tracking system separate development from maintenance).
5. Test the amortisation period. Compare the amortisation period for capitalised development against observed feature lifecycles. If features are being retired or rebuilt faster than the amortisation period assumes, calculate the impact.
6. Review sales commission capitalisation. Verify whether sales commission costs meet the capitalisation criteria under IFRS 15.91 and whether the amortisation period reflects the full period of benefit (including expected renewals), not just the initial contract term.

Common mistakes

• Recognising all implementation fees at contract signing without evaluating whether the implementation is distinct under IFRS 15.27. The ESMA 2023 enforcement priorities report flagged SaaS revenue recognition (specifically the identification of performance obligations for bundled deliverables) as an area of continued focus.
• Capitalising development costs based on a blanket policy (“all sprint work is capitalised”) without testing whether each project individually meets all six criteria of IAS 38.57. The FRC’s 2022–23 inspection cycle identified capitalised development costs as a recurring area of concern, particularly where time tracking evidence was insufficient.

Related content

Frequently asked questions

Further reading and source references

• IFRS 15, Revenue from Contracts with Customers: paragraphs 22–30 on performance obligations, 50–54 on variable consideration, 91–94 on contract costs.
• IAS 38, Intangible Assets: paragraph 57 on the six capitalisation criteria for development costs.
• ISA 315 (Revised 2019), Identifying and Assessing Risks of Material Misstatement: paragraph 14 on understanding internal controls.
• ISA 240, The Auditor’s Responsibilities Relating to Fraud: paragraph A1 on fraud risk factors including management incentives.
• ESMA 2023 Enforcement Priorities: SaaS revenue recognition and performance obligation identification.
• IFRS Interpretations Committee (April 2021): agenda decision on configuration and customisation costs in SaaS arrangements.