Software companies can scale quickly.

The accounting often does not.

A business may move from a handful of customers to hundreds of subscriptions, employ developers across several countries, collect payments through Stripe, invest heavily in product development and sell to customers around the world.

Yet the finance system may still be based on:

• basic bookkeeping;
• one revenue account;
• annual accounts prepared months after year-end;
• spreadsheets for subscriptions;
• no clear treatment of development costs; and
• limited visibility over recurring revenue, margins or cash runway.

That creates a problem.

The statutory accounts may technically be completed, but management still cannot clearly answer:

• How much recurring revenue are we actually generating?
• What income belongs to future periods?
• Should software development costs be expensed or capitalised?
• What does it really cost to deliver our platform?
• Which customers or products generate the strongest margins?
• What VAT treatment applies to overseas software sales?
• How much cash runway do we have?
• Are our numbers ready for an investor, lender or buyer?

Accounting for software companies therefore needs to do considerably more than record transactions and submit year-end returns.

It needs to reflect how the software business actually operates.

Why Accounting for Software Companies Is Different

Traditional accounting systems are often designed around relatively straightforward transactions:

• sell something;
• raise an invoice;
• receive payment;
• record revenue.

Software businesses can be very different.

Revenue may come from:

• monthly SaaS subscriptions;
• annual subscriptions paid upfront;
• perpetual software licences;
• term licences;
• implementation projects;
• onboarding fees;
• usage-based billing;
• support and maintenance;
• API access;
• reseller arrangements;
• enterprise contracts; and
• professional services.

At the same time, significant expenditure may relate to:

• software engineers;
• product teams;
• cloud infrastructure;
• external developers;
• data;
• APIs;
• cybersecurity;
• research and development;
• customer acquisition; and
• intellectual property.

Each can have a different accounting, tax or management-reporting treatment.

Good accounting therefore starts by understanding the commercial model rather than simply importing bank transactions into Xero.

1. Revenue Recognition for Software and SaaS Companies

Revenue is one of the most important areas of accounting for software businesses.

The amount invoiced or collected is not always the amount that should appear as revenue immediately.

Example: annual SaaS subscription

A customer pays £24,000 on 1 January for 12 months’ access to a software platform.

Cash received: £24,000

But if the service is provided evenly throughout the year, the accounting may recognise approximately: £2,000 per month

with the balance initially carried forward until the relevant service is provided.

This distinction affects:

• reported turnover;
• monthly profitability;
• deferred income or contract liabilities;
• management accounts;
• tax calculations; and
• investor reporting.

The FRS 102 changes from 2026

For accounting periods beginning on or after 1 January 2026, the revised FRS 102 Section 23, Revenue from Contracts with Customers, applies to many UK companies using FRS 102.

The revised model focuses on the contractual promises made to customers and when those promises are satisfied.

For software companies, this can be particularly important where contracts contain several elements, such as:

• software access;
• implementation;
• data migration;
• training;
• customisation;
• support; and
• maintenance.

The accounting treatment should therefore follow the substance of the customer contract rather than automatically recognising everything when an invoice is raised.

AccounTax Zone Insight
Do not build your revenue policy around your invoicing software.
Stripe, GoCardless or your CRM may tell you what was billed and collected, but they do not determine when revenue has been earned.
For a growing software company, the contract, billing system and accounting records should be reviewed together. Otherwise MRR, statutory revenue and cash collections can easily become three different numbers without management understanding why.

2. SaaS Revenue, MRR and ARR Are Not the Same Thing

This is an important distinction.

Accounting revenue is governed by accounting principles.

MRR and ARR are management metrics.

Cash collections show liquidity.

Although related, they are not interchangeable.

For example, a customer paying £12,000 annually may create:

• £12,000 of cash today;
• approximately £1,000 of accounting revenue each month; and
• £12,000 of ARR, depending on the company’s KPI methodology.

A software company should therefore maintain clear reconciliations between:

Billing → cash → accounting revenue → recurring revenue metrics

Without this reconciliation, management reporting can become unreliable as transaction volumes increase.

3. Deferred Income and Contract Balances

Software companies frequently receive money before completing the related service.

This can create a liability because the company still owes something to the customer.

Historically, this has commonly been described as deferred income.

