Rethinking IAS 38 in the Age of AI: The End of Waterfall Accounting

1. Historical Context: The Windows Era (1990s～)

In the late 1990s, the world witnessed the "Software Revolution" led by Microsoft's Windows. Software was no longer a peripheral tool — it became the core engine of business value.

In response, IAS 38: Intangible Assets was established in 1998. Its primary mission: move software costs from "period expenses" to "capitalized assets," acknowledging that intangible investments could generate long-term economic returns just like factories or machinery.

To understand why IAS 38 is beginning to show its age, we first need to understand what it was originally designed to do.
The first half of this article explains the standard on its own terms.
The second examines where that logic begins to break in the age of AI.

2. Structural Overview: The Architecture of IAS 38

Before diving into the details, here is a map of the standard — broken down by classification and key issues within each.

3. Key Provisions in Detail

A. Core Definitions (Para 8–17)

An intangible asset is recognized only if it meets three criteria:

• Identifiability: It is separable or arises from contractual/legal rights.

• Control: The entity has the power to obtain benefits and restrict others' access.

• Future Economic Benefits: It must be expected to generate revenue or cost savings.

B. Recognition and Initial Measurement (Para 18–50)

Recognition follows the same two-threshold logic found across IFRS: it is probable that future economic benefits will flow to the entity, and the cost can be measured reliably. In practice, these thresholds are straightforward for most acquisition routes — the standard effectively presumes they are met when an intangible is acquired externally.

Initial measurement depends on how the asset was acquired. Three routes exist, each with meaningfully different accounting treatment:

• Separate acquisition: Measured at cost — purchase price plus directly attributable expenditure. The probability criterion is always considered satisfied. This is the cleanest case.

• Acquisition as part of a business combination (IFRS 3): Measured at fair value at the acquisition date. Crucially, the identifiability criterion — not the probability criterion — is the only gate. This has a significant consequence: brands, customer lists, and publishing titles that are strictly prohibited from capitalization when internally generated must be recognized at fair value if acquired through a business combination. The same asset. Opposite treatment. This is one of the most well-known tensions in IAS 38, and we return to it in Section 4.

• Government grant (IAS 20): An entity may choose to recognize the asset at either fair value or a nominal amount (even zero). This is a deliberate policy choice, not an error — IAS 20 permits it explicitly.

C. The Research and Development Split (Para 51–67)

IAS 38 draws a fundamental distinction:

• Research Phase: Always expensed. No asset is recognized.

• Development Phase: Capitalization is mandatory if all six criteria are met:

1. Technical feasibility to complete

2. Intention to complete and use/sell

3. Ability to use or sell

4. Evidence of future economic benefits

5. Availability of adequate resources

6. Ability to reliably measure expenditure

D. The Hard Prohibition (Para 63)

Internally generated brands, mastheads, publishing titles, customer lists, and items similar in substance are strictly prohibited from capitalization. The standard argues these costs cannot be distinguished from the cost of developing the business as a whole.

E. Subsequent Measurement (Para 72–87)

Once recognized, companies choose between:

• Cost Model: Cost less accumulated amortization and impairment losses.

• Revaluation Model: Fair value at the date of revaluation, less subsequent amortization and impairment — but only if an active market exists for the asset.

F. Useful Life Classification (Para 88–106)

Note: For a deep dive into the mechanics of the Revaluation Model and the Impairment Test, please refer to my previous article

Revaluation Model : https://ifrs-labo.com/posts/ias-16-ppe-lifecycle-guide

Impairment Test : https://ifrs-labo.com/posts/ias-36-measurement-cgu-viu-ghost-ledgers

Retirements and Disclosures (Para 107–128) follow the same logic as IAS 16 — derecognize on disposal, recognize gain or loss, and disclose by class. No material divergence from general IFRS principles.

4. The New Paradigm: From Agile to AI

As a CPA and a Product Manager, I see a growing friction between the 1998 logic and 2026 reality. But the cracks appeared long before AI.

The First Fracture: Agile Development

