Did you know that IAS 38 Intangible Assets is almost half a century old? In fact, the first exposure draft dates all the way back to 1977. So, if you think that the first portable computer was only produced in 1981, you can get an idea of just how old it is and how different technology was at that time.
In the Digital Era where intangible assets are a company’s lifeblood, the standard can end up being less suited to deal with modern technologies and its application can sometimes present a challenge for companies.
Future economic benefits – what’s the deal?
Imagine an entity internally develops an additional module within its ERP to comply with GDPR requirements. Does the module meet the general recognition criteria of IAS 38.21 (i.e. the ability to generate future economic benefits to the entity)? And, if so, does it qualify as subsequent expenditure or a separate intangible?
When it comes to future economic benefits, we are led to believe that they will be in the form of generating revenues or reducing costs. IAS 38.57(d), however, states that if the intangible is to be used internally, the ability to generate benefits can be demonstrated by the usefulness of the asset to the company.
In the development phase of an internal project (the GDPR module in this case), an entity can, in some instances, identify an intangible asset and demonstrate that the asset will generate probable future economic benefits.
In line with IAS 38.60, to demonstrate how an intangible asset will generate probable future economic benefits, an entity will assess the future economic benefits to be received from the asset using the principles in IAS 36 Impairment of Assets. Therefore, if the asset will only generate economic benefits in combination with other assets, the entity applies the concept of cash-generating units in IAS 36. In other words, the asset is considered to generate independent cash inflows together with other assets.
Applying the standard to a GDPR software module, its usefulness lies in the fact that the entity would not be able to operate without it, as this would result in non-compliance with EU law.
The ‘unit of account’ factor
Seems pretty straightforward so far… However, things get more complicated when it comes to determining if the expenses incurred to develop the module will be capitalized as a separate intangible asset or as an addition to the existing software.
When IAS 38 was initially written, the nature of the intangible asset existing at that moment was such that, in most cases, there were no additions to such assets or replacements of part of it (IAS 38.20). Indeed, most subsequent expenditure are likely to just maintain the expected future economic benefits in an existing intangible asset (and as such shall be expensed as incurred) rather than meet the definition of an intangible asset and related general recognition criteria under IAS 38.18.
Nowadays, on the other hand, it is not that uncommon for companies to develop a software for internal use and then add additional features. A GDPR module is just one example among many other modules which could be added to existing software. In these cases, subsequent expenditure incurred can be directly attributed to the newly-developed asset with the aim of extending the capacity of the software by adding additional features.
The standard doesn’t provide specific guidance on when subsequent expenditures will be recognized as a separate intangible. Therefore, we need to refer back to the unit of account’ concept.
A unit of account is selected for an asset or liability by evaluating how recognition criteria and measurement concepts will apply to that asset or liability and to the related income and expenses. In some circumstances, it may even be appropriate to select one unit of account for recognition and a different unit of account for measurement (CF 4.49). Therefore, an entity shall select a unit of account that provides relevant information about the asset or liability and a faithful representation of the substance of the transaction that has generated it.
As often happens when dealing with IFRS standards, the choice will eventually be a judgment call based on specific facts and circumstances.