Is Software a Fixed Asset?

Accounting for Software

Correctly accounting for software can vary depending on the arrangement. The treatment depends on the type of software, its value, how it was acquired and how it is used. A business may hold licences for ERP systems, financial software, payroll systems, CRM platforms and a wide range of operational tools. Each may require different accounting treatment.

The core questions are: is the software a fixed asset on the balance sheet? Is it tangible or intangible? Should the licence cost be capitalised or expensed? And if it is capitalised, how should it be amortised?

Incorrect treatment has a direct impact on the financial statements. Capitalising costs that should be expensed overstates assets and understates costs in the current period. Expensing costs that should be capitalised has the opposite effect. Both create audit risk.

What Makes Software a Fixed Asset

A fixed asset is an item that a business controls, expects to use for more than one accounting period, and holds for use in its operations rather than for resale. Software meets this definition when it is purchased or developed for long-term internal use, not for immediate resale or short-term consumption.

Under FRS 102 Section 18 (Intangible Assets other than Goodwill), an intangible asset is recognised when it is identifiable, the entity controls it, and it is expected to generate future economic benefits. Most software licences and internally developed software that meet the recognition criteria and capitalisation threshold will satisfy these conditions.

Software is almost always classified as an intangible fixed asset because it has no physical substance. The exception is where software is embedded in hardware and the hardware cannot function without it (for example, firmware). In that case, the software is treated as part of the tangible asset.

Capitalise or Expense: The Decision Framework

This is the decision that causes the most difficulty in practice. The treatment depends on three factors: how the software was acquired, the value relative to the capitalisation threshold, and the length of expected use.

Purchased perpetual licences

A perpetual software licence grants the right to use the software indefinitely. The upfront cost is typically capitalised as an intangible fixed asset, provided it exceeds the organisation’s capitalisation threshold. Implementation costs that are directly attributable to bringing the software to its intended use (installation, configuration, data migration, testing) can normally be included in the capitalised amount.

Costs that are not directly attributable to bringing the asset into use should be expensed. These include staff training, ongoing maintenance fees and consultancy costs related to business process changes rather than software configuration.

Subscription and SaaS arrangements

Software-as-a-Service (SaaS) and cloud computing arrangements have become the dominant model for business software. In most SaaS contracts, the customer does not take control of the software. They access it remotely, and the vendor retains ownership and control of the underlying code.

Under FRS 102 and IFRS, if the customer does not control the software, the arrangement is a service contract, not an asset. The subscription fees are typically recognised as an expense over the contract term as the service is received.

This applies even where the contract includes significant upfront configuration or customisation costs. In April 2021, the IFRS Interpretations Committee issued an agenda decision on configuration and customisation costs in cloud computing arrangements, concluding that where the customer does not control the resulting software, these costs are generally expensed (either as incurred or over the service period), unless they create a separate identifiable asset controlled by the customer.

This is a common area of inconsistency in practice. Organisations that moved from on-premises perpetual licences to SaaS often continue to capitalise costs out of habit, which overstates assets and understates operating costs.

Internally developed software

When an organisation builds its own software, the accounting treatment follows the development cost rules in FRS 102 Section 18 or IAS 38.

Costs incurred during the research phase (investigating feasibility, evaluating alternatives) are always expensed. Costs incurred during the development phase (coding, testing, integration) can be capitalised if the organisation can demonstrate that the recognition criteria are met, including technical feasibility, intention to complete, expected future economic benefit, and reliable measurement of costs.

In practice, the boundary between research and development is a judgement call. The capitalisation policy should define when a project moves from research to development, and this should be documented at the project level. See our guide on accounting for assets under construction for more on managing capital projects through to completion.

Below the capitalisation threshold

Software that costs less than the organisation’s capitalisation threshold is typically expensed in line with the organisation’s capitalisation policy. Low-cost annual subscriptions, individual desktop application licences and minor plug-ins will typically fall into this category.

Amortisation of Software Assets

Once capitalised, software is amortised over its useful economic life. Unlike tangible assets, software does not physically wear out, but it does become obsolete, unsupported or functionally inadequate over time.

Determining useful life

The useful life for amortisation should reflect the period over which the organisation expects to derive benefit from the software. Factors to consider include the licence term (for perpetual licences, this may be longer than the expected period of use), the vendor’s support and update roadmap, the pace of technological change in the relevant area, and the organisation’s own replacement cycle.

Common useful lives for software range from three to ten years, though the specific choice should be justified and documented rather than defaulted to a standard number.

Amortisation method

Straight-line amortisation is by far the most common method for software because the pattern of economic benefit is usually even across the asset’s life. Reducing balance or other methods can be used where the benefit is clearly front-loaded, but this is rare for software.

Residual value

The residual value of software is normally nil. Unlike property or specialist equipment, there is rarely a recoverable residual value, and internally developed software has no resale value to the organisation.

