Companies can spend millions on software without actually owning much software at all.

That sounds strange until you look at how modern technology is bought.

A business might pay an implementation fee, annual subscription, configuration costs, integration charges, data migration fees and substantial amounts for custom development. Management may describe the whole project as an investment in a new technology platform.

The accounting question is different.

What does the company actually control?

That question is becoming increasingly important as businesses move away from software installed on their own systems and towards cloud-based Software as a Service arrangements.

It is also receiving renewed attention from the International Accounting Standards Board. In 2026, the IASB has been examining possible changes to aspects of IAS 38 Intangible Assets and has specifically used cloud-based software arrangements as a test case when considering how the definition and recognition requirements work.

For ACCA SBR candidates, this is an excellent current reporting issue. It combines IAS 38, contractual rights, professional judgement, digital transformation and the distinction between an asset and a service.

Candidates developing this kind of applied analysis with an ACCA SBR tutor should focus less on what management calls the project and more on the rights the company actually obtains.

Software spending has changed faster than software accounting

Traditional software purchases were comparatively easy to understand.

A company might buy a software licence, install the program on its own computers and obtain the right to use that software for an agreed period.

The business could often identify a separate resource.

Modern arrangements can look very different.

A company may subscribe to a cloud accounting system, customer relationship management platform or AI service. The supplier hosts the software on its own infrastructure and controls updates, security and the underlying application.

The customer simply logs in and receives access.

The business may pay a significant upfront implementation cost, but that does not automatically mean it has purchased an asset.

This creates tension between the commercial language and the accounting.

Management may describe a £5 million cloud transformation project as capital investment.

The financial statements may show much of that spending as an expense or prepaid service.

Both descriptions can be understandable in their own context.

The accounting treatment depends on whether the expenditure has created a resource controlled by the company.

Paying for software does not necessarily mean owning software

The first question should be simple:

Does the customer control the software?

A business may receive enormous economic benefit from a platform without controlling the underlying application.

Consider a company subscribing to an online finance system.

The supplier hosts the application.

The supplier controls the source software.

The supplier provides updates.

The supplier decides how the platform operates.

The customer receives the ability to access and use the software during the subscription period.

In that situation, the customer may have purchased a service rather than an intangible asset.

This distinction is fundamental.

The fact that the software is essential to the business does not create control.

The fact that the subscription is expensive does not create control.

The fact that the customer cannot operate effectively without the platform does not create control.

Accounting focuses on the rights obtained under the arrangement.

Control remains the key concept

IAS 38 requires an intangible asset to be an identifiable non-monetary asset without physical substance.

However, recognition is not based only on whether something valuable exists.

The company must control the resource.

Control broadly means that the business can obtain the future economic benefits arising from the resource and restrict others from accessing those benefits.

This becomes difficult in SaaS arrangements because the supplier often retains control over the software itself.

The customer may have contractual access, but access is not necessarily the same as control.

Imagine a retailer signs a five-year contract to use a cloud inventory system.

The retailer’s staff can log in and use the platform.

The retailer can enter its own inventory information.

The system is highly important to operations.

However, the supplier owns the application and can provide the same software to thousands of other customers.

The retailer does not control the underlying software merely because it depends on it.

The arrangement may therefore represent a right to receive a service over five years.

That changes how associated expenditure is considered.

Configuration costs create one of the biggest problems

Buying access to a standard cloud application is often only the beginning.

The customer may then spend heavily configuring it.

Configuration could include changing settings, defining workflows, establishing user permissions, setting reporting parameters and adjusting how existing functions operate.

Commercially, these costs may feel like part of building the new system.

Accounting does not necessarily see them that way.

If the configuration merely changes how the supplier’s existing software operates for the customer, it may not create a separate intangible asset.

The customer still does not control the underlying software.

The configuration may simply form part of the service required to make the cloud platform usable.

This is why finance teams need to analyse implementation expenditure rather than capitalising every cost attached to a technology project.