Under the revised FRS 102 revenue model, businesses may also need to consider contract assets and contract liabilities depending on the circumstances.

These balances should not simply be calculated once at year-end.

For subscription businesses, they should ideally be reviewed as part of the monthly close.

A proper schedule should identify:

• customer;
• contract;
• subscription start date;
• subscription end date;
• total contract value;
• amount invoiced;
• cash received;
• revenue recognised; and
• remaining balance.

This gives management a much clearer picture of future revenue obligations.

4. Accounting for Software Development Costs

One of the most judgement-heavy areas for software companies is deciding what to do with development expenditure.

A company may spend significant amounts on:

• developers;
• engineers;
• contractors;
• product managers;
• testing;
• software tools;
• APIs;
• cloud computing; and
• technical infrastructure.

But not every development-related cost should automatically become an asset.

Research and development are different

Under FRS 102, research expenditure is generally recognised as an expense.

Development expenditure requires a more detailed assessment.

Where the company adopts an accounting policy of capitalising qualifying development expenditure, conditions must be satisfied before costs can be recognised as an intangible asset.

The assessment may consider matters including:

• technical feasibility;
• intention to complete the project;
• ability to use or sell the software;
• expected future economic benefits;
• availability of sufficient technical and financial resources; and
• ability to measure the development expenditure reliably.

Current ICAEW guidance also confirms that similar principles apply to software development expenditure under FRS 102.

Capitalisation is not simply about making profit look better

Capitalising development costs moves qualifying expenditure from the immediate profit and loss account onto the balance sheet.

That can increase reported profit in the initial period.

But it also creates:

• an intangible asset;
• future amortisation charges;
• potential impairment considerations; and
• additional accounting judgements.

The accounting policy therefore needs to reflect the economics of the development activity, not a desired profit figure.

AccounTax Zone Insight
Define the point at which development starts before year-end.
Trying to reconstruct a year's development activity after the accounts have closed is difficult.
For larger software projects, we recommend documenting:
- when research ended;
- when development criteria were considered satisfied;
- which employees worked on the project;
- how their time was allocated; and
- which external costs relate directly to development.
This creates a much stronger audit trail for both accounting and tax purposes.

5. Amortisation and Impairment of Capitalised Software

Capitalising development expenditure is not the end of the accounting process.

Once the software asset is available for use, management must consider its useful economic life and amortisation.

FRS 102 requires intangible assets to be amortised systematically over their useful lives. Where the expected consumption pattern cannot be determined reliably, a straight-line basis is generally used.

This requires particular judgement in technology businesses because software can become obsolete quickly.

Factors may include:

• expected product life;
• speed of technological change;
• competitive developments;
• replacement plans;
• customer demand;
• contractual rights; and
• planned platform migrations.

Management should also consider whether events indicate that the carrying value of an asset may no longer be recoverable.

For example:

A company capitalises significant expenditure on a software product but later decides to abandon the product after failing to achieve commercial traction.

Continuing to carry the full asset value without reconsidering recoverability could give a misleading picture of the company’s financial position.

6. Accounting for Cloud Hosting, APIs and Technology Infrastructure

Modern software businesses can incur substantial third-party technology costs.

Examples include:

• AWS;
• Microsoft Azure;
• Google Cloud;
• database services;
• AI model/API usage;
• data providers;
• cybersecurity platforms;
• monitoring tools;
• messaging services; and
• payment infrastructure.

The accounting question is not simply which supplier issued the invoice.

Management needs to understand what the cost relates to.

For management reporting, technology costs may need to be divided between:

Direct cost of delivering the service

For example:

cloud resources directly linked to customer usage.

Product and development expenditure

For example:

development environments or technical tools used by engineers.

General overhead

For example:

internal productivity software used by the wider team.

Getting these classifications right is important because they affect gross margin and product economics.

7. Calculating Gross Margin Properly

Software companies often focus heavily on gross margin.

But the percentage is only meaningful if the underlying cost classification is consistent.

Depending on the business model, direct costs might include:

• cloud hosting attributable to customers;
• third-party licences required to provide the service;
• payment processing;
• customer-specific infrastructure;
• certain support costs; and
• third-party data consumed in delivering the product.