IAS 38 was designed for a waterfall world. Requirements, design, build, test — sequential phases with clear boundaries. "Technical Feasibility" had an identifiable moment. The Research/Development line could, in theory, be drawn.

Agile broke that assumption. In a sprint-based workflow, design, development, and testing happen simultaneously. A single ticket can contain new feature work and bug fixes in the same commit. The question — is this sprint capitalizable development or maintenance expense? — became genuinely unanswerable without arbitrary judgment calls.

In practice, companies adopted one of three approaches: expense everything (conservative, defensible), allocate by ticket classification (burdensome, subjective), or capitalize by release milestone (pragmatic, but a departure from the standard's intent). None of these is clearly right. All of them are workarounds for a standard that assumed a development process that no longer existed.

The Second Fracture: AI and Vibe Coding

If Agile blurred the Research/Development boundary, AI has dissolved it. With tools like Cursor and Claude, "Technical Feasibility" (Para 57a) is often demonstrated within minutes of the first prompt. The capitalizable window — already hard to identify under Agile — now shrinks toward zero.

The cost structure has also inverted. Development is no longer dominated by external labor costs that are natural to track and capitalize. It is driven by AI tokens, subscriptions, and a founder's domain expertise — costs that are either too granular to track or impossible to separate from general business expenditure.

This is not a theoretical argument. In building a cloud consolidation platform that became one of Japan's fastest-growing products in its category, the most critical asset was never the code itself. It was the document that captured the intent behind the development: why we were building this, what problem we were solving, and what we were deliberately choosing not to build.

In a high-velocity development environment, formal requirements documents and specifications lose their meaning quickly. An outdated spec can actively obstruct progress. What endures — what actually governs the direction of the product — is a clear articulation of development intent.

That is what IAS 38 cannot measure. And that is what AI-era accounting will eventually need to confront.

The Self-Creation Paradox — An IFRS-OneQ Case Study

Consider IFRS-OneQ, my own app — launched just prior to the publication of this article. Software developed to generate revenue from external users can in principle qualify for capitalization under IAS 38, once all six development criteria are met (Para 57). In practice, however, two things make this impossible. First, in AI-driven development, the moment those criteria are satisfied is nearly impossible to identify in real time. Second, when the developer is also the founder, there are no external labor costs to measure — and without reliable measurement (Para 57f), there is no asset to recognize. A $20 monthly Cursor subscription, a few hours a week over three months: all period expenses. Even if the market comes to recognize the value of what has been built, IAS 38 Para 71 prohibits reinstating those costs as an asset. External validation changes nothing on the balance sheet.

Yet if I were to sell IFRS-OneQ to a third party tomorrow, the acquirer would recognize it on their balance sheet as an intangible asset at the acquisition price.

The same asset. Two accounting treatments. One standard.

This tension is not new — it is the most well-known criticism of IAS 38. But in the AI era, it is sharper than ever. When domain knowledge and a series of prompts can generate a production-ready app in weeks, what has value is not the cost of the code. It is the soul of the product vision that gives intent its direction — something IAS 38 was never built to measure.

5. The Standard Is Already Under Review

The friction described above is not going unnoticed. Following its Third Agenda Consultation in 2022, the IASB formally launched a comprehensive review of IAS 38 in April 2024 — rated by stakeholders as the highest-priority project. In May 2025, the board confirmed its objectives unanimously, with agile software development designated as one of the primary test cases for potential changes to the recognition criteria. A project direction decision is expected in H2 2026.

No amendments have been proposed or finalized. But the direction of travel is clear.

6. Conclusion: Designing a Standard for the Next Century

IAS 38 was a masterpiece for the Industrial Software era of the 90s. However, as we enter the AI era, the waterfall mindset of accounting is being disrupted.

The self-creation prohibition made sense when the boundary between "developing a product" and "developing the business" was genuinely blurry. In the age of AI, that boundary has not become clearer — it has collapsed entirely.

As a CPA and a Product Manager, I believe we are entering a phase where we must move beyond measuring the cost of code and start valuing the soul of the product vision. The next revision of IAS 38 will need to grapple with that reality — or risk becoming as obsolete as the waterfall it was designed to govern.

Sample Practice Questions

Question 1: Definition of an Intangible Asset

Problem:

Which of the following is NOT a required characteristic for an item to qualify as an intangible asset under IAS 38?

A. The asset must be identifiable — either separable or arising from contractual or legal rights.
B. The entity must have control over the asset and the ability to restrict others' access to its benefits.
C. The asset must have a reliably measurable fair market value at the reporting date.
D. The asset must be expected to generate probable future economic benefits for the entity.

Correct Answer: C

Explanation:

IAS 38 requires three criteria for recognition: identifiability, control, and future economic benefits (Para 8–17). A fair market value is not required — in fact, many intangible assets are recognized at cost precisely because no active market exists.

• The Revaluation Model (Para 75) does require fair value, but only as a subsequent measurement option, and even then only where an active market exists.

• Conflating "has a market value" with "qualifies as an intangible asset" is one of the most common misconceptions about IAS 38.

Question 2: Development Costs — Capitalization Policy

Problem:

A software company is developing a new product for external sale. Which of the following statements best describes the correct accounting treatment for development costs under IFRS?

A. Development costs must always be expensed as incurred — the same treatment applies regardless of which accounting framework the entity follows.
B. Development costs must be capitalized once all six recognition criteria are met, regardless of the company's accounting policy choice.
C. Development costs may be capitalized at the company's discretion once technical feasibility has been established.
D. Development costs are expensed during the research phase and may be optionally capitalized during the development phase.

Correct Answer: B

Explanation:

Under IAS 38 Para 57, capitalization of development costs is not optional — it is mandatory once all six criteria are met. This is a critical point that is frequently misunderstood.

• Option A is incorrect: while US GAAP (ASC 730) expenses substantially all R&D costs, IFRS takes a fundamentally different approach.

• Option C describes the US GAAP threshold for externally sold software (ASC 985-20), where Technical Feasibility is the sole gate — a narrower and different concept from IAS 38's six-criteria test.

• Option D is also incorrect: under IFRS, there is no optional treatment once all six criteria are satisfied.

Question 3: Internally Generated Intangibles — Customer List

Problem:

TechCo has internally developed a customer list over five years at a total cost of £50 million. An independent valuation firm has assessed its fair value at £200 million. TechCo is preparing its standalone financial statements under IFRS.

What amount should TechCo recognize on its balance sheet in respect of this customer list?

A. £200 million — at independently assessed fair value
B. £50 million — at historical cost of development
C. An amount between £50 million and £200 million, based on management's best estimate
D. Zero

Correct Answer: D

Explanation:

Under IAS 38 Para 63, internally generated customer lists are explicitly prohibited from recognition as intangible assets, regardless of their assessed fair value or the costs incurred in developing them. The standard takes the position that such costs cannot be reliably distinguished from the cost of developing the business as a whole. Neither the £200 million valuation nor the £50 million cost is relevant — the answer is zero.

However, one important nuance: if TechCo were acquired by another entity in a business combination, the acquiring entity would be required under IFRS 3 to recognize the customer list at its fair value at the acquisition date — potentially the full £200 million. The same asset. The same standard. Two entirely different outcomes depending solely on how ownership changed hands. This asymmetry between organic growth and acquisition is one of the most well-known criticisms of IAS 38, and is currently under active review by the IASB.

📲 Practice These Concepts in IFRS-OneQ

The questions from this article are available in IFRS-OneQ — our practice app for IFRS professionals and exam candidates.

👉 Try sample questions Available on Web and Android.

Disclaimer

This article is intended for educational and informational purposes only. It reflects the author's interpretation of IAS 38 as issued by the IASB and does not constitute professional accounting, audit, or legal advice. Standards may be subject to jurisdiction-specific interpretations, amendments, or transitional provisions. Readers should consult a qualified professional before making decisions based on this content. IFRS-LABO LLC accepts no liability for actions taken in reliance on the information presented here.