Customisation can produce a different answer

Customisation may go further than configuration.

A supplier or third party might write new software code specifically for the customer.

That raises another question.

Who controls the additional code?

If the customer obtains a separate piece of identifiable code, can benefit from it and can restrict others from using those benefits, the code may potentially qualify as an intangible asset.

The answer depends on the contract and the substance of the arrangement.

For example, imagine a company subscribes to a standard cloud platform but pays a developer to create a separate application that connects its warehouse systems to the cloud service.

The company owns the newly created code and can use it with another supplier if the main SaaS contract ends.

That looks very different from paying the SaaS provider to change a few settings inside its own application.

The first arrangement may create a resource controlled by the customer.

The second may simply improve the service the customer receives.

This distinction is more useful than asking whether the invoice says “software development”.

The contract matters more than the invoice description

Technology invoices can contain vague descriptions.

Implementation.

Integration.

Development.

Configuration.

Customisation.

Transformation services.

None of those labels decides the accounting treatment.

Finance teams need to understand what work was actually performed and what rights resulted from it.

The contract may reveal that the supplier retains all intellectual property rights.

Another agreement may give the customer ownership of newly developed code.

One implementation service may simply establish user accounts.

Another may create a separate interface controlled by the customer.

The accounting therefore needs to follow substance rather than terminology.

A strong SBR answer should do the same.

Do not write:

“The company has incurred software development costs and should therefore recognise an intangible asset.”

Instead ask:

“What identifiable resource has been created, and does the company control it?”

That is the professional judgement the scenario is testing.

When implementation costs are simply services

If no intangible asset is created, the next question is when the expenditure should be recognised as an expense.

This depends on the nature of the service and who provides it.

Suppose the SaaS supplier also performs configuration work that is not distinct from providing access to the software.

In economic terms, the customer may be paying part of the cost of obtaining the overall service.

The expenditure may therefore be recognised over the period in which the related service is received rather than necessarily being expensed immediately when the configuration work occurs.

Alternatively, if an independent consultant performs a separate configuration service and no asset is created, the customer may recognise the cost as an expense when that service is received.

The important point is that “not an asset” does not automatically answer every accounting question.

Management still needs to understand the service being received and the period to which the expenditure relates.

Data migration can feel valuable without creating an asset

Data migration is another area where businesses spend substantial sums.

Moving customer records, supplier data, historic transactions and product information from an old system into a new platform can be technically difficult and commercially essential.

That does not automatically create an intangible asset.

The migration service may simply move existing information from one location to another.

The company may already control the underlying data.

Paying someone to clean, convert or transfer it does not necessarily create a new resource.

The cost may therefore need to be expensed depending on the circumstances.

Again, the commercial importance of the activity is not the same as the accounting definition of an asset.

A project can be critical to the business and still create an accounting expense.

Training is another common capitalisation trap

New systems usually require employee training.

Management may argue that the training is necessary before the software can generate benefits.

That may be true.

It does not mean training expenditure becomes part of the intangible asset.

The company does not normally control the knowledge acquired by employees in the same way that it controls software code.

Employees can leave.

Their skills cannot usually be separated from them and sold by the company.

Training expenditure is therefore generally recognised as an expense.

This is a useful reminder that accounting does not simply capitalise every cost required for a project to succeed.

Each category of expenditure must be analysed separately.

One technology project can contain several different accounting treatments

A major cloud implementation should rarely be treated as one accounting object.

A single project could include:

• a SaaS subscription
• configuration services
• separately controlled custom code
• consulting services
• data migration
• employee training
• internal development work
• new hardware

Different elements may require different accounting treatments.

This is the only bullet list in this article because the central lesson is not to memorise categories.

It is to break the project apart.

A finance team that receives one large “digital transformation” budget should not assume that the entire amount can be capitalised or that the entire amount must be expensed.

The components need separate analysis.

Internal development introduces the research and development problem

Not every company buys software from an external supplier.

Some businesses develop their own applications.