Other expenditure may properly belong in:

• development;
• sales and marketing; or
• general administration.

The policy should be clearly defined and applied consistently.

Otherwise management can appear to improve gross margin simply by moving costs between categories.

AccounTax Zone Insight
A KPI is only useful when the accounting behind it is stable.
If hosting costs are included in cost of sales one month and overheads the next, gross-margin trends become meaningless.
For software companies preparing for investment or sale, consistency matters almost as much as the headline percentage because an investor will want to understand how the metric was constructed.

8. R&D Tax Relief and Software Accounting

Software companies are among the businesses most likely to consider R&D tax relief.

However: accounting treatment and R&D tax eligibility are not the same test.

Capitalising development expenditure in the accounts does not automatically mean that it qualifies for R&D tax relief.

Equally, accounting capitalisation does not necessarily prevent qualifying revenue expenditure from being considered under the R&D rules.

HMRC specifically notes that accounting treatment is not conclusive in determining whether expenditure is revenue or capital for tax purposes.

Under the reformed R&D rules, qualifying revenue expenditure can include software used in qualifying R&D activity, subject to the relevant conditions and appropriate apportionment.

For software businesses, records should therefore be capable of supporting both: the financial reporting treatment and the tax relief position without assuming that one automatically determines the other.

9. VAT Accounting for Software Companies

VAT can become complicated quickly because software companies often sell internationally from an early stage.

Transactions may include:

• UK B2B subscriptions;
• UK consumer subscriptions;
• EU business customers;
• EU consumers;
• customers elsewhere in the world;
• software licences;
• electronically supplied services;
• consultancy; and
• bundled services.

HMRC includes supplies of software and software updates within its examples of electronically supplied services. For cross-border consumer supplies, the customer’s location can affect where VAT is due.

Software businesses therefore need records that distinguish:

• customer country;
• B2B or B2C status;
• type of supply;
• VAT rate;
• VAT evidence; and
• platform or marketplace involvement.

Businesses should avoid applying one blanket VAT treatment to every overseas customer.

Your detailed Cross-Border VAT for UK Tech & SaaS Businesses cluster can then handle this topic in greater depth.

10. Payment Platforms Must Reconcile with the Accounts

Stripe may show £100,000 of payments.

That does not mean £100,000 should simply be posted to sales.

The difference may include:

• VAT;
• refunds;
• processing charges;
• failed payments;
• chargebacks;
• foreign exchange;
• payouts still in transit;
• credits;
• annual subscriptions relating to future periods; and
• payments collected on behalf of another party.

The accounting records should therefore reconcile:

For high-volume software businesses, relying on manual month-end journal entries can become increasingly risky.

11. Foreign Currency Accounting

Software companies frequently invoice customers and pay suppliers in different currencies.

Common currencies may include:

• GBP;
• USD;
• EUR; and
• other international currencies.

This creates accounting requirements around:

• transaction exchange rates;
• outstanding receivables;
• supplier balances;
• bank accounts;
• foreign exchange gains; and
• foreign exchange losses.

Management reporting should also distinguish genuine operational growth from exchange-rate movements.

For example:

A rise in sterling revenue may partly reflect currency movements rather than increased customer activity.

12. Payroll, Developers and Contractors

People costs are often the largest expenditure category in a software company.

They may include:

• founders;
• UK developers;
• sales staff;
• product teams;
• overseas employees;
• consultants;
• freelancers; and
• personal service companies.

The accounting system should make it possible to separate staff expenditure by function.

For example:

• Development: Engineering and product.
• Sales and marketing: Sales team, advertising and customer acquisition.
• Customer success: Support and retention.
• Administration: Finance, legal and general management.

This makes profitability and SaaS metrics considerably more meaningful.

Where contractors are used, employment-status and IR35 considerations may also arise depending on the engagement.

13. Management Accounts for Software Companies

Annual accounts tell you what happened historically.

Growing software companies need more frequent information.

Monthly management accounts should normally bring together:

Profit and loss

Showing:

• recurring revenue;
• services income;
• cost of sales;
• gross margin;
• payroll;
• development expenditure;
• marketing;
• overheads; and
• operating profit or loss.

Balance sheet

Including:

