13 Oct 2017

R&D costs: why capital counts

Property

If research and development (R&D) are part of your work, especially in the tech and digital sector, you may be wondering whether you should capitalise R&D costs.

Under the new UK GAAP, strict criteria to write off research costs apply in the initial stages of development projects. In the case of established development projects of definitive feasibility, FRS 102 offers a choice to either write costs off as they are incurred, or capitalise and amortise them over the useful life of the asset.

This treatment is markedly different from that of IFRS: IAS 38 states that, when the relevant strict asset recognition criteria are met, development costs must be capitalised.

What are research costs?

Research is original and planned investigation, undertaken with the prospect of gaining new scientific or technical knowledge and understanding. An example could be a company in the software industry conducting research into a new product opportunity, cost and production timeline, such as a virtual reality or predictive chatbot application for sale to third parties.

In this example, staff research time would be a significant component of research costs, which would also typically include subcontract labour and consumables, all incurred for the purpose of facilitating the development of the application.

What are development costs?

Development is the application of research findings or other knowledge to a plan or design for the production of new or substantially improved materials, devices, products, processes, systems, or services, before the start of commercial production or use. An example is when development of the virtual reality or chatbot application begins.

Development costs would often include programmers’ time directly attributable to coding the software, an allocated amount of indirect costs (such as overheads related to programmers and the facilities they occupy), costs associated with alpha and beta testing, and other direct production costs that are incurred to bring the software to market.

Is the difference between research and development important?

Research does not directly lead to future economic benefits, and capitalising such costs does not comply with accounting standards. Therefore, the accounting treatment for all research expenditure is to write it off to the profit and loss account as incurred.

In terms of development expenditure, an entity may choose to either write the costs off to the P&L account, or subject to certain criteria being met (see the case study below), capitalise the costs, bringing them ‘on balance sheet’. Note that if an accounting policy of capitalisation is adopted, it should be applied consistently to all development projects that meet those criteria.

Case study: software developer

Consider a company developing software to eventually sell, lease or market to the general public.

This software is developed with the intention of earning future revenues and should not provide benefit to the internal operations of the company. A key question before considering whether these costs can be capitalised is: when did the software project achieve ‘definitive feasibility’?

Definitive feasibility is the point during a software project when the research phase has substantially been completed. The standards provide specific guidance as to when a project has achieved definitive feasibility. An example of one of the criteria in determining definitive feasibility is that project income is expected to outweigh cost; then it can be argued that these costs should be treated as development costs.

The development phase should cease when the software is available for general release to its customers. Any future costs relating to the software project should be expensed as incurred, unless they are ‘significant enhancements’ (which we’ll explain below).

Every development project should be reviewed at the end of every accounting period to ensure that the recognition criteria are still met. Where the conditions no longer exist or are doubtful, the capitalised costs should be written off to the P&L account immediately.

What are the practical difficulties?

Development costs are internally-generated intangible assets. Unlike a tangible business asset, such as a computer, you can’t see or touch an intangible asset, and accounting for these in practice requires some thought.

If you capitalise development costs, you must be able to support these capitalised costs with hard numbers, spreadsheets, and the logic behind it all. The process typically results in the need to track developers’ time hourly by project, as well as identifying project-specific costs such as software and subcontractors. If your company is capitalising development costs, you need to ensure you have suitable systems in place to identify and record the associated costs.

Where development costs are recognised as an asset, they should be amortised over the periods expected to benefit from them. Amortisation should begin only once commercial production has started or when the developed product or service comes into use. One of the many challenges a company faces when it capitalises development costs is what period this is written off over.

To do that, you will need to make some estimate of the period over which you expect to derive economic benefits from that asset. When making the determination, you should make sure whatever period you choose is consistent across a comparable class of assets. If, in exceptional cases, you are unable to make a reliable estimate of the useful life of the assets, the period shall not exceed 10 years as defined in paragraph 18.20 to FRS 102.

Your company must carefully reassess the useful life of such assets each period to ensure that the amortisation policy in force is appropriate.

A particular challenge for software companies capitalising development costs of their products is the treatment of enhancements such as new functionality. Each significant enhancement should be treated the same as the base product in that all costs prior to definitive feasibility are to be expensed; all costs post-definitive feasibility may be capitalised. Definitive feasibility is likely to be achieved earlier in the development process for significant enhancements; product enhancements are only eligible for capitalisation if they are deemed significant to the overall product itself (i.e. new functionality).

Capitalisation: what’s the impact on the numbers?

The treatment of development costs does not impact cash flow but it can dramatically change the company’s reported financial position. Capitalisation removes development costs from the P&L when incurred and spreads them out over the life of the product developed. Expensing development costs is going to increase a company’s costs and can, in the early phases of a company’s development of its product suite, quite possibly produce significant losses.

A company may have spent £10m developing new software for market which is then capitalised and amortised over its estimated useful economic life of 10 years. If you generated revenue of £5m in the current year, a profit of £4m would be recognised after taking into account £1m amortisation. By contrast, if the £10m had been expensed in the P&L, a loss of £5m would have been recognised.

The tax implications of the treatment of development costs also differ and need to be considered in detail. We explore this in a further article.

To capitalise or not to capitalise?

That is the question and it is not black and white.

Whether capitalising development costs makes sense depends on your business: you should consider the implications of the accounting policy adopted. Capitalisation can certainly improve a company’s reported financial position because it defers the expenditure over a longer period of time.

Why then do all software companies not do this? And why do some who’ve done it later change their minds? The answer is complex, but some recurring themes are:

  • Companies find identifying the actual development costs with future value difficult, especially in the early phases.
  • Technology moves at a rapid pace: often products have to be rebuilt regularly to comply to new protocols, so understanding what is held on the balance sheet can be difficult.
  • Tracking enhancements is challenging: often such projects are a mixture of support, bug fixes and added functionality.
  • Investors often add back any capitalisation to identify the ‘true’ financial position and cash being generated or expended.

The reality is that both approaches have pros and cons. Your company should fully explore each policy in the context of your business before deciding which method to adopt. BKL’s experience with tech and digital clients means we can help you reach that decision.

For more information, please get in touch with your usual BKL contact or use our enquiry form.