Capitalized development: follow projects into amortization
Capitalized development can improve current earnings while creating future amortization or impairment risk. Follow individual project cohorts from the capitalization decision through readiness for use and later revenue evidence. The central question is whether the asset balance reflects supported future benefits or merely a growing pool of deferred costs.
Identify the recognition boundary
IAS 38 distinguishes research expenditure from development expenditure meeting recognition conditions. This article uses IFRS. US GAAP research and software rules differ, so an IFRS capitalization rate is not directly comparable with an American peer’s expense ratio. Bought technology also has a different origin from internally generated development.
Locate management’s capitalization criteria and the date each material project first meets them. Technical feasibility alone does not establish all required conditions. Evidence about completion intent, resources, use or sale, future benefits and reliable cost measurement matters. Costs previously expensed should not quietly reappear as an asset when a project later looks promising.
Hypothetical project cohort
A software business spends 60 million on research and development. It expenses 35 and capitalizes 25. Existing development assets amortize by 12 and an abandoned project incurs impairment of 3. Ignoring other movements, the development asset grows by 10 and current operating profit includes 50 of expense: 35 + 12 + 3.
For a consistently all-expensed analytical history, current development expense would be 60 rather than 50: add the 25 current capitalization and remove the 12 amortization and 3 impairment on historical development assets that would never have existed. Label that counterfactual adjustment rather than a correction to compliant accounting. It is not a cash-flow calculation.
Assume 15 of the new capitalization relates to a product not yet ready for use, while 10 becomes available in October. A full-year amortization assumption for all 25 would be wrong. The start date, useful life and impairment assessment must follow each cohort’s circumstances.
Build a project ledger
Create fields for project, research phase spending, capitalization start date, capitalized additions, ready-for-use date, useful life, amortization, impairment, closing carrying amount and related operating evidence. Add whether amounts include payroll, contractor costs or acquired technology.
Reconcile the sum of project balances to the intangible-asset note. If the issuer only provides aggregate figures, keep the project-level ledger partially blank and explain what cannot be tested. Do not distribute totals across products using marketing prominence or development headcount without evidence supporting that allocation.
Look for cohort outcomes
Observe launches, customer adoption and later revenue or cost savings associated with the asset. A successful launch does not prove the entire carrying amount is recoverable, but repeated delays can challenge earlier completion and benefit assumptions. Compare the age of work in progress with the firm’s development cycle.
Check whether useful lives lengthen while new capitalization rises. The combination can defer more expense, although it may be justified by longer product utility. Ask for the underlying evidence rather than treating the accounting choice as misconduct. A reasonable research conclusion can be that earnings comparability is limited because cohort data are missing.
FAQ
Is a higher capitalization rate always aggressive?
No. Project maturity, acquisition mix and accounting framework affect the rate. Inspect the criteria and later project outcomes. A stable percentage can still hide weak assets, while a rising percentage can reflect projects legitimately reaching the development stage.
Should amortization be added back to evaluate cash spending?
Only as part of a complete reconciliation that also deducts current cash development spending where relevant. Adding back amortization while ignoring replacement development costs can overstate the economics of a software business.