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.

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 (IAS 38.56)

• 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 (IAS 38.59)

• 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

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; if one stops being met later, capitalisation stops and the asset is tested for impairment.

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.

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.

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.

Date the Evidence for Each Test

Capitalisation starts on the date the last of the six tests is met (IAS 38.65), and IAS 38.71 stops any cost expensed before that date from being reinstated later. So the evidence file needs a date against every test, not just a yes:

Capitalisation start-date evidence file

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.82m. 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 and a named launch customer signs a pilot agreement; the board then approves the £1.6m development budget. 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, the last of the six dates, so the £35k of detailed design work after it is the first capitalised cost.

Phase 3 — Development (months 4–11, £1.18m)

Of the £1.18m, £1.075m is capitalised (£760k + £190k + £85k + £40k) and £105k is 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 available for use: "in the location and condition necessary for it to be capable of operating in the manner intended by management" (IAS 38 §97). Capitalisation ends. Total capitalised intangible asset: £1.275m (£35k + £1.075m + £165k). 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.

Indefinite Reassessment and Impairment

Capitalisation is not a one-time decision. IAS 38.111 applies IAS 36, which requires the entity to assess at each reporting date whether there is any indication that the asset may be impaired (IAS 36.9). An asset that is not yet available for use must be tested for impairment every year, indicator or not (IAS 36.10). 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.

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.

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 can increase opening retained earnings, but only for projects whose assessment was documented at the time and whose costs were captured as incurred (IFRS 1.IG46-47).

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 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.

Common Pitfalls in IFRS R&D Capitalisation

1. Treating capitalisation as optional — once the six tests are met, IAS 38 §57 makes capitalisation mandatory. Expensing because it "feels conservative" is a misstatement.
2. 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.
3. Backdating capitalisation to project start — capitalisation begins on the date all six tests are simultaneously met, not on the date the project began.
4. 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.
5. Capitalising training, marketing and general overhead — IAS 38 §67 is explicit; only directly attributable costs are capitalisable.
6. 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.
7. 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.

For the full checklist and a note that reconciles, see our IAS 38 disclosure requirements guide.

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

• The whole standard on one page — our IAS 38 intangible assets guide summarises IAS 38 paragraph by paragraph, with the recognition decision tree
• Ten scenarios with journal entries — our IAS 38 worked examples follow one company from the capitalisation start date to amortisation, impairment and disposal
• A written capitalisation policy — our IAS 38 capitalisation policy template sets out each section, the evidence auditors ask for against each of the six tests, and the FRS 102 variant
• The tax side of the same spend — our comparison of R&D tax relief vs capitalisation explains why capitalising development costs does not change a UK R&D tax relief claim
• SaaS implementation spend — our guide to SaaS configuration costs under IAS 38 covers when configuring or customising cloud software is expensed, spread over the contract or capitalised, with the US GAAP comparison
• When an intangible is valued, not costed — our IFRS intangible asset valuation guide explains when IFRS 3, IAS 36 and IFRS 13 call for a value, on what basis, and which method fits each asset
• 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