IAS 38 was written around a fairly understandable idea.
A business researches an idea.
At some point, the idea becomes technically feasible and commercially realistic.
The project moves into development.
From that point, qualifying expenditure may be recognised as an intangible asset rather than immediately charged to profit.
That distinction is still important.
The problem is that modern software development often does not happen like that.
A digital product may be released early, changed every week and tested continuously. Developers add features, remove features, correct problems and respond to customer behaviour. The software may be technically usable while significant development is still taking place.
There may never be a single meeting where somebody says, “Research has finished. Development starts today.”
That creates an obvious accounting problem.
If a company cannot identify when its software project moves from research into development, when should capitalisation begin?
The question has become sufficiently important that the IASB is now using agile software development as a test case within its wider review of IAS 38.
For candidates working with an ACCA SBR tutor, this is a useful current issue because it takes a familiar accounting rule and places it inside a modern business model where the traditional boundaries are much less obvious.
The existing IAS 38 model is clear on paper
IAS 38 separates the creation of an internally generated intangible asset into research and development.
Research expenditure is recognised as an expense.
Development expenditure can be capitalised, but only once the company can demonstrate all of the required conditions.
Broadly, management needs evidence that the asset can be completed, that it intends and is able to complete and use or sell it, that future economic benefits are probable, that adequate resources are available and that qualifying expenditure can be measured reliably.
The principle protects financial statements from optimistic capitalisation.
A company cannot simply describe spending as an investment and place it on the balance sheet.
It needs evidence that an identifiable asset is actually being developed.
That discipline still makes sense.
The difficulty is identifying when the criteria are met in a development process that is deliberately designed not to have a clean beginning and end.
Agile development does not behave like a traditional project
Traditional software development is easier to picture.
Management identifies a need.
A project is approved.
Specifications are created.
The system is developed.
Testing follows.
The finished software is launched.
There may still be difficult accounting judgements, but the stages are visible.
Agile development works differently.
Teams often develop software through short cycles.
A basic version may be released quickly.
Users interact with it.
The business collects feedback.
Developers then improve the product, add functions, change the interface, remove features and release another version.
That process can continue indefinitely.
The software is never completely “finished” in the traditional sense.
This makes the research and development distinction harder to apply.
The project may be usable before development is finished
Suppose a company creates a new online customer platform.
The first version is launched after six months.
Customers can log in, place orders and make payments.
The system therefore works.
However, the company has another eighteen months of planned development.
It intends to add subscription functionality, automated recommendations, new reporting tools and integration with external software.
Has development finished?
Clearly not.
But has the asset become available for use?
Possibly.
That matters because IAS 38 does not only determine when capitalisation begins. It also determines when amortisation starts.
An intangible asset with a finite useful life generally begins to be amortised when it is available for use.
In an agile environment, the same software can therefore be operating while developers continue to improve it.
The accounting needs to distinguish between creating new functionality, maintaining existing functionality and simply operating the system.
That distinction is not always easy.
Not every developer salary can go on the balance sheet
One obvious risk is that companies treat the existence of a software development team as evidence that all of its expenditure is capital.
It is not.
A developer may spend Monday creating a significant new function.
Tuesday might be spent fixing a fault.
Wednesday could involve experimenting with an idea that is eventually abandoned.
Thursday might involve routine maintenance.
Friday could be spent improving existing code without creating significant additional functionality.
Those activities do not necessarily receive the same accounting treatment.
Management needs a reliable method for identifying expenditure that is directly attributable to creating or preparing a qualifying intangible asset.
That becomes difficult where staff work across multiple activities during the same sprint.
A vague estimate that “80 per cent of the technology team works on development” may not provide sufficient evidence.
The more material the capitalised balance becomes, the more important the underlying records become.
If research and development cannot be separated, the result is conservative
The existing IAS 38 requirements contain an important safeguard.
If a company cannot distinguish the research phase from the development phase of an internal project, the expenditure is treated as though it were incurred during research.
In practical terms, that means expense recognition.
This is deliberately cautious.
Management does not receive the benefit of capitalisation simply because its internal processes make the boundary difficult to identify.
That creates tension for agile software companies.
A commercially sensible development method can produce an accounting result that looks conservative because significant expenditure may be expensed even though management expects the product to generate benefits for years.
That does not automatically mean the standard is wrong.
It does explain why the IASB is examining whether the existing model works well for modern intangible assets.
The accounting cannot be driven by management’s preferred profit figure
Capitalising development expenditure increases assets and reduces current-period expenses.
That creates an obvious incentive.
A company growing quickly may want to demonstrate stronger profitability.
Management may argue that its technology spending is investment rather than operating cost.
Commercially, that description may have some truth.
Accounting recognition requires more.
The finance team needs evidence showing when the recognition criteria were satisfied and which expenditure relates to the qualifying asset.
The board should be particularly sceptical if the amount capitalised increases sharply at the same time management is under pressure to meet a profit target.
Professional judgement needs to work in both directions.
Companies should not expense expenditure automatically just because the accounting is difficult.
They should not capitalise it simply because management believes the project is valuable.
Minimum viable products create a particularly awkward boundary
Modern software businesses frequently use a minimum viable product, usually called an MVP.
The idea is to launch a functioning but limited version of the product, observe how customers use it and continue developing based on that evidence.
This can blur several accounting stages.
Before launch, the business may still be experimenting.
After launch, it may still be experimenting.
Some features may be technically feasible.
Others remain uncertain.
The company may not even know which future features customers will value.
This creates an important question.
Is the company developing one intangible asset that continues to evolve, or is it creating a series of separate additions and enhancements?
The answer depends on the circumstances.
A candidate should not assume that every new software release creates a separate asset.
Equally, management should not automatically treat years of continuous spending as the cost of one permanent development project.
The substance of what is being created matters.
New functionality and maintenance are not the same thing
This distinction becomes critical after software is already in use.
A development team might create a completely new customer payment system.
That could potentially create additional functionality and future economic benefits.
Another team may simply install security updates or correct errors.
Those activities maintain the existing system.
They do not necessarily create a new intangible asset.
The same problem occurs with performance improvements.
If developers rewrite code so that an application loads faster, has something new been created?
Possibly.
But an improvement does not automatically satisfy the recognition criteria.
Management still needs to identify the asset, establish that the relevant development criteria are satisfied and measure qualifying expenditure reliably.
Labels such as “upgrade”, “version 2” or “transformation programme” do not determine the accounting.
Continuous deployment makes cut-off harder
Many software businesses no longer wait months between releases.
Changes can be deployed daily or even several times a day.
That creates a practical accounting challenge.
Traditional project accounting may have expected a clear completion date.
Continuous deployment may create hundreds of small releases.
Some add features.
Some remove them.
Some correct bugs.
Some alter infrastructure.
A finance team cannot sensibly treat every code release as a separate capital project.
However, it still needs enough information to distinguish qualifying development from maintenance and research.
That may require closer integration between finance and technology teams.
Accounting cannot be performed properly from invoices alone.
The finance team needs to understand what developers were actually building.
Reliable cost measurement becomes a systems issue
IAS 38 requires expenditure attributable to the intangible asset to be measured reliably.
In agile environments, this can be one of the biggest practical obstacles.
Developers may work across several projects.
Cloud infrastructure may support both development and live operations.
Testing environments may be shared.
External contractors may perform different tasks within the same invoice.
Product managers may contribute to both research and development.
The business therefore needs records capable of separating expenditure appropriately.
Time recording may help, but it must be meaningful.
Creating detailed records after the year end because the auditor asks for them is much weaker than having a process that captures project activity as the work occurs.
This makes development accounting partly an internal control issue.
Cloud software makes the analysis even more complicated
Modern software development frequently depends on external platforms.
A company may build functionality on infrastructure controlled by another provider.
It may subscribe to software services, purchase licences, develop its own code and connect several applications through APIs.
The result may operate as one commercial system.
Accounting may see several different arrangements.
Some expenditure may relate to a service.
Some may create code controlled by the company.
Some may relate to configuration or customisation.
Some may be consumed immediately.
This is why simply saying “we spent £5 million developing the platform” tells the accountant very little.
The finance team must understand what rights and resources actually exist.
When does amortisation start if development never stops?
This is another awkward part of continuous software development.
An intangible asset begins to be amortised when it is available for use.
But what happens when the product is already live while the development team continues adding major functionality?
The existence of ongoing development does not necessarily mean the original asset is unavailable for use.
If the software is capable of operating in the manner intended by management, amortisation may need to begin.
Later qualifying expenditure could potentially relate to enhancements or additional development.
This means capitalisation and amortisation can occur at the same time within the wider software programme.
That may feel strange to management.
It is not necessarily contradictory.
A live product can contain an existing asset that is being consumed while new functionality is being created.
Useful lives may also be shorter than management expects
Software can become obsolete quickly.
A system expected to support the business for ten years may require substantial replacement after three.
Technology changes.
Customer expectations change.
Security requirements change.
External platforms change their specifications.
Competitors introduce better products.
Management therefore needs to reassess useful lives and impairment indicators rather than assuming that capitalised development expenditure automatically represents a long-term asset.
A large software balance should increase scrutiny, not reduce it.
The company must still demonstrate that future economic benefits are expected.
The current IASB work does not mean IAS 38 has already changed
This is important for SBR candidates.
The IASB is currently reviewing IAS 38 and is using agile software development as one of its test cases.
That does not mean there is already a new accounting rule for agile projects.
The Board is exploring whether aspects of the definition and recognition requirements need improvement.
Current accounting continues to follow IAS 38 as it stands.
A current issues answer should therefore distinguish between the existing requirements and the standard-setting discussion.
Avoid saying:
“Agile software can now be capitalised.”
That is not the current position.
A better answer would explain that agile development has exposed practical difficulties in identifying the development phase and applying the recognition requirements, and that the IASB is considering whether IAS 38 needs updating.
That is accurate and balanced.
How this could appear in an SBR scenario
Imagine a technology company has spent £12 million on a new platform.
Management capitalised the entire amount because the platform is expected to generate revenue for several years.
The development team works using short agile sprints.
The platform was launched halfway through the year, but development continued afterwards.
Staff worked on new features, bug fixes, security updates and experimental functions.
The company does not maintain detailed records showing how employees divided their time.
There are several issues immediately.
Management cannot capitalise expenditure simply because the project is expected to create future benefits.
The company must determine when the IAS 38 development criteria were satisfied.
Expenditure before that date would generally be expensed.
The company must also distinguish qualifying development from research and maintenance.
Reliable measurement may be difficult if staff time has not been recorded sufficiently.
Once the platform became available for use, amortisation may need to begin even though further development continued.
A strong answer would separate those points rather than simply saying that software development can be capitalised.
Why this is a good professional judgement topic
There may be pressure from several directions.
The technology team may see all development expenditure as investment.
Management may want to protect profit.
Auditors may be cautious where project records are weak.
Investors may want to understand how much money is being invested in future capabilities.
The accountant must balance those interests without allowing any of them to determine the accounting outcome.
That requires evidence.
When did technical feasibility become demonstrable?
What functionality was being created?
Which expenditure can be measured reliably?
When was the asset available for use?
What work simply maintained existing benefits?
Those questions make the accounting defensible.
What candidates should take from the IASB review
Do not turn this into another long current issues note.
Remember the tension.
IAS 38 assumes that internally generated intangible assets can be separated into research and development.
Agile software development can make that separation difficult because experimentation, development, release and improvement happen continuously.
The existing standard deals with uncertainty conservatively. If research and development cannot be distinguished, the expenditure is treated as research.
The IASB is now examining whether the recognition model remains appropriate for newer forms of intangible assets and modern development methods.
That is the current issue.
Candidates following an ACCA SBR course should then practise applying that issue to a scenario involving staff costs, ongoing releases, maintenance and uncertain project boundaries.
The accounting problem is not that agile development is unusual
Agile development is no longer unusual.
That is precisely why the issue matters.
Accounting requirements developed around traditional projects are increasingly being applied to businesses where products evolve continuously.
The answer cannot simply be to call everything development.
Nor can financial reporting ignore genuine internally generated resources because the development process looks different from an old-fashioned project plan.
The challenge is finding a recognition approach that remains disciplined without becoming disconnected from how businesses actually build software.
For now, IAS 38 remains the standard companies must apply.
That means identifying the asset, demonstrating the development criteria, measuring qualifying expenditure reliably and starting amortisation when the asset is available for use.
Where the evidence does not support capitalisation, expenditure remains an expense.
The development process may never feel finished.
The accounting decision still has to be made.
