Does ASC 842 apply to software?

Lucas Russell | 2021-06-10

The answer to that question is no. Software arrangements are not a lease because intangible assets are precluded from lease accounting.

But of course, it's not as simple as that. Some of these arrangements include both software and hardware components, and as usual, it comes down to the specific contractual arrangements. 

It's safe to say the use of software in running a company's operations will only become more common. Already, in 2021 software is moving into the realm of science fiction. Self-driving cars are one of the clearest examples of this. To procure software, a company can: 

  • Develop software internally
  • Contract third parties
  • Procure on-premise software from a vendor 
  • Procure Cloud-based software from a vendor

What can add to the complexity of accounting for these transactions is that software offerings continually evolve. For example, a company may procure software from a vendor to use a third-party developer to build a customizable dashboard.  

This article will cover the most common arrangement in which a company enters with a software vendor. As we explore the accounting, you will see ASC 842 is more than likely not the standard to apply. For example, if you were to use Cradle's lease accounting software to automate your compliance with ASC 842, that arrangement would not be a lease!

What standard should be applied to account for software

Lease - Topic 842

Could ASC 842 be the applicable standard to account for a software arrangement? As mentioned previously, that depends on the fact pattern of the contract. So to work through this, let's go through a typical software example that most companies will need to account for. 

Suppose Company Zip3 has entered into a contract where it pays a monthly subscription for payroll software. Paying this subscription allows Zip3 to log on via an online portal and facilitate the payment of their employees.

So is ASC 842 the suitable standard to apply to account for this transaction? 

The first thing to consider is, are there any exemptions to apply in the new lease accounting standard? The answer to that is yes ASC 842-010-15-1 states: 

This Topic does not apply to the following:

  • Leases of intangible assets (see Topic 350, Intangibles—Goodwill and Other).

Noting the above arrangement is a SaaS arrangement (software as a service) that includes access to an intangible asset with no hardware components, it's safe to conclude that the contract is specifically excluded from lease accounting under Topic ASC 842.

If you have no time to waste and want to know the accounting see the section “How to account for software arrangements”

What if Topic ASC 842 included software

So that’s that, the lease accounting standard is not applicable to this transaction. But for arguments sake, let’s ignore the exemption and explore if the above arrangement would be a lease. For example, under IFRS 16 you can lease an intangible asset. Also this might be a useful exercise to apply to any contract.

The next step would be to see if the arrangement meets the definition of a lease. ASC 842 defines a lease as: 

ASC 842-10-15-3 A contract is or contains a lease if the contract conveys the right to control the use of identified property, plant, or equipment (an identified asset) for a period of time in exchange for consideration. A period of time may be described in terms of the amount of use of an identified asset (for example, the number of production units that an item of equipment will be used to produce).  

So let’s break down each of those inputs to see if software would meet the definition of a lease under ASC 842.

Is there an identified asset

There are several inputs to help determine whether there is an identified asset in the lease. Which are the following:

Is the asset explicitly or implicitly specified in the contract?

The contract may explicitly identify an asset to be used, e.g., by serial number or description. But the asset could also be implicitly implied within the contract. 

Is the asset physically distinct?

An identified asset must be physically distinct. A physically distinct asset may be an entire asset or a portion of an asset. The asset must be able to be used independently. 

This can be complicated when certain assets can be used by more than one party. If various parties can use the asset, one party must have substantially all the capacity and benefits from using the asset to qualify it as a lease. We’ll get to more of that later.

Does the supplier/lessor have substantive right to substitute the asset throughout the period of use?

As per ASC 842-10-15-10 

Even if an asset is specified, a customer does not have the right to use an identified asset if the supplier has the substantive right to substitute the asset throughout the period of use. A supplier’s right to substitute an asset is substantive only if both of the following conditions exist:

a. The supplier has the practical ability to substitute alternative assets throughout the period of use (for example, the customer cannot prevent the supplier from substituting an asset, and alternative assets are readily available to the supplier or could be sourced by the supplier within a reasonable period of time).