Review

FRS 102 requires the useful life and amortisation method to be reviewed at least at each reporting date. If the software is being replaced sooner than expected, or if the vendor has announced end-of-life support earlier than anticipated, the remaining useful life should be revised and the amortisation charge adjusted prospectively.

Where Software Intersects with Lease Accounting

Some software arrangements create obligations that sit closer to a lease than a straightforward purchase. Multi-year licence agreements with fixed annual payments, minimum commitment terms, and termination penalties may require assessment to determine whether they meet the definition of a lease under the relevant standard.

Under IFRS 16, a contract contains a lease if it conveys the right to control the use of an identified asset for a period of time. Most SaaS contracts do not meet this test because the customer does not control the underlying software. However, certain on-premises licence arrangements with dedicated servers or dedicated capacity may do.

Under FRS 102 Section 20, the distinction between finance leases and operating leases still applies. A multi-year software licence funded through a finance arrangement (for example, a lease line) may need to be recognised on the balance sheet as a finance lease rather than simply expensed.

The determining factor is whether the arrangement transfers substantially all the risks and rewards of ownership to the customer. If it does, it is a finance lease and the asset and liability must be recognised. If it does not, the payments are expensed over the term.

Organisations adopting updated FRS 102 lease accounting requirements from January 2026 should review their software contracts as part of that exercise to confirm the correct treatment.

Audit Considerations for Software Assets

Software assets attract audit attention because the capitalisation decision involves judgement, the boundaries between capital and revenue expenditure are not always clear, and the values can be significant.

What auditors test

Auditors typically examine the capitalisation policy to confirm it is consistent with the relevant accounting standard (FRS 102, IFRS, or local GAAP). They may also sample capitalised software costs to confirm they relate to the development phase (not research), are directly attributable, and exceed the threshold. They will test the amortisation charge by recalculating useful lives and checking for indicators that the useful life should be revised. They will review SaaS and subscription contracts to confirm that costs that should be expensed have not been capitalised. And they will look for evidence that AUC software balances are reviewed periodically and transferred to the live register when the software is available for use.

Common findings

The most frequent audit issues with software assets are: costs capitalised that do not meet the recognition criteria (particularly training, data cleansing, and business process consultancy), SaaS configuration costs capitalised as intangible assets when the customer does not control the software, software that has been available for use but remains in the AUC category (so amortisation has not started), useful lives that have not been reviewed despite clear indicators that the software will be replaced sooner than planned, and a weak audit trail between the capitalisation decision, the cost build-up and the amortisation schedule.

Building an audit-ready record

Each capitalised software asset should have a record in the fixed asset register that includes the original capitalisation approval, the cost breakdown (licence, implementation, development, testing), the date the software was available for use, the useful life and amortisation method with supporting rationale, and any subsequent revisions to the useful life or carrying amount. Where the software was internally developed, the register should also show when the project moved from research to development phase, and which costs were expensed during research.

Holding this in a dedicated fixed asset accounting system rather than relying on spreadsheets means the amortisation runs automatically, the audit trail is generated as a by-product of normal use, and auditors can access the supporting detail without reconstructing it from email threads and journal entries.

Managing Software Assets in the Fixed Asset Register

Software licences, internally developed applications and their associated costs should be recorded and managed in the same fixed asset register as tangible assets. Keeping software assets in a separate spreadsheet or a standalone schedule creates reconciliation risk and makes it harder to produce a consolidated view of the balance sheet.

Within the register, software assets should be coded to their own asset class so that amortisation policies, useful lives and reporting can be managed independently of tangible asset classes. For organisations that hold both perpetual licences and internally developed software, separate sub-classes are useful because the cost build-up and the audit requirements are different.

Specialist fixed asset accounting software handles amortisation alongside depreciation within the same system, applies the correct method per asset class, posts automatically to the general ledger, and maintains a complete history of every change to the asset record. This is particularly valuable for software assets because the amortisation period, the useful life and the capitalisation rationale all need to be visible to auditors in one place.

Summary

Software can be a fixed asset, but whether it should be capitalised or expensed depends on how it was acquired, whether the organisation controls it, its value relative to the capitalisation threshold, and the length of expected use. Perpetual licences and internally developed software that meet the recognition criteria are capitalised and amortised. SaaS subscriptions where the customer does not control the software are expensed.

Getting the treatment right matters for the accuracy of the financial statements, for tax, and for audit. Getting it wrong is one of the more common causes of audit adjustments in organisations with significant technology spend.

A clear capitalisation policy, proper cost coding from the outset, and a fixed asset register that holds the full record from capitalisation decision through to disposal will keep software assets under control and audit-ready.

If you would like to understand how FMIS supports software and intangible asset management, contact us or arrange a demonstration.