• cash;
• debtors;
• deferred income or contract balances;
• capitalised development costs;
• creditors;
• tax liabilities; and
• funding balances.

Cash flow

Showing:

• cash generated or consumed;
• burn;
• runway; and
• upcoming funding requirements.

SaaS and commercial KPIs

Depending on the business:

• MRR;
• ARR;
• new ARR;
• churn;
• net revenue retention;
• average revenue per customer;
• CAC;
• LTV;
• gross margin;
• burn rate; and
• runway.

The purpose is not to create the largest possible dashboard.

It is to give directors information they can actually use.

14. A Better Chart of Accounts for Software Companies

A growing software company should not operate with a single account called “Sales” and another called “Software Costs”.

A more useful structure might include:

Revenue

• SaaS subscriptions
• Software licences
• Implementation
• Professional services
• Support
• Other recurring income

Direct costs

• Cloud hosting
• Customer-specific licences
• Payment processing
• Third-party data
• Direct support costs

Product and development

• Developer salaries
• External developers
• Development software
• Testing
• Product management

Sales and marketing

• Sales salaries
• Commissions
• Advertising
• Events
• CRM systems

General and administrative

• Finance
• Legal
• Insurance
• Office
• General software
• Director costs

The precise structure should follow the way management runs the business.

15. Monthly Accounting Checklist for a Software Company

16. Common Accounting Problems We See in Software Businesses

1. Everything received through Stripe is treated as revenue: This can distort income, VAT and deferred balances.
2. Annual subscriptions are recognised immediately: This may overstate current-period revenue where future services remain to be delivered.
3. Development expenditure has no documented policy: Costs may be treated inconsistently from one year to another.
4. R&D accounting and R&D tax relief are treated as the same exercise: They are connected but require different technical assessments.
5. No reconciliation between MRR and statutory revenue: Management and statutory reporting gradually drift apart.
6. Hosting costs move between categories: Gross margin becomes unreliable.
7. Overseas VAT is reviewed too late: International growth can create liabilities before the company realises registrations or reporting may be required.
8. Accounting is only updated quarterly or annually: Directors make current decisions using historic information.
9. Investor reporting is built manually at the last minute: Due diligence then exposes inconsistencies that should have been resolved much earlier.

17. AccounTax Zone Insight: Build the Finance Function Before You Need Due Diligence

The worst time to discover weaknesses in software accounting is after receiving an investor term sheet or acquisition enquiry.

At that point, management may suddenly need to explain:

• why ARR does not reconcile with revenue;
• how deferred income was calculated;
• what was included in gross margin;
• why development costs were capitalised;
• how R&D claims were prepared;
• whether international VAT is correct; and
• why historic management accounts changed.

A cleaner approach is to build these reconciliations while the company is scaling.

That gives management better information today and makes future funding or exit processes significantly easier.

How AccounTax Zone Supports Software Companies

At AccounTax Zone, we support software, SaaS and technology businesses with finance systems designed around the way they actually operate.

Our support can include:

• bookkeeping and month-end close;
• management accounts;
• SaaS revenue recognition;
• deferred revenue and contract balance schedules;
• accounting for software development expenditure;
• R&D tax relief;
• VAT and international digital sales;
• payroll and contractor accounting;
• cash flow forecasting;
• MRR and ARR reporting;
• KPI dashboards;
• budgets and scenario modelling;
• investor reporting;
• Virtual Finance Office support; and
• Virtual CFO support.

The aim is not simply to keep the company compliant.

It is to make the financial information reliable enough to support decisions.

Accounting for Software Companies: A Practical Review Framework

Build an Accounting System That Can Scale with Your Software Business

Software businesses can change quickly.

Your finance function needs to keep up.

If you are dealing with:

• unreliable MRR or ARR;
• unclear revenue recognition;
• questions over development costs;
• complicated VAT;
• inconsistent management accounts;
• weak cash-flow visibility; or
• investor reporting requirements,

AccounTax Zone can help.

Book a FREE 30-minute initial consultation with a specialist Tech Accountant.

We can review:

• your accounting structure;
• subscription and revenue reporting;
• software development costs;
• tax position;
• financial systems; and
• management reporting.

Call: 020 3740 7074
Email: info@accountaxzone.com