Software Implementation Services provided by Vendors to Customers (NZ IAS 38) (NZ IFRS 15)

The problem currently is that the different terms used by software providers and customers colloquially in practice such as “implementation”, “customisation”, “configuration”, “integration” etc.:

             (i)    Are not defined by NZ IFRS, 
             (ii)   Are used interchangeably in practice and within the software industry itself, and
             (iii)  Are not used consistently from entity-to-entity (and sometimes even within the same entity).

So, the first (positive) thing that the IFRIC decision does is to provide (unofficial) guidance and descriptions around this very specific area.

The key point here is that a Customer needs to know on quite a technical level what the implementation services are actually doing in the background, with the focus on “is code being added or modified?”.

This is not necessarily something that will be known by the Finance team, nor potentially something that can be easily determined by reviewing invoices from the Vendor (and even in some cases, review of the contract itself).

Accordingly, getting clarity over this typically requires discussions to be had with the entity’s own in-house IT department (that would have overseen the SaaS implementation), or failing that, the Vendor themselves

Also, given the description of configuration services above, these would generally be expected to be limited in nature and scope, and accordingly, limited in time and cost. Therefore, in situations where an entity has determined that it has significant configuration services, in may be that the entity has not correctly identified:

            (a)    Services that are actually (more involved) customisation services, and/or
            (b)    Other promised goods or services that have been provided in addition to configuration
                     services and customisation services (such additional goods or services that have
                     been executed within the customer’s own IT infrastructure environment, and/or involving
                     purchased or leased IT hardware).

 

The May 2021 edition of BDO’s Accounting Alert (click here) details the key aspects of the IFRIC decision.

The first question that the IFRIC decision looks at is whether the definition of an Intangible Asset is met which would facilitate costs associated with implementation services being able to be capitalised, noting that there are two criteria to be satisfied:

             (i)    That there is the power to obtain future economic benefits, and
             (ii)   That there is power to restrict others from having access to those same future economic
                     benefits.

It is here, particularly with respect to (ii), where entities have “gone wrong” in their previous determination that there is an Intangible Asset present to capitalise.

 

First assessment

The first thing to look at is whether the licensed software itself meets the definition of an Intangible asset.

If so, it is probably highly likely that any subsequent Implementation services would meet (i) and (ii) above.

Practicably this is likely to be the case if, and only if, the software in question is not off-the-shelf, or out-of-the-box software – that is, it is software that has been specifically built for a specific Customer.

However, even where this is the case, what would then need to be assessed is the rights around the intellectual property, IP, (i.e., the code) that has gone into building that software, and who has contractual rights (of use) to it.

If the Vendor retains IP rights to the software (and its code), then the Customer would typically be unable to demonstrate that (ii) has been met (i.e., the Vendor is not restricted from using the software code for the development of future software products for other potential customers).

If the IP is contractually protected for a period of time (i.e., the contract period), then it is arguable that the Customer satisfies (ii), but only for the period protected (which would then be the amortisation period of any Intangible asset recognised, unless the useful life of the software is shorter).

Assessing such IP protection would require specific analysis of the contract, as well as potential advice from legal experts regarding the legal and practical enforceability of such contractual clauses.

Second assessment

The second thing to look at is, even if the licensed software itself does not meet the definition of an Intangible asset (for the reasons above), whether the additional implementation services (most likely the customisation services) themselves meet the definition of an Intangible asset.

The analysis that needs to be done here is the same as in the First assessment above, being that an entity needs to consider and confirm whether the IP relating to the additional and/or modified code is contractual (and legally) protected, such that satisfaction of (ii) can be demonstrated.

Note that this Second assessment may still be necessary to consider even where the software itself does meet the definition of an Intangible asset (particularly if the contract is “silent” about specific aspects of the software build).

 

Treatment where costs are able to be capitalised as an Intangible Asset

Standard NZ IAS 38 accounting is applied, being that costs are capitalised and then amortised over the shorter of the licence period, IP protection period (if relevant), or the useful life of the software.

 

Treatment where costs are not able to be capitalised as an Intangible Asset

Again, this area was covered in some detail in the May 2021 edition of Accounting Alert (click here) with the below useful diagram:

The key point here is that even though there will be no Intangible Asset recognised, there may be instances where a Prepayment asset might be recognised (i.e., where amounts paid to the Vendor are in advance of the associated expense being recognised for accounting purposes).

The key difference between the three potential scenarios from the diagram above is the period over which the expense relating to the costs incurred for implementation services is spread, being:

