Accountants for
saas startups

The default SaaS recognition pattern under IFRS 15 is that subscription revenue is recognised rateably over the service period, which sounds simple until it meets reality. An annual contract invoiced upfront for £12,000 is not £12,000 of revenue in month one: it is £1,000 per month of recognised revenue and an opening £11,000 deferred revenue balance that unwinds over the twelve months. Cash receipts and recognised revenue move in different directions, and the gap (deferred revenue on the balance sheet) is often the single largest line item for a growing SaaS startup. Founders who track cash only typically overstate revenue in months with a lot of annual billing and understate it in months with a lot of renewals. Monthly management accounts need to show MRR, ARR, bookings, and recognised revenue as four distinct metrics with explicit reconciliation between them.

Usage-based pricing adds a layer. Variable consideration under IFRS 15 needs to be estimated and constrained: if a customer’s usage-based bill has meaningful variability, the estimate goes into revenue with a constraint for the probability of significant reversal. In practice most UK SaaS startups use the expected value method on a rolling basis with a monthly true-up. Credits, free trials, and month-zero promotions are treated as variable consideration that reduces the transaction price. Multi-year deals with annual price escalators need the escalator modelled into the straight-line recognition unless the increase reflects a material change in the services provided.

Two separate capitalisation questions sit alongside revenue recognition and catch SaaS founders out. First, costs to obtain a contract (sales commissions) are capitalised and amortised over the expected customer life under IFRS 15 where they are incremental and recoverable. For a SaaS startup with meaningful ACV and a multi-year expected customer life, this shifts a substantial cost from immediate P&L recognition to a capitalised asset amortised over three to five years. Second, costs to fulfil a contract (customer onboarding, implementation, setup) are capitalised where they relate to a specific contract, generate or enhance resources used to satisfy future performance obligations, and are expected to be recovered.

Separately, internally generated intangible assets (platform development capitalisation under IAS 38 or FRS 102 section 18) is a policy choice with material P&L implications. Capitalising platform development shifts engineering cost off the income statement and onto the balance sheet as an intangible asset, amortised over a useful economic life (typically three to five years). For a SaaS startup with significant engineering spend and a desire to report a smaller loss to investors, this is attractive but needs to be consistent with both IAS 38 criteria (technical feasibility, intention to complete, ability to use or sell, probable economic benefit, reliable cost measurement) and with R&D credit claim methodology. Cost that is capitalised as an intangible asset still qualifies for R&D relief if it meets the qualifying criteria, but the claim mechanics differ from expensed R&D. Accountants in our network set the policy at the first accounting period, document the methodology, and apply it consistently to avoid restatements at due diligence.

Under the merged scheme, R&D tax credits return twenty per cent of qualifying expenditure, rising to twenty-seven per cent for R&D-intensive SMEs where qualifying R&D exceeds thirty per cent of total expenditure. For a typical UK SaaS startup, the qualifying work tends to concentrate in specific areas: novel algorithm design, machine learning model development where existing approaches are insufficient, significant data pipeline or streaming architecture work, scalability and performance engineering that resolves genuine technical uncertainty, and infrastructure work that goes beyond routine cloud configuration.

What does not qualify is the routine majority of SaaS engineering: CRUD feature development, standard REST or GraphQL API wrapping of existing functionality, third-party integration work, UI implementation against an existing design system, routine database schema changes, standard DevOps and deployment configuration, and content or copy work. HMRC’s enquiry activity since August 2023 has focused on claims that extrapolate from a small core of qualifying work to a large percentage of total engineering spend without the underlying evidence. The documentation that stands up to review is contemporaneous: commit logs or project tickets that identify the specific scientific or technological uncertainty, time allocation records that separate qualifying and non-qualifying work at the individual engineer level, cloud and software cost allocation that identifies the compute and tools directly consumed by qualifying work, and clear separation of externally provided workers and subcontractors by the nature of the work they did.

The under-claimed cost categories for SaaS specifically are cloud compute and data (where genuinely consumed by qualifying development and testing rather than production), externally provided workers (specialist contractors brought in for specific R&D work, at sixty-five per cent for SMEs), and subcontractors (similarly at sixty-five per cent for SMEs, where the work addresses scientific or technological uncertainty). Software licences directly used in R&D (for example, specialist ML tooling, scientific computing platforms, internal observability for R&D environments) also qualify and are often missed.

