Capitalization of internal software development costs

Whether engineering spend is expensed as research or capitalized as development changes reported profitability and the balance sheet materially, and because agile development blurs the line between exploratory and committed work, an aggressive or inconsistent capitalization policy can flatter EBITDA in a way that misleads investors about the true cost of building the product.

At what point does the project pass from the research phase (expense as incurred) into the development phase where technical feasibility is demonstrable? Can management support all six IAS 38 capitalization criteria, including probable future economic benefit and reliable cost measurement, with contemporaneous evidence? Is engineering time tracked by project and phase with enough granularity to separate capitalizable development effort from ongoing maintenance or exploratory work?

1. Classify spend as research (expense as incurred) versus development (capitalize if criteria met) based on the nature of the activity, not the team or budget label.
2. Test all six IAS 38 criteria before capitalizing any cost: technical feasibility of completing the asset, intention to complete and use or sell it, ability to use or sell it, how it will generate probable future economic benefit (e.g., an identifiable market or internal use case), availability of adequate technical/financial/other resources to complete it, and ability to reliably measure the expenditure attributable to it.
3. Identify the specific point in time (not a broad period) all six criteria are first met, commonly after a proof-of-concept or feasibility study confirms the product will work technically and commercially.
4. Capitalize only expenditure incurred from that point forward; do not reinstate or capitalize retroactively costs already expensed before the criteria were met.
5. Maintain contemporaneous evidence (time-tracking by project/sprint, feasibility sign-off documentation) to support both the capitalization start date and the population of costs included.

Measure the capitalized asset at cost, including directly attributable expenditure necessary to create, produce and prepare the asset for its intended use (e.g., developer salaries and directly attributable overheads for the time spent after criteria are met), excluding selling, administrative and general overheads, and excluding identified inefficiencies or initial operating losses. Amortize over the asset's useful life once it is available for use (i.e., the product or feature is ready for its intended purpose), using a method reflecting the pattern of expected benefit; reassess useful life and amortization method at least annually.

Disclose: (1) the accounting policy distinguishing research from development expenditure and the criteria applied; (2) the amount of development costs capitalized during the period and the resulting carrying amount; (3) the amortization method and useful life used; (4) research and development expense recognized in profit or loss, and the line items where it sits; (5) any impairment losses on capitalized development costs.

• Capitalizing broad swaths of engineering payroll to boost reported EBITDA without evidence all six criteria were met at the claimed start date
• capitalizing routine maintenance, bug fixes, and minor enhancements that do not create a new or enhanced asset
• lacking time-tracking evidence to substantiate which hours relate to capitalizable development versus research or maintenance
• treating the whole of an agile sprint as capitalizable because '
• some development happened'
• without isolating research-stage exploratory work within the same sprint
• retroactively capitalizing costs incurred before feasibility was actually established.