b. The supplier would benefit economically from the exercise of its right to substitute the asset (that is, the economic benefits associated with substituting the asset are expected to exceed the costs associated with substituting the asset).

If these three criteria are met, the first stage of the lease definition under ASC 842 has been met. 

Example A

Company A enters into an arrangement to use a portion of a data center to store its customer information. The contract does not explicitly specify the equipment to be used to fulfill the contract. But the agreement does explicitly include specific restrictions on the equipment to be used. All data must be captured on individual servers reserved for that customer, and the servers cannot be substituted.  

Is this contract a lease? 

The asset is implicitly specified due to the contractual requirements, the asset being the servers are physically distinct and are contractually not permitted to be substituted. As a result, this contract is a lease.

Right to control the identified asset

To meet the definition of a lease, it needs to be determined whether there is right to control the identified asset. The guidance ASC 842 provides to determine this is the following:

ASC 842-10-15-4

To determine whether a contract conveys the right to control the use of an identified asset (see paragraphs 842-10-15-17 through 15-26) for a period of time, an entity shall assess whether, throughout the period of use, the customer has both of the following:

a. The right to obtain substantially all of the economic benefits from use of the identified asset (see paragraphs 842-10-15-17 through 15-19)

b. The right to direct the use of the identified asset (see paragraphs 842-10-15-20 through 15-26).

Substantially all is a judgement area, but most of the Big-4 firms will state 90% or more is substantially all. 

Example B

A solar farm enters into an arrangement to sell the energy produced and the renewable energy certificates to separate companies.

Which company has the right to obtain all the economic benefits of the solar farm substantially?

It depends on the total economics of the contract. If either benefit is deemed more than insignificant, neither party would have the right to option substantially all the benefits. The agreement would not meet the definition of a lease.

Would a software contract meet the definition of a lease?

Now we have gone through the criteria required to meet the definition of a lease under Topic 842, let's apply the above to a SaaS contract. 

842-10-15-9 - Is there an Identified asset?
Criteria to be met Explanation
Implicitly or explicitly stated No: For a typical SasS contract, there is no asset explicitly stated. One could potentially argue there is an asset implicitly stated with the right to use the software. However, ASC 842 is precluded for leases with intangible assets.
Physically distinct / majority of the total capacity No: The user is not privy to this information, furthermore given the software is “off the shelf”one can conclude it’s not physically distinct nor does the company have majority of the total capacity.
No substitution rights from lessor Yes: For the majority of software contracts, the lessor does have substitution rights. The lessor can make updates or changes to the software without the approval of the lessee.
842-10-15-17 - Does the lessee obtain substantially all of the economic benefits?
Criteria to be met Explanation
Customer has the right to substantially all of the economic benefits from use In this individual SaaS agreement from the user’s perspective, yes.
842-10-15-20 - Does the lessee direct the use?
Criteria to be met Explanation
The customer makes the ‘how and what purpose decisions’ then the contract is a lease No: The user of the software does not determine the functionality of the software. The user can only use the software for the purpose it’s been engineered for, in this case lease accounting software.

How to account for software arrangements

Of course, that firstly depends on the contractual terms of the software arrangement. There are two standards the accounting for a software contract is likely to fall under, and that is: 

  • ASC 985-20 - Accounting treatment of software development costs
  • ASC 350-40 - Internal-Use Software

For the majority of companies, it’s apparent what standard is applicable based when considering when ASC 985-20 is in scope: 

ASC 985-20-15-2 - Computer software to be sold, leased, or otherwise marketed as a separate product or as part of a product or process, whether internally developed and produced, or purchased.

This definition would only apply to a company looking to generate revenue with software. It’s a quick and easy way to cross ASC 985-20 off the list when figuring out what standard to apply to software costs. 

For most companies, the software will be used for internal use only, as a tool to help with running the business. As a result, ASC 350-40 would be more applicable as it defines internal use as: 

ASC 350-40-15-2

  1. The software is acquired, internally developed, or modified solely to meet the entity’s internal needs.
  2. During the software’s development or modification, no substantive plan exists or is being developed to market the software externally.

