Research vs. development

IAS 38 draws a sharp line between two phases of creating an intangible asset. Research costs — the search for new knowledge, evaluation of alternatives and exploration of concepts — are always expensed and cannot be capitalised.

Development costs are the application of research findings to a plan for a specific product. If all six criteria are met, they can — and must — be capitalised.

The six capitalisation criteria

IAS 38 sets out conditions that must all be met simultaneously:

  • technical feasibility of completing the asset,
  • intention to complete and use or sell the asset,
  • ability to use or sell the asset,
  • demonstration of future economic benefits,
  • availability of resources to complete development,
  • ability to measure costs reliably.

How this looks for a typical SaaS

Imagine a team of 12 engineers working for four months on a new module of the platform. The first two weeks are prototyping and proof of concept — research. After that the actual feature development, testing and production release begin.

Costs for the first two weeks are expensed in the current period. The remaining 3.5 months — provided all six criteria are met — form an intangible asset. The starting point for capitalisation is usually the moment when the architecture is fixed and the team has an approved plan.

What to include in the cost

The cost of the intangible asset includes direct staff costs (engineer salaries, payroll taxes, bonuses, the relevant share of the option programme), third-party service fees directly attributable to the development, and a reasonable share of overheads that can be associated with development.

Excluded are: general administrative costs, marketing, staff training, costs of inefficiencies and losses incurred before planned performance is achieved.

Amortisation and useful life

Capitalised development is amortised from the date the asset is ready for use. For a SaaS this is usually the production release. Useful life is determined by reference to the technology cycle — for most products that means three to five years.

The method is normally straight-line. Useful life is reviewed at least at the end of each financial year: if the technology is becoming obsolete faster than expected, the useful life is shortened.

Impairment testing

If there are indicators that the asset generates less economic benefit than its carrying amount, an impairment test is performed under IAS 36. For intangible assets not yet in use, the test is mandatory annually regardless of indicators.

Typical impairment triggers for IT companies are product discontinuation, loss of key customers, migration to a new technology, or a sharp drop in the active user base.

Common mistakes in Ukrainian IT companies

There are several recurring issues in practice. First, attempting to capitalise everything, including the research phase. Second, missing time logs, which makes it impossible to justify how many hours a specific engineer spent on development.

Third, using tax useful lives rather than economic ones. Fourth, starting amortisation too late: the company keeps the asset "in development" for years and never amortises. Fifth, ignoring impairment for products that have effectively stopped evolving.