IAS 38 was written for a world where development projects were easier to describe.
Research happened first. Development followed. A product eventually became ready for use or sale.
Modern software development does not always work like that.
Agile teams work in short cycles. Features are designed, tested, changed and released incrementally. Customer feedback may alter requirements halfway through the project. Some ideas fail quickly while others become useful almost immediately.
That flexibility is commercially valuable.
It also creates an accounting problem.
When exactly does research end and development begin? Is every new feature a separate intangible asset? Should an entire software project be treated as one asset? When does capitalisation begin, and when should amortisation start?
These questions have become important enough for the IASB to use agile software development as a test case in its wider review of intangible asset accounting.
For candidates preparing with an ACCA SBR tutor, it is an excellent current issue because it shows what happens when an established accounting standard meets a business practice that does not fit comfortably into the assumptions behind the original rules.
The problem starts with how software is now built
Traditional software development is often described as a waterfall process.
The project moves through relatively clear stages.
Requirements are gathered.
The system is designed.
Development takes place.
Testing follows.
The completed product is deployed.
Maintenance begins afterwards.
That structure works reasonably well with the basic logic in IAS 38 because it is easier to identify when exploratory activity ends and genuine development begins.
Agile development is different.
Software is built through repeated iterations, often called sprints. Each sprint may produce working functionality. Feedback from users is then used to change priorities, redesign features or add new requirements.
Development and testing happen repeatedly.
Research-like activity can reappear after development has already started.
A product may also be released while further features are still being developed.
The process does not always have a neat point where someone can say, “Research has finished. Development begins today.”
That is where the accounting starts to feel strained.
IAS 38 still requires a research-development divide
IAS 38 currently distinguishes internally generated intangible asset expenditure between research and development.
Research expenditure is recognised as an expense when incurred.
Development expenditure may be capitalised when specified recognition criteria have been satisfied.
If the business cannot distinguish the research phase from the development phase, the expenditure is treated as though it arose during research.
That creates discipline.
A company cannot capitalise speculative expenditure simply because management hopes the project will eventually become valuable.
The problem is that agile development can cause research and development activities to occur repeatedly within the same project.
A team may develop one feature while still experimenting with another.
A working version may already be generating benefits while engineers continue exploring different technical approaches elsewhere in the product.
The traditional two-phase model can therefore become difficult to apply.
One sprint does not necessarily equal one asset
Another major question is the unit of account.
Suppose a software company develops an application through 20 separate sprints.
Each sprint produces some functionality.
Should each piece of functionality be assessed as a separate intangible asset?
That could create an enormous number of accounting units.
It might also produce an artificial result if the individual features only generate economic benefits when used together.
At the other extreme, management could treat the entire multi-year software programme as one enormous asset.
That creates a different problem.
If later experimental features remain technically uncertain, grouping everything together could delay recognition of functionality that is already complete and capable of generating benefits.
It could also delay amortisation.
Neither extreme necessarily reflects the economics.
That is why the IASB is looking carefully at how the appropriate unit of account should be identified.
The economic benefit may sit somewhere between a feature and the whole project
The IASB staff analysis has explored several possible approaches.
One possibility is treating everything approved as part of a single project as one unit.
Another is separating every distinct piece of functionality.
A third approach sits between the two.
Under that thinking, the unit of account could be based on the smallest group of functionality from which management expects to generate future economic benefits.
This is currently an area of exploration rather than a final requirement.
The logic, however, is useful.
Imagine a software company is building a new product with five planned features.
The first three need to work together before customers will buy the product. Features four and five are enhancements planned for later.
Treating all five features as one asset could be too broad.
Treating features one, two and three as three independent assets could be too narrow because management does not expect any of them to generate benefits independently.
The economically meaningful unit may therefore be the combination of the first three features.
That grouping becomes the point at which a usable product exists.
The later features may need separate assessment.
Agile development exposes the weakness of accounting by project label
Companies often organise development around internal project names.
That does not automatically mean the accounting unit should match the project management structure.
A project could contain several different assets.
Equally, several teams might be developing components that ultimately operate as one integrated asset.
The accountant needs to understand how the software generates benefits.
Can a feature be used on its own?
Does it significantly modify another feature?
Are several components highly interdependent?
Does management intend to release them together?
Would users obtain any meaningful benefit from one without the others?
These questions move the analysis away from administrative labels and towards economic substance.
That is exactly the kind of judgement SBR candidates need to develop.
Technical feasibility becomes difficult when failure is part of the method
One of the development recognition criteria under IAS 38 concerns technical feasibility.
In a traditional project, technical feasibility may become reasonably clear after a defined design or testing stage.
Agile development deliberately allows uncertainty to remain.
Teams experiment.
Some iterations fail.
That failure provides information that shapes the next sprint.
This is not necessarily evidence that the overall project is unfeasible.
It may simply be how the development method works.
The accounting challenge is therefore identifying when enough uncertainty has been resolved for the relevant asset to meet the recognition criteria.
A business should not automatically conclude that agile development prevents capitalisation.
It should also not assume that every sprint qualifies simply because working code has been produced.
The judgement has to be made at the appropriate level.
Probable future economic benefits can be equally awkward
Another recognition criterion concerns future economic benefits.
A software feature may technically work but have little value on its own.
Management may expect customers to pay only when several features are combined.
Alternatively, a small enhancement might immediately reduce operating costs even though a much wider software project remains unfinished.
Agile development makes these distinctions important.
The accountant needs to identify what resource is actually expected to generate benefits.
That might be a complete application.
It might be a collection of integrated functionality.
It might occasionally be an individual feature.
The answer depends on how the business expects to use the software.
A generic rule based purely on the number of sprints cannot solve that question.
Continuous development makes the finish line difficult to identify
Software does not always become “complete” in the traditional sense.
A digital product may be updated every week.
New features are added.
Security patches are released.
Interfaces change.
Performance is improved.
Old functionality is removed.
If development never truly stops, when does the company begin amortising the intangible asset?
The answer cannot simply be when the entire product stops changing.
That point may never arrive.
This is one reason identifying an appropriate unit of account matters so much.
If a group of functionality is available for use and capable of generating the expected economic benefits, it may need to begin its accounting life even while other features continue to be developed.
Otherwise, companies could continually expand the definition of the project and postpone amortisation.
That would produce an increasingly questionable carrying amount.
Enhancement and maintenance are not the same thing
Continuous software development also creates difficulty after initial recognition.
A team may spend the same working day fixing bugs, improving performance and creating a completely new feature.
Those activities can have different accounting implications.
Routine maintenance generally supports existing functionality rather than creating a new asset.
Expenditure that creates genuinely new functionality may need a different assessment.
The problem is identifying and measuring the costs reliably.
Modern development teams do not always record their working time according to accounting categories.
A developer may move between several tasks during a sprint.
Cloud infrastructure may support both existing and new functionality.
Testing teams may work across maintenance and development simultaneously.
The accounting department therefore needs information that the development process may not naturally produce.
This becomes an internal control issue as much as a technical accounting issue.
Poor time recording cannot justify aggressive capitalisation
Management may argue that separating qualifying and non-qualifying expenditure is difficult.
Difficulty does not justify capitalising everything.
If the company cannot measure the cost attributable to a qualifying intangible asset reliably, that is relevant to whether recognition is appropriate.
Finance teams therefore need to work with software teams before year end.
Projects should be structured so that qualifying expenditure can be identified where possible.
Development records should explain what functionality was being created.
Time and supplier costs should be capable of being linked to the relevant activities.
The objective is not to turn developers into accountants.
It is to create enough evidence for the accounting treatment to be supportable.
There is an obvious profit incentive
Capitalising development expenditure normally reduces the immediate expense recognised in profit or loss.
That creates a management incentive.
A business under pressure to meet profit targets may prefer to classify more software expenditure as development.
A rapidly growing technology company may also prefer a balance sheet showing substantial intangible assets rather than a large current-period expense.
That does not mean capitalisation is wrong.
It means the judgement deserves challenge.
The audit committee should understand when capitalisation begins, how the unit of account was determined, how qualifying costs are identified and whether the same approach is applied consistently.
An accounting policy should follow the economics of the development process rather than the desired profit figure.
Agile does not mean IAS 38 has already changed
This distinction is important for current issues answers.
The IASB is using agile software development as a test case while considering potential improvements to IAS 38.
The October 2026 staff paper explores possible approaches.
It does not introduce new mandatory accounting requirements.
The IASB has not yet decided what final changes, if any, should be made.
Current financial statements must therefore continue to apply the existing requirements.
An SBR candidate should avoid writing as though the exploratory staff thinking is already part of IAS 38.
A stronger answer distinguishes clearly between current requirements and the direction of the IASB’s research.
That precision matters.
Why simply expensing everything is not necessarily better
One response to the complexity would be to expense all internally developed software expenditure.
That would be simple.
It would also create problems.
A business may spend substantial amounts developing software that it controls and expects to use for several years.
Recognising all expenditure immediately could understate the resources being created and make current expenses unusually high.
It could also reduce comparability with a competitor that acquires similar software from an external supplier and recognises an intangible asset.
The challenge is therefore not simply preventing capitalisation.
The challenge is recognising assets when the accounting genuinely reflects an identifiable resource while avoiding recognition of speculative expenditure.
That balance sits at the heart of IAS 38.
The acquisition comparison remains uncomfortable
Software accounting also highlights a wider issue with intangible assets.
Internally generated software may face strict recognition requirements.
If another company buys the business, identifiable technology may be recognised separately at fair value as part of the acquisition accounting.
The same underlying resource can therefore become more visible in the financial statements after a change in ownership.
That tension already exists within intangible asset accounting.
Agile development makes it more noticeable because modern businesses can invest heavily in software while relatively little appears as a recognised asset.
This is one reason the IASB’s Intangible Assets project is looking more broadly at whether current information remains useful to investors.
How this could appear in an SBR scenario
Imagine a company developing a new digital platform using two-week sprints.
Management has capitalised all developer salaries since the board approved the overall project.
Some features are already operating.
Others remain experimental.
Developers also spend time fixing existing software, but their time records do not distinguish maintenance from new development.
Management argues that the whole programme will eventually generate substantial revenue.
A weak answer might simply recite the six IAS 38 development criteria.
A stronger answer would identify several separate concerns.
Board approval does not automatically establish that the development recognition criteria were satisfied from that date.
The business needs to identify the appropriate intangible asset or units of account.
Experimental activity may remain research expenditure.
Maintenance costs should not automatically be capitalised as development expenditure.
Management must be able to measure qualifying expenditure reliably.
Functionality that is already available for use may also affect when amortisation should begin.
The final answer should recommend that management reassess the project structure and supporting cost records rather than accepting the blanket capitalisation policy.
That is a board-ready response.
What this teaches candidates about current issues
Current issues questions are rarely about memorising the latest IASB meeting.
The useful part is understanding the reporting problem.
Agile software development exposes several weaknesses in applying the existing IAS 38 model.
The project does not always have clear research and development phases.
Individual development cycles may be too narrow to represent meaningful assets.
Entire projects may be too broad.
Technical feasibility can evolve rather than appearing at one obvious milestone.
Economic benefits may depend on groups of features.
Maintenance and enhancement expenditure can be mixed together.
Once you understand those problems, you can discuss why the IASB is reviewing the requirements even if you cannot remember every detail of a staff paper.
What finance teams should be doing now
Businesses using agile development should not wait for a future amendment before improving their accounting processes.
Current IAS 38 still needs to be applied.
Finance teams should understand how software projects are actually managed rather than forcing a waterfall accounting model onto a process that works differently.
They need to identify what resources are being created, how those resources generate benefits and when recognition criteria are satisfied.
Cost information also needs to be reliable.
Where development expenditure is material, finance and technology teams should agree how relevant activities will be documented and how qualifying costs will be captured.
The accounting policy should then be reviewed as development methods evolve.
A policy written ten years ago may no longer reflect the way the business builds software today.
What to do next
Agile software development is not breaking accounting because software is somehow impossible to recognise.
It is exposing assumptions that were easier to make when development followed a clear sequence.
Modern software can be released incrementally, changed continuously and built from functionality that only creates value when several components work together.
IAS 38 still provides the current accounting framework.
The IASB is now asking whether parts of that framework can be made easier to apply to these newer development methods.
Candidates following an ACCA SBR course should focus on that tension.
Understand the current requirements.
Identify where agile development makes them difficult to apply.
Then explain what information management would need to support a credible accounting judgement.
That is much stronger than saying software development costs should either all be capitalised or all be expensed.
The real question is what asset has been created, when it became recognisable and which expenditure genuinely belongs to it.
Agile development may have changed how software is built.
Accounting still has to work out what the business actually owns.
Leave a Reply