No Match Found
The March 2021 IFRS IC update included an agenda decision on Configuration and Customisation (‘CC’) costs in a Cloud Computing Arrangement.
The agenda decision includes steps which entities should consider in accounting for such CC costs. The key areas of consideration are as follows:
This will impact entities that incur CC costs associated with a Software as a Service (SaaS) cloud arrangement, and might result in a change in accounting policy. Entities should ensure they dedicate sufficient resources to obtain the historical information about their current and previous SaaS arrangements to implement any change in accounting policy appropriately and on a timely basis.
Cloud computing is a model for delivering information technology services through web-based tools and applications. Cloud services usually fall into one of three service models: infrastructure, platform and software. This publication focuses on Software as a Service (SaaS).
In such contracts the customer generally does not obtain a software licence or have a right to take possession of the software. The contract conveys to the customer the right to receive access to the supplier’s application software over the contract term. That right to receive access does not provide the customer with a software asset and, therefore, the access to the software is a service that the customer receives over the contract term. The software typically remains on the seller’s hardware, and the buyer would only access the software via an internet connection.
The IFRS IC issued an agenda decision on the treatment of SaaS arrangements in March 2019. The March 2019 agenda decision considered the accounting for SaaS arrangements as a whole. It indicates when an arrangement would likely be accounted for as a service (which is often the case for cloud computing if the entity does not obtain a right to take possession of the software) versus when it could be an intangible asset or a lease. In the latest agenda decision the IFRS IC has focused solely on the treatment of CC costs. This In Depth therefore focuses on only the accounting for CC costs of such arrangements.
What are CC costs in a Cloud Computing Arrangement?
Many entities will pay a fee for the SaaS arrangement and an additional amount to configure and/or customise those services to their own specific requirements in advance of receiving the services. For example, an entity might have a SaaS arrangement for a human resources system but want to customise it to create additional reporting functionalities. As part of the discussion papers which led to the agenda decision the IASB staff defined CC costs as follows:
(i) Configuration: Typical configuration relates to the setting of various ‘flags’ or ‘switches’ within the software, or defining certain values or parameters, to implement a particular set-up for the software’s existing functionality. Configuration does not involve the modification or writing of additional software code, but rather involves setting up the software’s existing code to function in a particular way for the entity’s benefit.
(ii) Customisation: Typical customisation involves modifying existing software code in the application or writing additional code. The effect of significantly altering or adding software code is generally to change, or create additional, functionalities within the software so that it can provide the intended benefits.
The CC might be performed by the customer themselves, the SaaS provider, or a third party and is often a substantial cost in relation to the total cost of the SaaS arrangement.
This publication covers how to account for these CC costs and if they should be capitalised as an intangible asset or a prepayment in the statement of financial position, or if they are required to be expensed when incurred. There could be a variety of other costs which are incurred as part of the arrangement. An entity will continue to make their usual judgements about how to treat those other costs, for example, development of bridging modules that connect or integrate the SaaS software with existing software/systems controlled by the entity. This publication does not apply to these other costs.
An intangible asset is defined as ‘an identifiable non-monetary asset without physical substance’. An asset is a resource controlled by an entity. An entity controls an asset if it has the power to obtain the future economic benefits from an underlying resource and to restrict the access of others to those benefits.
The Committee observed that, in the SaaS arrangement described in the request, the customer often would not recognise an intangible asset because it does not control the software being configured or customised and those activities do not create an asset that is separate from the software. In some circumstances however, the arrangement may result in, for example, additional code from which the customer has the power to obtain the future economic benefits and to restrict others’ access to those benefits. In that case, the customer assesses whether the additional code is identifiable and meets the recognition criteria in IAS 38 to recognise the additional code as an intangible asset.
If the definition of an intangible asset is met and the SaaS provider or a third party carries out the CC, the intangible asset is not an internally generated intangible asset and qualifies for recognition as a separately acquired intangible asset.
Where an entity carries out the CC themselves and the definition of an intangible asset is met, an assessment about whether costs incurred meet the criteria for capitalisation is required. There are specific criteria which should be met before these costs can be capitalised, the criteria are set out in IAS 38.57 as follows:
‘An intangible asset arising from development (or from the development phase of an internal project) shall be recognised if, and only if, an entity can demonstrate all of the following:
PwC practical insight
The implementation of a SaaS system is often complex and there are a variety of costs that could be incurred. Judgement will be required to determine if the definition in IAS 38 paras 8-17 is met for some of these costs. The IFRS IC noted that, in the SaaS arrangement described in the request, the customer often would not recognise an intangible asset related to the activities defined in the submission as CC activities. This is because the entity does not control the software being configured or customised and the CC activities do not create a resource controlled by the customer that is separate from the software.
SaaS arrangements might be configured or customised by the SaaS recipient themselves, and costs incurred in relation to the CC and other setup costs would be included within eligible costs for capitalisation if the IAS 38 par 57 criteria are met. Entities should consider if these costs result in an internally generated intangible asset and meet the capitalisation criteria (IAS 38 para 57) like any other R&D project.
There are many costs incurred in relation to SaaS agreements and many of these costs are not CC costs as defined in the agenda decision. An entity will need to identify the nature of all costs incurred and apply judgment to determine whether it is appropriate to apply the guidance in the agenda decision or use other guidance to assess whether costs should be capitalised.
Example 1 - Costs incurred to migrate to a cloud based IT infrastructure model
A reporting entity that was previously using an ‘on premise’ software model has switched over to a SaaS model during the current year. In implementing this change the entity has incurred setup costs of CU105 in the current period. These costs are not part of the annual service fee, rather they were incurred in the current period to set up the new SaaS operating model. The entity has assessed the costs as summarised below:
CU 5 for data cleansing and transfer
CU 5 for training of employees
CU 45 for the configuration of the SaaS software, i.e. setting of flags and switches and setting the parameters of the software
CU 50 for the interface between the various ERP tools, portal and reporting capabilities (these are bespoke to the entity and the entity controls this software). The entity develops these on its own.
What is the accounting treatment of the CU105 in costs incurred during the current period?
The CU5 incurred on data cleansing and transfer does not create a resource for which the entity will receive economic benefits. This is because the data already existed and is not being enhanced in any way. The entity is only incurring this cost to retain the data so that it is available in its new system. Therefore, the costs to transfer the data do not meet the definition of an intangible asset and would be expensed as they are incurred.
The CU5 in training costs are indistinguishable from the costs of developing the business as a whole and should be expensed as they are incurred. [IAS 38 paras 15, 69]
For the CU45 incurred on the configuration of the SaaS agreement the entity would not recognise an intangible asset because it does not control the software being configured and those configuration activities do not create a resource controlled by the entity that is separate from the software. However these costs might be eligible for capitalisation as a prepayment (refer to questions 2 and 3 below for the detailed discussion on prepayments) if they are paid in advance of the related service being rendered.
For the CU50 incurred on the creation of the interface, the entity has created an asset that it controls that is a resource from which it expects to derive future economic benefits. This asset is separately identifiable and since it is controlled by the entity, the definition of an intangible asset is met [IAS 38 paras 8, 11 and 12]. The entity would consider whether the criteria for development costs are met [IAS 38 para 57]. If these criteria are met, the entity would capitalise the CU50 as an intangible asset and amortise it over its useful life.
If an entity has concluded that the costs do not meet the definition of an intangible asset, they should assess whether the costs can be capitalised as a prepayment or must be expensed as incurred. IAS 38 requires an entity to expense the cost of a service when it is received. A service is received when it is performed by the supplier in accordance with a contract and not when the entity uses the service.
IAS 38 does not provide any guidance on what ‘performed by the supplier’ means nor does it provide guidance around the identification of services received from a supplier. The IFRS IC suggested entities should look to the criteria in IFRS 15 Revenue from Contracts with Customers to determine the nature of the services which might impact when they are performed by the supplier. An entity should understand who is performing that service (a third party or the SaaS provider) and whether the service is distinct from the SaaS performance obligation following the criteria in IFRS 15 to conclude when the service is performed.
To determine whether the CC services are distinct from the SaaS arrangement an entity should look to the criteria in IFRS 15. The customisation cost would be recognised over the period of the customisation when the promises are distinct. The customisation costs would be recognised as a prepayment and spread over the entire SaaS arrangement if the promises are not distinct. In some cases making this determination might be challenging because the criteria in IFRS 15 were developed with revenue recognition in mind, rather than cost capitalisation from the customer’s perspective.
Per IFRS 15, a good or service that is promised to a customer is distinct if:
Therefore, the assessment of whether a good or service is distinct has two elements; the good or service must be both: (a) capable of being distinct; and (b) separately identifiable. [IFRS 15 para 27]
If the CC risk and SaaS service risk are not distinct, then the entity would conclude that it has not yet received the service related to the payment made for the CC. As a result, the payment for the CC would be a prepayment related to the combined SaaS arrangement. This prepayment would be recognised as an expense when the combined goods or services are provided under the SaaS arrangement.
Example 2 - Customisation of the SaaS source code inseparable from SaaS
A customer in the banking industry implements a SaaS arrangement to facilitate interactions between bank advisors and its customers. Since the current platform does not cover all regulatory requirements, it was agreed there was a need to customise the base solution and to include certain functionalities by intervening in the source code such as:
The activities listed above are carried out by the SaaS provider and the customer pays for these costs upfront.
Question: Can the entity capitalise the customisation costs?
The customer concludes that the CC and SaaS services are not distinct because the CC significantly modifies the services that will be provided. The risks are inseparable because the SaaS service cannot be provided without the modification to satisfy the regulatory requirements.
CC cost should be capitalised as a prepayment and amortised over the SaaS contract period.
The SaaS provider or another third party supplier might provide the CC services. The IFRS IC concluded that if a third party supplier performs the CC, those costs would typically be expensed as incurred. This is because when considering IFRS 15 to determine the nature and satisfaction of the services, it is likely the third party would be considered to have performed when the third party completes the tasks per the contract. However, the IFRS IC also discussed whether it would be appropriate to consider whether the third party is in substance a subcontractor of the SAAS provider and therefore the services should be considered as being provided by a single party for the purposes of assessment under IFRS 15.
Whether a third party is in substance a subcontractor is likely to involve the exercise of significant judgement
In considering whether a third party may be in substance a subcontractor of the SaaS provider, an entity might consider, among other things, the following factors (this list is not exhaustive or determinative):
If the third party is considered an in substance subcontractor of the SaaS provider, then the entity would next need to assess whether the CC services are distinct from the SaaS agreement as explained in question 2 above.
Example 3a - Third party - subcontractor
An entity is implementing a new SaaS arrangement for their HR function. As part of the arrangement the entity needs to incur substantial CC in advance of the SaaS being provided. A third party provides the CC. The SaaS provider is required to approve the third party’s work before starting to satisfy the SaaS performance obligation to ensure the SaaS service will operate as intended, and is responsible if further changes are needed to provide the SaaS service.
Question: Is the third party acting as a subcontractor for the SaaS provider?
The SaaS provider is required to approve the third party’s work before starting to satisfy the SaaS performance obligation and is responsible for the sufficiency of the work performed. Therefore, the entity is likely to conclude that the third party is in substance a subcontractor of the SaaS provider.
Example 3b - Third party - not a subcontractor
An entity is implementing a new SaaS arrangement for their HR function. As part of the arrangement, the entity needs to incur substantial CC costs in advance of the SaaS being provided. A third party provides the CC. The contract for the CC is between the third party and the entity, with no involvement by the SaaS provider. If there are issues providing the SaaS service as a result of the CC, the third party is responsible for addressing those issues to the satisfaction of the entity.
Question: Is the third party acting as a subcontractor for the SaaS provider?
The SaaS provider is not a party to the contract between the third party and the entity, and is not responsible for resolution of any issues regarding the CC service. As a result, the entity would likely determine that the third party is not acting in substance as a subcontractor of the SaaS provider, but rather as a vendor to the entity.
The agenda decision has no formal effective date. The IFRS IC has noted that agenda decisions might often result in explanatory material that was not previously available, which might cause an entity to change an accounting policy. The IASB expects that an entity would be entitled to sufficient time to make that determination and to implement any change. Any change to the amounts recognised in the financial statements should be applied retrospectively, therefore comparative amounts might also need to be restated. Any material change in the financial statements as a result of entities reconsidering their accounting should be disclosed in a transparent way and comply with IAS 8.
PwC Practical Insight
This agenda decision might require an entity to re-evaluate the accounting for configuration and customisation costs incurred in previous reporting periods, in particular if they were capitalised. Agenda decisions often provide explanatory material which can result in voluntary accounting policy changes in accordance with IAS 8 as they arise from ‘new information’. Voluntary changes in accounting policies are applied retrospectively unless impracticable. Agenda decisions are effective immediately; an entity would be entitled to sufficient time to assess and implement any change. Practically, while it might be expected that a 31 December 2021 reporter would have sufficient time to analyse the IFRIC decision, it may not be able to do so for the 30 June 2021 financial report. Disclosure in the June 2021 financial report explaining their process and timing of any expected change should be made if this is a significant policy.
Comparison to recent US GAAP guidance on customisation / configuration costs
On 29 August, 2018, the FASB issued new guidance on a customer's accounting for implementation, set-up and other upfront costs incurred in a Cloud Computing Arrangement hosted by the vendor—that is, a service contract. Under the new US GAAP guidance, a customer will apply the same criteria for capitalising implementation costs of a Cloud Computing Arrangement as it would for an on-premises software license.
Capitalization requirements for Cloud Computing Arrangement implementation costs are aligned with ASC 350-40 internal-use software guidance.
The US GAAP guidance clarifies that implementation costs, including Cloud Computing Arrangements that do not transfer a software license, may qualify for capitalisation based on the phase and nature of the costs.
US GAAP also has specific guidance regarding the impairment of any cloud computing costs that have been capitalised. There are also multiple disclosures required under US GAAP that could differ from those required by IFRS.
Difference between IFRS and US GAAP
It should be noted that the requirements of IFRS and US GAAP differ for cloud computing arrangements. US GAAP favours an approach which more easily permits the capitalisation of configuration or customization costs relative to IFRS.
Director and Leader Accounting Consulting Services, PwC Switzerland
Tel: +41 58 792 26 54