SaaS valuations for SEIS and EIS rounds are almost always built on ARR multiples in the UK market. The valuation evidence HMRC expects for advance assurance and the investor commitment in the term sheet need to be consistent: if the term sheet is priced at a ten times ARR pre-money and the advance assurance submission implies a very different valuation basis, the application slows down. The work at advance assurance is to document the ARR figure, the growth trajectory, the retention and expansion assumptions, the comparable transactions, and the basis for the specific multiple, in a form that matches how the same numbers appear in the pitch deck and data room.

For R&D-intensive SaaS, the interaction with the enhanced credit rate matters over time. A very early-stage SaaS startup with a large engineering team and small revenue will often qualify for the twenty-seven per cent rate at first claim. As ARR grows, the R&D-intensive threshold (qualifying R&D greater than thirty per cent of total expenditure) breaks, and the rate drops to twenty per cent. Accountants in our network model this transition in the 18-month forecast so the cash flow impact of the rate change is not a surprise in the first year post-Series A.

The standard 13-week rolling cash flow model needs specific adjustments for SaaS. Annual prepayment timing creates large month-to-month cash swings that have no relationship to MRR, so the cash forecast and the MRR-led trading forecast need to be explicitly reconciled rather than treated as the same thing. Customer acquisition cost payback periods of six to twenty-four months mean that aggressive new customer acquisition consumes cash in the acquisition month and produces cash a year or more later, which a simple gross margin forecast does not capture. Churn and contraction need to be modelled at the cohort level, not as a blended monthly percentage, because the actual cash impact depends heavily on when cohorts expire and how expansion revenue concentrates.

R&D credit receipt timing matters materially for loss-making SaaS startups where the annual credit is a large single inflow. The credit payment from HMRC typically arrives four to eight weeks after the claim is submitted with the Corporation Tax return, but enquiries extend that to three to six months. For a SaaS startup with fifteen months of runway where two months of runway are the R&D credit, the forecast needs to model the credit as a probability-weighted inflow with a contingency for delay. Accountants in our network build the two-scenario version at first forecast: optimistic with credit received on target date, conservative with credit delayed by three months.

UK SaaS startups with meaningful US customer revenue or US-based senior hiring frequently consider a US flip at Series A or Series B: restructuring so a Delaware C-Corp owns the UK subsidiary. The flip ends further SEIS and EIS eligibility at the UK level (no further qualifying share issues to UK investors) and creates a transfer pricing obligation between the UK and US entities for the value of the IP and services flowing across the border. For a SaaS startup, the IP valuation at the point of flip is commercially sensitive and tax-material: the R&D work continues in the UK subsidiary, the customer contracts and revenue sit in the US parent, and the transfer pricing arrangement needs to reflect the economic reality of where value is created.

The timing decision is rarely clean. Flipping earlier preserves more optionality on US-led rounds but forecloses further UK SEIS/EIS. Flipping later captures more UK relief but complicates the Series B process with US investors. Accountants in our network who work with UK SaaS startups model the full tax impact of both timings (relief captured, ongoing transfer pricing cost, Corporation Tax rate arbitrage, US tax consequences for UK founders) before the decision goes to the board.

EMI option schemes are standard at SaaS Series A and beyond, but the design and administration has specific SaaS considerations. The option pool size (typically ten to twenty per cent of the post-money fully diluted cap table) needs to accommodate both engineering retention and the go-to-market hires that ARR growth requires, with an explicit plan for pool top-ups before Series B. EMI valuations need to be defensible at HMRC-agreed methodology rather than self-assessed, because a SaaS company with rapidly growing ARR will see the option exercise price need frequent update if the valuation methodology is not agreed in advance.

The £250,000 per-employee unexercised option limit and the £3 million scheme-wide cap apply through the life of the scheme, and both are easier to breach at a fast-growing SaaS startup than founders anticipate. For a senior engineer hired early with a large grant, subsequent grants or top-ups can push past the individual limit. The scheme administration and option agreements need to be set up with the growth trajectory in view, not just the founding team’s equity.