Capitalising software cost means recognising it as an asset rather than expensing it as incurred. Two frameworks govern the question, they draw the line in different places, and neither draws it where the project changed its name.

What IAS 38 asks

Under IFRS, internal research expenditure is expensed. Development expenditure is recognised only where six things hold together: technical feasibility is demonstrable, the entity intends to complete, it is able to use or sell the result, probable future economic benefits exist, adequate resources are available to finish, and the directly attributable cost can be measured reliably. Where expenditure cannot be separated between research and development, it follows the research treatment.

The standard’s own examples of development include the design, construction, and testing of pre-use prototypes. So the word prototype does not push work into the research phase, and it does not by itself establish recognition either. The criteria carry the whole decision.

The costs that do not come back

Cost accumulation for an internally generated asset starts when the recognition criteria are met, and expenditure previously expensed is not reinstated as part of the asset’s cost.

Take an entity that expenses 30,000 while the criteria are unmet, then demonstrates them and incurs a further 12,000 of eligible directly attributable cost. It recognises 12,000. Not 42,000.

This is the mechanical consequence teams find surprising, and it has a behavioural edge: the longer the criteria stay unmet, the more of the project is permanently expensed. Meeting them earlier moves more cost onto the balance sheet, which is a real incentive acting on how projects are described and when they are said to have become feasible.

What US GAAP asks, and what is changing

ASC 350-40 governs internal-use software under US GAAP. The model most practitioners know distinguishes preliminary, application-development, and post-implementation activities, with cost eligibility attaching to the middle stage.

ASU 2025-06 removes those prescriptive stages. Recognition instead keys to funding authorisation together with probable completion and use as intended, with significant development uncertainty taken into account. The amendments are effective for annual periods beginning after 15 December 2027 and their interim periods, early adoption is permitted, and transition can be prospective, modified, or retrospective subject to stated conditions.

The practical consequence for the next two reporting cycles is that two comparable entities doing comparable work can be on different models, one having early-adopted and one not. A single undated stage checklist cannot explain both. Each entity records its policy, its adoption decision, and the applicable version before classifying anything.

Scope also does not follow from the word internal. The FASB’s basis for conclusions discusses both internally used software and software supporting externally provided services, and licensing and hosting facts matter to the analysis.

The boundary is dated evidence, not a rename

Four milestones get conflated, and each documents something different. Naming a project a prototype records the team’s description of its inquiry. A passing technical test records performance under the tested conditions. A production release records a deployment decision. Recipient acceptance records a transition of responsibility.

None of the four establishes an accounting classification of prior or future costs. Recognition rests on which criteria were satisfied, on what date, with what evidence.

That makes relabelling worth investigating in both directions. A sponsor calling a system production while its requirements are still changing has not moved the boundary. Equally, a project still called a prototype after a documented criterion assessment does not get the opposite treatment forced on it because the old name stuck. Compare the claimed milestone against the observed work before inferring anything about motive; genuine technical progress and a documented policy change are the competing explanations, and no prevalence of budget-driven renaming is established.

Inference charges are not a single item

A token-priced invoice is a pricing unit. Before any classification, separate what was obtained: calls consumed during operation, calls used in development and testing, prepaid access or usage balances with their expiry and refund terms, separately controlled code, and owned equipment.

The cloud-computing analysis is the relevant anchor for the first of these: access under a service arrangement is a service rather than a customer software asset, separately controlled code needs its own assessment, and an advance payment can create a prepayment. A non-refundable payment does not establish intangible-asset recognition on its own.

The rule

What stays fixed is that recognition follows evidenced criteria on dated facts. What changes is the framework, the entity’s adoption decision, and the version in force — and all three have to be recorded before the first cost is classified, because they determine which question is even being asked.

Not to be confused with

Budget approval. Management authorising funding is not the same act as satisfying a recognition criterion under either framework, and under IFRS it is one input among six.

Tax treatment. Financial reporting, budget approval, and tax relief are three separate analyses on the same expenditure. Research and development tax incentives have their own definitions and do not follow the accounting classification.

A measure of merit. Recognition is not a verdict on whether the investigation was worth doing. A failed recognition test says nothing about whether to continue the research.