IAS 38 distinguishes between research and development expenditure for internally generated intangible assets.

Research expenditure is recognised as an expense.

Development expenditure may be capitalised once the required conditions are satisfied.

That distinction becomes difficult in software development because projects are rarely linear.

Teams experiment.

They build prototypes.

They test different technologies.

They abandon features.

They change direction.

At some point, management may become confident that the project is technically feasible and will produce future economic benefits.

The challenge is identifying when that point occurs.

A company cannot decide retrospectively that the whole project was successful and capitalise costs from the beginning.

The recognition criteria need to have been satisfied at the time the qualifying expenditure was incurred.

Agile development makes the dividing line harder

Modern development methods make the traditional research and development distinction even more difficult.

Software teams may release small improvements continuously rather than build one clearly defined product.

Some work creates significant new functionality.

Some corrects defects.

Some maintains existing performance.

Some explores ideas that never reach production.

If the accounting process simply capitalises the salaries of everyone working in the development team, there is a risk that ordinary maintenance and research expenditure becomes part of the asset.

Management therefore needs systems capable of identifying qualifying development activity.

This is not simply an accounting-policy problem.

It is a data and internal-control problem.

If employees do not record their time or projects do not distinguish between maintenance and new development, finance may not have reliable information from which to measure the asset.

Why the IASB is looking at this again

The difficulty surrounding modern software arrangements is one reason intangible asset accounting remains under review.

The IASB has been considering potential changes to aspects of the definition and recognition requirements in IAS 38.

Cloud-based software arrangements provide a useful test case because they expose how difficult it can be to identify what the customer controls.

The business may obtain significant economic benefits from technology without receiving traditional ownership rights.

That does not necessarily mean the existing accounting is wrong.

Recognising every valuable software-related capability would create serious measurement and reliability problems.

However, the growth of SaaS, cloud infrastructure and other technology services raises legitimate questions about whether financial statements always provide the most useful picture of digital investment.

For SBR candidates, the important point is not to predict exactly how IAS 38 will eventually change.

The stronger answer is to explain the tension.

Existing requirements provide discipline by requiring identifiable, controlled resources before an asset can be recognised.

At the same time, modern business models can result in substantial economically important technology expenditure being recognised as services and expenses rather than assets.

That is a balanced current-issues discussion.

Management incentives make the distinction more important

There is another reason finance teams need to approach software costs carefully.

Capitalisation improves short-term profit.

If £2 million of expenditure is recognised as an intangible asset rather than an immediate expense, current operating expenses fall and reported profit rises.

The cost then affects future periods through amortisation and possible impairment.

That creates an incentive for management to prefer asset recognition.

A company trying to meet an earnings target, loan covenant or management bonus measure may be particularly keen to describe technology spending as investment.

This does not mean capitalisation is inappropriate.

It means the judgement needs evidence.

The audit committee should challenge whether the company genuinely controls an identifiable asset and whether the recognition criteria have been met.

Commercial enthusiasm for a digital transformation project should not determine the accounting.

The balance sheet can make two similar companies look very different

Suppose two companies introduce similar technology.

Company A develops its own qualifying software and capitalises part of the development expenditure.

Company B subscribes to a cloud platform providing broadly similar functionality and recognises subscription and implementation services as expenses.

The two businesses may gain similar operational benefits.

Their financial statements can look different.

Company A may report a larger intangible asset and higher current profit.

Company B may report fewer assets and higher operating expenses.

This creates a comparability issue.

It does not necessarily mean either treatment is wrong.

The accounting reflects the different contractual rights and control each company has.

Investors therefore need enough information to understand the business model rather than relying only on the amount of recognised intangible assets.

Disclosure becomes more important when recognition tells only part of the story

A company may make a major strategic investment in cloud technology while recognising relatively little of that expenditure as an asset.

That can make disclosure important.

Management might explain the nature of the transformation, significant commitments, the expected operational effect and major implementation risks.

