R&D Capitalisation Under IFRS (IAS 38): The 6-Test Framework
The Binary Distinction at the Heart of IAS 38
Under IAS 38, every pound of research and development spend sits in one of two phases — and the accounting treatment is binary. Research-phase costs are expensed in full, in the period incurred, without exception. Development-phase costs must be capitalised when six specific tests are met. There is no middle ground, no policy choice, and no judgement available once a project crosses the line.
IAS 38 paragraph 54 is unambiguous: "No intangible asset arising from research (or from the research phase of an internal project) shall be recognised. Expenditure on research shall be recognised as an expense when it is incurred." Paragraph 57 sets out the six development-phase tests that, when satisfied together, force capitalisation. The word in paragraph 57 is shall, not may.
R&D capitalisation under IAS 38 is not optional. Once all six development-phase tests are met simultaneously, capitalisation is mandatory from that date forward. Expensing development costs that meet the criteria misstates assets and current-period earnings just as surely as capitalising research costs does.
Research vs Development: Where the Line Sits
IAS 38 paragraph 8 defines research as "original and planned investigation undertaken with the prospect of gaining new scientific or technical knowledge and understanding." Development is "the application of research findings or other knowledge to a plan or design for the production of new or substantially improved materials, devices, products, processes, systems or services before the start of commercial production or use."
The practical distinction is whether the work is still asking can this be done? (research) or how do we build the thing we already know can be done? (development). The line is crossed when technical feasibility has been established and a defined design specification exists.
Typical research-phase activities
- Activities aimed at obtaining new knowledge
- Searches for, evaluation of, and final selection of applications of research findings or other knowledge
- Searches for alternatives for materials, devices, products, processes, systems or services
- Formulation, design, evaluation and final selection of possible alternatives for new or improved materials, devices, products, processes, systems or services
Typical development-phase activities
- Design, construction and testing of pre-production or pre-use prototypes and models
- Design of tools, jigs, moulds and dies involving new technology
- Design, construction and operation of a pilot plant
- Design, construction and testing of a chosen alternative for new or improved materials, devices, products, processes, systems or services
Where an entity cannot distinguish the research phase from the development phase of an internal project, IAS 38 paragraph 53 requires the entity to treat the expenditure on that project as if it were incurred in the research phase only — i.e., expense everything. The default position when documentation is weak is to expense, not capitalise.
The Six Development-Phase Tests (IAS 38 §57)
Paragraph 57 of IAS 38 sets out the six tests that an entity must demonstrate are met before any development-phase expenditure can be capitalised. All six apply concurrently. Missing one means capitalisation cannot begin; failing one later means amortisation begins or impairment is tested.
Test 1 — Technical Feasibility
The entity must demonstrate the technical feasibility of completing the intangible asset so that it will be available for use or sale.
In a software context, this means the core architecture has been proven — typically through a working prototype or a successful proof-of-concept — and there are no unresolved technical risks that could prevent completion. A team building a recommendation engine on well-understood machine-learning frameworks has technical feasibility. A team attempting a novel cryptographic primitive that has not been validated by peer review or working code does not.
Evidence that satisfies: working prototype, completed architecture document signed off by the CTO, technical review by an independent specialist, successful integration tests for the critical-path components.
Evidence that does not satisfy: "the team is confident", roadmap slides, vendor demos of similar but distinct technology.
Test 2 — Intention to Complete
The entity must demonstrate its intention to complete the intangible asset and use or sell it.
This is the easiest test to evidence but the easiest to fail in practice. A board minute approving the project, an approved business case, and an explicit budget line in the operating plan all count. A "skunkworks" effort that the executive team has not formally endorsed does not.
Evidence that satisfies: board or executive-committee minute approving the project, business case in the approved annual plan, a named accountable executive, a dedicated team with cost-centre tracking.
Evidence that does not satisfy: ad-hoc engineering exploration, an experiment running on slack time, a project whose continued funding requires renewed approval each quarter.
Test 3 — Ability to Use or Sell
The entity must demonstrate its ability to use or sell the intangible asset.
For software intended for commercial sale, this typically means a defined go-to-market plan: target customer segment, channel, pricing, and the operational capability to deliver. For internal-use software, it means a defined business unit that will operate the system and a deployment plan.
The test is not whether the asset will be commercially successful — that is a separate question handled by Test 4. The test is whether the entity has the operational ability to take the finished asset to market or into production.
Evidence that satisfies: signed pilot agreements, an approved commercial launch plan, an internal operations team committed to running the asset, regulatory permissions obtained or on a clear path.
Test 4 — Future Economic Benefits (Probable)
The entity must demonstrate how the intangible asset will generate probable future economic benefits. Among other things, the entity must demonstrate the existence of a market for the output of the intangible asset or the intangible asset itself or, if it is to be used internally, the usefulness of the intangible asset.
Paragraph 60 elaborates: the entity should assess the future economic benefits using the principles in IAS 36 (impairment). For a market-facing asset, this means a defensible revenue forecast supported by demand evidence — customer interviews, signed letters of intent, comparable product data. For internal-use software, it means a quantified efficiency or cost-avoidance case.
A UK SaaS company building a new ML-driven pricing module produces a forecast showing £4.2m of incremental annual revenue over five years, supported by three signed pilots and competitor pricing benchmarks. This satisfies Test 4. A speculative consumer app with no user research and no comparable product data does not.
Evidence that satisfies: a quantified revenue model with sensitivity analysis, signed letters of intent or pilot contracts, customer-interview research, comparable-product data, an internal-use business case with quantified savings.
Evidence that does not satisfy: "the team believes there is a large addressable market", strategic-fit arguments without numbers, "this fits our long-term vision".
Test 5 — Adequate Resources to Complete
The entity must demonstrate the availability of adequate technical, financial and other resources to complete the development and to use or sell the intangible asset.
The financial test is concrete: is there committed funding — either from existing cash reserves, an approved facility, or contracted external funding — to take the project to completion? The technical test is harder: are the specialist skills in place or contracted, and are the dependencies on third parties manageable?
Evidence that satisfies: approved budget through to completion, signed-off resourcing plan, key-person retention agreements, identified or contracted external specialists where in-house skills are missing.
Evidence that does not satisfy: a project that depends on a Series B that has not closed, a single key engineer who has given notice, an unsigned vendor contract for critical IP.
Test 6 — Reliable Measurement of Expenditure
The entity must demonstrate its ability to measure reliably the expenditure attributable to the intangible asset during its development.
In practice, this means time-tracking by project, a cost-accounting system that allocates direct labour and directly attributable overheads to the project, and documented capitalisation policies. Paragraph 66 lists what can be included: directly attributable costs necessary to create, produce and prepare the asset to be capable of operating in the manner intended by management — this includes employee benefits arising from the generation of the asset, fees to register a legal right, and amortisation of patents and licences used to generate the asset.
Paragraph 67 lists what cannot: selling, administrative and other general overhead expenditure (unless directly attributable), inefficiencies and initial operating losses, and expenditure on training staff to operate the asset.
| Cost type | Capitalisable? | Authority |
|---|---|---|
| Direct development labour (loaded) | Yes | IAS 38 §66 |
| Directly attributable overhead | Yes | IAS 38 §66 |
| Externally contracted development | Yes | IAS 38 §66 |
| Software licences used in development | Yes (amortisation portion) | IAS 38 §66 |
| Borrowing costs (qualifying asset) | Optional — IAS 23 | IAS 23 §8 |
| General R&D management overhead | No | IAS 38 §67 |
| Training costs | No | IAS 38 §67 |
| Initial operating losses | No | IAS 38 §67 |
| Sales and marketing | No | IAS 38 §67 |
Evidence that satisfies: time-tracking by project, a finance system with project-cost codes, a written capitalisation policy reviewed annually, sample auditable cost listings.
Evidence that does not satisfy: estimated labour splits, no project-cost codes, capitalisation policy reverse-engineered at year-end.
Worked Example: A UK SaaS Company Builds a New ML Platform
OrbitalPay Ltd is a UK-incorporated SaaS company reporting under UK-adopted IFRS. In FY2026 it begins a 14-month project to build a new machine-learning fraud-detection platform for its enterprise customers. Total project spend is £1.85m. Below is how the costs split between expense and capitalisation under IAS 38.
Phase 1 — Research and feasibility (months 1–3, £240k)
The team evaluates three alternative ML architectures, trials open-source frameworks, and builds throwaway prototypes to assess each option. There is no approved design at this point. All £240k is expensed in the period incurred under IAS 38 §54.
Phase 2 — Design and architecture lock-in (month 3, £35k)
The CTO signs off the final architecture; the board approves the £1.6m development budget; a named launch customer signs a pilot agreement. Tests 1–5 of paragraph 57 are now demonstrably met; the finance system already has project-cost codes (Test 6). Capitalisation begins from the date of the board approval.
Phase 3 — Development (months 4–11, £1.18m)
| Cost category | Total | Treatment | Authority |
|---|---|---|---|
| Engineering labour (loaded) | £820k | Capitalise | IAS 38 §66 |
| Externally contracted ML specialists | £210k | Capitalise | IAS 38 §66 |
| Cloud compute and tooling (project-attributable) | £95k | Capitalise | IAS 38 §66 |
| Project-management overhead (directly attributable portion) | £55k | Capitalise | IAS 38 §66 |
| General CTO-office overhead | £25k | Expense | IAS 38 §67 |
| Training (pre-launch) | £18k | Expense | IAS 38 §67 |
| Sales prep and marketing | £62k | Expense | IAS 38 §67 |
Of the £1.18m gross, £1.18m × (820+210+95+55)/(820+210+95+55+25+18+62) = £1.08m capitalised; £105k expensed.
Phase 4 — Testing and pre-launch (month 12, £210k)
Integration testing, security review, pilot deployment with the launch customer. £165k of directly attributable cost is capitalised; £45k of training and pre-launch sales support is expensed.
Phase 5 — Available for use (end month 12)
The platform is "capable of operating in the manner intended by management" — IAS 38 §30. Capitalisation ends. Total capitalised intangible asset: £1.28m. Amortisation begins over an estimated useful life of five years.
Phase 6 — Post-launch (months 13–14 and ongoing, £155k)
Routine bug fixes, maintenance, and minor configuration changes are expensed as incurred. A discrete feature project to add a new fraud-pattern module — if it independently satisfies the six tests — could be capitalised as a separate addition.
OrbitalPay's audited FY2026 financials show £1.28m added to intangible assets, with £128k of amortisation in the first year (assuming the platform goes live in month 12 and is amortised straight-line over 60 months from that point). The P&L records £390k of R&D expense (research phase + non-capitalisable development costs + post-launch maintenance). Without capitalisation, the P&L would have absorbed all £1.85m, materially understating EBITDA and overstating the cost-to-serve.
Indefinite Reassessment and Impairment
Capitalisation is not a one-time decision. IAS 38 paragraph 71 requires the entity to assess at each reporting date whether there is any indication that the asset may be impaired. Triggers include project cancellation, scope reduction, loss of the launch customer, regulatory changes, or evidence that the future economic benefits forecast in Test 4 are no longer probable.
If a project is abandoned, the carrying value is written off immediately. If a project is pivoted, the impairment test under IAS 36 must be run and any shortfall recognised in the period. Auditors increasingly focus on capitalised development balances where the underlying project has slipped, lost a key customer, or missed milestones — and rightly so.
Capitalising development costs requires ongoing discipline, not just a one-time recognition decision. A capitalised balance that sits on the balance sheet after a project has been cancelled, deferred, or commercially failed is a material misstatement waiting to be found. Finance teams must build a quarterly review of every capitalised project into their close cycle.
Useful Life and Amortisation
Once available for use, the capitalised asset is amortised over its estimated useful life under IAS 38 §97. Useful life must be the period over which the asset is expected to generate economic benefits — not a default policy choice. For most internally developed software, useful lives sit between three and seven years; for platform-class assets with strong moats and active investment, longer lives may be justified but require explicit support.
The amortisation method should reflect the pattern in which the asset's future economic benefits are consumed (IAS 38 §97). Straight-line is the default and is appropriate when consumption is broadly even. Accelerated methods may be appropriate where benefits front-load (e.g., a one-off compliance system that delivers most of its value in year one).
Useful life and amortisation method must be reviewed at least at each financial year-end (IAS 38 §104) and changed as a change in accounting estimate under IAS 8 where circumstances change.
FRS 102: The UK Small-Entity Optional Capitalisation Policy
UK entities not reporting under IFRS apply FRS 102. Section 18 of FRS 102 differs from IAS 38 in one critical respect: capitalisation of development costs is a policy choice, not a requirement.
IAS 38 (UK-adopted IFRS)
- Research phase: expense (mandatory)
- Development phase: capitalise when 6 tests met (mandatory)
- No optional treatment
- Amortisation period: estimated useful life
FRS 102 Section 18
- Research phase: expense (mandatory)
- Development phase: policy choice — either expense all, or capitalise when criteria met
- Policy applied consistently to all development costs
- Amortisation period: up to 10 years if useful life cannot be reliably estimated
The policy choice in FRS 102 §18.8H means many smaller UK entities choose to expense all development costs — simpler, more conservative, no capitalisation discipline required. Entities that capitalise must apply the same six-test framework as IAS 38, must apply the policy consistently to all qualifying development, and must disclose the policy in the accounts.
An entity that transitions from FRS 102 to IFRS — typically on listing or as part of growth — loses the policy choice and must capitalise development costs that meet the IAS 38 tests. This often produces a material restatement of opening retained earnings.
US GAAP: ASC 730 and ASC 350-40 — A Different Logic
US GAAP takes a different approach to R&D. For most internal R&D, ASC 730 requires immediate expensing — there is no equivalent of IAS 38's six-test capitalisation framework. This is the largest single difference between IFRS and US GAAP in this area.
The exception is software. ASC 350-40 governs internal-use software and uses a staged framework based on project phase rather than the satisfaction of six discrete tests:
| ASC 350-40 stage | Treatment | Equivalent under IAS 38 |
|---|---|---|
| Preliminary project stage | Expense | Research phase |
| Application development stage | Capitalise | Development phase (post-§57 satisfaction) |
| Post-implementation stage | Expense (unless enhancement) | Post-availability-for-use |
ASC 985-20 covers software developed for external sale and applies a different threshold: capitalisation begins at "technological feasibility" — typically when a detailed program design or working model exists.
The practical consequence is that a US group reporting under US GAAP and an identical UK group reporting under IFRS can produce very different balance sheets and P&Ls for the same R&D activity. Dual-listed groups maintain reconciliations.
The 2017 Tax Cuts and Jobs Act changed the US tax treatment of R&D — section 174 now requires capitalisation and amortisation for tax purposes (5 years US, 15 years foreign), even where book treatment under ASC 730 is to expense. Book-tax reconciliations have become materially more complex as a result. Recent legislative proposals would restore immediate tax deductibility, but until enacted the capitalised-tax-asset treatment stands. UK groups with US R&D operations need to track both.
Common Pitfalls in IFRS R&D Capitalisation
- Treating capitalisation as optional — once the six tests are met, IAS 38 §57 makes capitalisation mandatory. Expensing because it "feels conservative" is a misstatement.
- Capitalising research as development — early-stage feasibility, prototype-to-throw-away work, and architecture-selection effort is research. The presence of code does not establish technical feasibility.
- Backdating capitalisation to project start — capitalisation begins on the date all six tests are simultaneously met, not on the date the project began.
- Failing the measurement test by retrofitting cost data — if the cost-accounting system did not track development costs by project at the time they were incurred, the measurement test (Test 6) cannot be met retrospectively.
- Capitalising training, marketing and general overhead — IAS 38 §67 is explicit; only directly attributable costs are capitalisable.
- Ignoring impairment indicators after launch — a capitalised asset whose underlying project has been cancelled, pivoted, or commercially disappointed must be tested for impairment under IAS 36.
- Choosing a useful life that bears no relation to the asset — defaulting every internal-software project to a five-year useful life without analysis attracts auditor and regulator challenge.
Disclosure Requirements
IAS 38 §118 requires entities to disclose, for each class of intangible assets, the useful lives or amortisation rates used, the amortisation methods used, the gross carrying amount and accumulated amortisation, and a reconciliation of opening to closing balances. Paragraph 126 requires the aggregate research and development expenditure recognised as an expense in the period.
Audit committees should expect to see:
- The total R&D spend in the period
- The amount capitalised and the amount expensed
- The basis on which the entity satisfied itself that the six tests were met for each capitalised project
- The carrying value and amortisation policy by project class
- Any impairment indicators identified and the resulting accounting treatment
Resources and Next Steps
- Value your capitalised R&D portfolio — use the Opagio Valuator to assess the economic value of your capitalised development assets, not just their accounting carrying value
- Read the full software-capitalisation guide — our Software as an Intangible Asset deep-dive covers ASC 350-40 in detail
- Glossary — start with IAS 38, research and development, software capitalisation, capitalisation, and amortisation
- FAQ — Can you capitalise intangible assets on the balance sheet?
- Related articles — How to value a patent: 4 methods covers how the patents that R&D produces get valued under each method; IFRS 3 vs ASC 805: PPA comparison shows how capitalised R&D appears in an acquirer's purchase price allocation
About the Author
Ivan Gowan is the Founder and CEO of Opagio. With 25 years in financial technology — including building and scaling technology platforms at IG Group — he has direct operating experience of R&D capitalisation decisions, audit-committee challenge on intangible-asset balances, and the strategic role of capitalised technology in high-growth businesses. This article was reviewed by Tony Hillier, Opagio Co-Founder and former director at N M Rothschild and GEC Finance, whose 30 years in valuation, due diligence and structured finance underpin our methodology. Meet the team.
Subscribe to our newsletter
Get the latest insights on intangible asset growth and productivity delivered to your inbox.
Want to learn more about your intangible assets?
Book a free consultation to see how Opagio Intangibles can help your business.