• A shorter period (i.e., over the period that the services are provided) if the services are provided by:
      -    A third-party (i.e., different from the software Vendor), or
      -    The software Vendor, where the implementation services are “distinct” (see below)
   
• A longer period (i.e., over the licence “contract term”) if the services are provided by the software Vendor, where the implementation services are not “distinct”, i.e., “bundled” with the licence (see below).
  It should be noted that the “contract term” itself is a matter that can be “grey” in practice, in particular where the licence is an open-ended (perpetual) licence.
  Entities therefore need to consider which of the below guidance in NZ IFRS 15 is most appropriate in their particular situation:
      -    The period over which there are enforceable rights - were termination and renewal clause
           analysis becomes critical), or
      -    The likely period over which the Customer will access the software, based on substance
            (i.e., the use of the Customer’s unilateral rights to renew and/or terminate the licence).

Whether or not the implementation services are “distinct” requires an assessment of NZ IFRS 15 from the perspective of the software Vendor, with respect to identifying separate (“bundles” of) performance obligations.

These are explored further in section 3. below.

 

The guidance within the IFRIC decision makes reference to (and in doing so, provides additional application guidance, with respect to) the application of NZ IFRS 15 in terms of the Vendor-side of the transaction.

In particular, the identification and description of implementation services between configuration services and customisation services, provides clarity as to how:

             (i)    Implementation services (irrespective of what they may be referred to as in practice) may
                    need to be disaggregated and classified based on the nature of what is (or is not) happening,
                    with respect to adding and/or modifying the underlying code of the software, and then
             (ii)   How these classifications are assessed against the performance obligation separation
                     requirements of NZ IFRS 15 paragraph 29, to determine whether they are separate and
                     “distinct” performance obligations.
 

Separate and “distinct” performance obligations

Under NZ IFRS 15, individual promised goods or services are bundled together into a single performance obligation where:

             (a)    They are significantly integrated with each other, or
             (b)    They significantly modify or customise each other, or
             (c)    They are highly dependent or interrelated with each other.

The key qualitative feature to keep in mind is that in order for the above indicators to be met, there should be a transformative relationship between the individual promised goods and services in question (rather than merely a functional relationship).

Other key points for entities to remember when assessing separate “distinct” performance obligations:

 

Configuration services

             -    By their nature, as these services do not result in adding and/or modifying any of the software’s
                  underlying code, the relationship here is less transformative.

             -    It is thereof likely that these types of (less transformative) configuration services are less likely to
                  be “bundled” with the licenced software, and instead more likely to be considered (subject to
                  materiality) a separate, distinct performance obligation - i.e. separately identifiable from the
                  customer’s right to receive access to the vendor’s application software.
​

Customisation services

             -    By their nature, as these services do result in adding and/or modifying any of the software’s
                  underlying code, the relationship here is potentially more transformative.

-    However, consideration still needs to be given to exactly what the customisation is resulting in,
     and whether this demonstrates a (true) transformative change in HOW the software operates.

                  For example, customisations that simply change the background colour, font etc. are not
                  particularly transformative in nature.

     Whereas, customisations that modify existing applications or functionality within the software,
     and/or add on additional features and/or modules, are clearly more transformative in nature.
 

Accordingly, these clarified descriptions will now better equip Vendors of SaaS and other software licencing from determining the nature and quantum of the distinct (bundles of) performance obligations being provided

 

The IFRIC decision has directly resulted in questions being asked of the appropriateness of software-related Intangible assets currently recognised on the balance sheets of Customers of SaaS and other software licence arrangements.

Many of these entities are being required to undertake “deep dive”, retrospective assessments of the nature of past costs associated with implementation services that have been capitalised.

Indirectly, the IFRIC decision has refocused Vendors of SaaS and other software licence arrangements regarding the nature of their separate promised goods and services, and the make-up of their (bundles of) separate performance obligations to which revenue recognition accounting under NZ IFRS 15 is to be applied.

Accordingly, entities in either camp will need to make sure that they:

             (i)    Understand the nature of the IFRIC decision.
             (ii)   Confirm whether it is applicable to them.
             (iii)  If applicable, determine how the impact will need to be assessed.
             (iv)  Undertake the assessment.
             (v)   Make retrospective adjustments to financial statements for any changes in accounting
                    treatments required.

              As noted above, it may be that engagement with an entity’s internal IT department and/or the
             Vendor is required to undertake this assessment accurately.

For entities with 30 June 2021 reporting dates, the above needs to be undertaken for the preparation of your 30 June 2021 financial statements… so time is very much of the essence.

Customers and Vendors of significant SaaS and other software licence arrangements may need to engage the assistance of IFRS experts to assist with (or undertake) this assessment