As cloud computing becomes more common it is important to understand how to account for these arrangements.
At a glance
Software as a service (SaaS) is a way of delivering applications over the internet — as a service – rather than installing and maintaining software on a customer’s on-premises servers. SaaS applications are sometimes called cloud computing or web-based software. The SaaS vendor controls the underlying software and manages access to the application, determines upgrades and changes to the platform, and manages security, availability, and performance.
Access to the Supplier’s Software Hosted on the Cloud
In March 2019, the IFRS Interpretation Committee (IFRIC) issued an Agenda Decision Customer’s Right to Receive Access to the Supplier’s Software Hosted on the Cloud which describes how a customer should account for a SaaS cloud computing arrangement.
IFRIC concluded that a contract that conveys to the customer only the right to receive access to the supplier’s application software in the future is a service contract. The customer receives the service — the access to the software — over the contract term. The arrangement does not represent a lease of the software nor are the costs incurred to obtain a licence to access a supplier’s SaaS software capable of being recognised an intangible asset.
This does not preclude the recognition of a prepayment if an entity has prepaid fees to obtain future access to cloud-based software.
Configuration or Customisation (C&C) Costs in a Cloud Computing Arrangement
Companies often pay a fee to access a SaaS arrangement and incur additional costs to configure and/or customise those services to their own specific requirements.
Configuration involves the setting of various ‘flags’ or ‘switches’ within the application software, or defining values or parameters, to set up the software’s existing code to function in a specified way.
Customisation involves modifying the software code in the application or writing additional code. Customisation generally changes, or creates additional, functionalities within the software.
In April 2021 IFRIC issued Agenda Decision Configuration or Customisation Costs in a Cloud Computing Arrangement. IFRIC noted that where an entity does not control the software, and is not able to recognise an intangible asset in relation to the SaaS arrangement, any configuration or customisation activities of that software cannot be capitalised as an intangible asset unless those activities create a resource controlled by the entity that is separate from the SaaS software being configured.
A separate intangible asset may exist where the entity controls any additional software code which it has the power to obtain future economic benefits and to restrict others’ access to those benefits.
C&C Services performed by the SaaS provider or its agent
Where the SaaS vendor performs the configuration and customisation services, then the customer applies the principles in AASB 15 Revenue from Contracts with Customers to assess whether those activities form part of the service of receiving access to the software or are distinct from the SaaS service. The assessment of whether a good or service is distinct has two elements; the good or service must be both capable of being distinct and is a separately identifiable service within the contract.
Whether a C&C service is distinct does not determine whether it can be recognised as a separate intangible asset. Rather, it only affects the timing of the recognition of those costs as an expense.
If the customisation and configuration services could only be performed by the cloud vendor, then this indicates that those activities are not distinct from the access to the SaaS software (ie, it is not capable of being distinct). In this case, the related implementation costs are recognised as an expense over the SaaS contract term.
If the cloud vendor performs the configuration service, but a third party – eg, a consulting company – would be capable of performing the service without also providing the access to the software, then those services are capable of being distinct. Provided the configuration and customisation services are separately identifiable from other promises in the contract with the SaaS vendor, then the C&C service is also distinct in the context of the contract and the implementation service is distinct from the SaaS service. In that case, those configuration and customisation costs are expensed at the point in time the services are provided.
This results in two broad outcomes:
Example 1 – Services are distinct
Company C enters into a cloud computing arrangement with Supplier D to access to D’s software for a period of 12 months. D also agrees to configure the software for C for a fee of $1,000. Based on the terms of the arrangement, C determines that it has a service contract with D – ie, C does not control the software. How does C account for the configuration costs?
Although D performs the configuration services, C determines that the service is distinct from the access to the SaaS software because a third party other than D could configure the software without also having to provide access to it and the configuration services are separately identified in the contract. However, C’s expenditure does not give rise to a separate intangible asset because C does not control the configured software that it has access to. Therefore, C recognises an expense of $1,000 for the distinct configuration services as those services are received.
Example 2 – Services are not distinct
Company C enters into a cloud computing arrangement with Supplier D to access to D’s software for a period of 12 months. D also agrees to customise the software by writing additional code that will create new functionality to enable its software to integrate with C’s other software for an additional fee of $1,000. D retains the intellectual property rights to the customised software and can make this new functionality available to other customers. Based on the terms of the arrangement, C has a service contract with D – ie, C does not control the software. How does C account for the customisation costs?
Applying the requirements of paras 9-23 of AASB 138, Company C determines that it does not control the customised software and cannot recognise an intangible asset. C also determines that only D is capable of modifying its underlying software. C is able to derive its intended benefit from the software only through D fulfilling both the ongoing access to the software and the customisation service. Therefore, C concludes that the customisation services are not distinct from the SaaS and there is only one service in the contract – being the access to the customised software. C recognises an expense of $1,000 over the 12 month period of the cloud arrangement.
Whether C&C activities are distinct elements in SaaS arrangement will require an assessment of individual SaaS contacts and significant judgement.
C&C Services performed by the customer
If the configuration and customisation services are performed by the customer or by a third party other than the cloud vendor, those services are distinct from the SaaS software. An entity then needs to determine whether those distinct services meet the criteria in AASB 138 to be recognised as an intangible asset.
An intangible asset can only be recognised if it meets the definition of an intangible asset (paras 9-17) and the recognition criteria (paras 21-23) of AASB 138. Namely:
For internally generated intangible assets, an entity is only permitted to capitalise relevant costs during the development phase (refer AASB 138 paras 57-67). In order to recognise software as an intangible asset, it is critical that the entity controls the software being acquired or constructed.
There are limited circumstances in which a company can recognise a separate intangible asset in relation to a SaaS arrangement. For example, costs to create a new interface between a company’s existing software and the cloud software could create a separate intangible asset where the company writes and controls new software code and the other conditions in AASB 138 are met.
Where the entity configures a vendor’s SaaS application, it is unlikely that these activities will create an asset that meets the conditions in paras 9-23 of AASB 138. This is because configuring elements within the SaaS supplier’s software is unlikely to create an asset that is separate from the software.
Example 3 – Customisation services performed by the entity
Company E enters into a cloud computing arrangement with Supplier F to access to F’s software for a period of five years. Company E engages M, a third party supplier, to write new code that will enable E’s existing software to integrate with F’s cloud computing software for a fee of $1,000. The new software is separable from F’s cloud computing software and E’s agreement with M vests the intellectual property rights to the customised software code in Company E, which has the right to restrict the access of others to the economic benefits flowing from that software. How does E account for the customisation costs?
Company E controls a software intangible asset (the software code) that is separable from the cloud computing arrangement and from which it can obtain future benefits. E determines that the other elements of paras 9 -23 of AASB 138 are met and concludes that it is capable of capitalising the directly attributable costs of preparing the software for its intended use as an intangible asset. E amortises the intangible asset over its estimated useful life.
As a general rule of thumb:
Change in accounting treatments
Because IFRIC Agenda Decisions are authoritative interpretations of AASB 138, previous accounting treatments that were inconsistent with the Agenda Decisions must be adjusted, where material.
AASB 108 Accounting Policies, Changes in Accounting Estimates and Errors requires an entity to retrospectively correct its previous accounting by:
Paragraph 49 of AASB 108 describes the required disclosures relating to such adjustments.
Illustration of accounting for software development and cloud computing arrangements:
Article by Martin Olde