Noting the above, let’s deal with the potential software arrangements starting with the most common.

Software Is Purchased for Internal Use as Cloud-Based Arrangement

These arrangements are now more common than not and will only become more popular as technology advances.  Suppose a company uses Google's G Suite for email, Zoom for conference calls, Slack for chat messaging, and Salesforce for customer relationship management (CRM). All are examples of software purchased for internal use and are cloud-based arrangements.

Before cloud-based solutions, a company would host on-premise solutions. Accounting software is an excellent example of this. We still see these solutions on the market, but they do not offer a cloud solution's flexibility and cost benefits. As technology progresses, it will be less common to see on-premise hosted solutions.

So what is the appropriate accounting for the above scenarios? It comes down to if the arrangement is a software license or is a service arrangement.

ASC 350-40-15-4A through 15-4C defines a service arrangement as:

If the entity:

(1) does not have "the contractual right to take possession of the software at any time during the hosting period without significant penalty" or

(2) it is not "feasible for the [entity] to either run the software on its own hardware or contract with another party unrelated to the vendor to host the software" the entity has entered into a service contract

If those criteria are met, the company has a service arrangement, for majority of SaaS arrangements this criteria will be met. To account for a service contract is incredibly straightforward. Account for the expense when it meets the definition of a liability. There is no balance sheet impact.

Implementation costs 

With specific software arrangements, there can be implementation costs incurred when setting up the software. How should these costs be accounted for? 

That depends on the implementation cost. ASC 350-40 can apply to implementation costs incurred for cloud-based (or hosting), resulting in those costs being capitalized. The criteria for capitalization is if a company needs to purchase or develop internal-use software as part of the implementation to use the software. Some examples of this are: 

  • Costs for coding and testing, directly related to the software
  • Purchases of external materials directly related to the software
  • Third-party software development fees
  • Software and software license purchases

Some example of non-capitalizable costs are: 

  • Training fees 
  • Manual data conversion costs 
  • Maintenance and support costs

Capitalization criteria are pretty strict, and a company will essentially need to incur some additional bespoke costs when implementing the cloud-based software. For majorities of companies, the implementation fee incurred will not be applicable and will be expensed when incurred.

On-Premise

What about a software arrangement where the customer hosts the software on its hardware? As done previously, the first thing to do is determine if it is a software license or service arrangement. As stated by ASC 350-40-15A, a software license would meet the following criteria:

a. The customer has the contractual right to take possession of the software at any time during the hosting period without significant penalty.

b. It is feasible for the customer to either run the software on its own hardware or contract with another party unrelated to the vendor to host the software. 

If it meets this definition, it is a licensing agreement. This is also the same definition as ASC 985-20-15-5. The difference of applying Topic 985 is if the software is intended to be sold, which for our purposes it’s not. 

Initial Recognition and subsequent accounting

When the contact is in the scope of 350-40-15A, the company will:

  • Recognize a prepaid asset for those costs (refer above), which will be amortized over the asset’s life. 
  • Recognize a liability for the future payments owed
  • If there is a difference between the two values, it’s due to the payments made at the inception of the contract that will instantly reduce the liability value while the asset is amortized

It should also be noted it’s the costs specifically related to the on-premise software. The costs incurred to host the software will probably fall under the scope of a different standard under US GAAP. For example, if the entity purchases servers to provide the hosting service, it would account for those servers as long-lived assets under ASC 360.

Conclusion

This article has covered how to account for a software arrangement entered into with a vendor for internal use purposes. Firstly the contract is not going to be a lease given intangible assets are precluded from lease accounting.  

The article then covered the accounting for software contracts entered into for internal use. Majority of contracts are more than likely to be accounted for as service arrangements. This means no balance sheet recognition. Those contracts involving a license have a higher likelihood of meeting the definition of ASC 350-40-15-4A, resulting in those costs being capitalized on the balance sheet.

But the accounting for G-Suite, Zoom, or Cradle Accounting subscription will be expensed to the income statement.