However, narrative reporting should remain consistent with the accounting.

A company should not describe a SaaS platform as a valuable asset owned by the business if the accounting analysis concludes that the company only receives access to the supplier’s service.

The language should reflect the economic arrangement.

Good reporting helps investors understand both what the business is investing in and what rights it actually controls.

How this could appear in an SBR scenario

Imagine a retailer enters a five-year agreement with a cloud software provider.

The supplier hosts the application and retains ownership of the underlying software.

The retailer pays an annual subscription plus £1 million of implementation expenditure.

Part of the implementation fee relates to configuring the supplier’s existing software.

A separate developer also creates an integration application. The retailer owns that code and can continue using it if the SaaS provider changes.

Management proposes capitalising the entire £1 million because the implementation is expected to provide benefits for five years.

A weak answer would accept management’s reasoning because future benefits exist.

A stronger answer would separate the components.

The right to access the cloud application is a service because the retailer does not control the supplier’s software.

Configuration of that software may not create a separate asset and should be accounted for according to the nature and timing of the service received.

The separately developed integration code may potentially satisfy the definition of an intangible asset because the retailer controls the identifiable code.

The conclusion should reject the idea of treating the whole implementation programme in the same way.

That is exactly the kind of applied judgement SBR rewards.

A useful exam structure

For a software or SaaS requirement, a clear answer can follow a simple sequence.

First identify the resource.

What exactly does management claim is an asset?

Then assess control.

Who owns the software or code? Can the company obtain the benefits and restrict others’ access?

Then consider identifiability and recognition.

Is there a separate resource? Are the relevant recognition requirements satisfied?

Then analyse each associated cost.

Configuration, customisation, migration, training and internal development may not all receive the same treatment.

Finally, explain the financial statement effect and reach a conclusion.

This approach is more valuable than starting with a long definition of an intangible asset.

What finance teams should be doing now

Technology spending should be analysed before invoices arrive at year end.

Finance should be involved when major cloud contracts are negotiated.

The team needs access to the contractual terms, particularly around intellectual property, ownership of custom code, termination rights and the supplier’s responsibilities.

Project managers also need to understand why finance is asking detailed questions.

If accounting waits until after the implementation has finished, it may be difficult to reconstruct which costs related to configuration, separate development, training or migration.

Large programmes should therefore create an accounting workstream alongside the technical implementation.

That provides better evidence and reduces the risk of an aggressive year-end capitalisation decision.

What current SBR candidates should take from the issue

The software question is not really about software.

It is about control.

That makes it a useful reminder of how SBR should be approached generally.

Do not allow the label in the scenario to make the decision for you.

A “software investment” may be a service.

A “licence” may contain different rights.

A “customisation” may create a separate asset or simply alter a supplier-controlled platform.

A “development project” may contain both research and qualifying development expenditure.

The candidate needs to examine the substance.

Students following an ACCA SBR course should practise this through scenarios rather than trying to memorise one treatment for every type of technology expenditure.

The bigger reporting question

Modern companies increasingly create value through systems they do not own.

They use cloud platforms, external data, subscription software and AI services to run important parts of their operations.

This can make the traditional connection between investment and recognised assets less obvious.

A large technology budget does not necessarily produce a large intangible asset balance.

That is not automatically a failure of accounting.

It reflects the fact that economic benefit and accounting control are different concepts.

The challenge for standard setters is deciding whether the current distinction continues to give users the most useful information as business models become more dependent on externally controlled digital resources.

The challenge for companies is much more immediate.

They need to understand exactly what they have bought.

What to do next

Whenever a software project appears in an SBR question, ignore the project name for a moment.

Ask what resource has actually been created.

Ask who controls it.

Ask whether it is separate from the supplier’s software.

Ask what rights remain if the service contract ends.

Then analyse the costs individually.

That approach will usually lead you towards the correct accounting treatment.

Software spending can create an asset.

It can also purchase an extremely valuable service.

The amount spent does not decide which one it is.

Control does.