On the Horizon: How SaaS Software Impacts Bank Accounting Practices

by Nick Smialek

In today’s inter-connected world, cloud-based software is fast becoming the new mode of business for most organizations, and banks are no exception. Often referred to as “Software as a Service” (SaaS), this software has had a significant impact on both our personal and business interactions. SaaS helps business offer such benefits as lower entry pricing for necessary services and the convenience of removing physical barriers of access for consumers, providing vital programs almost instantly with a click of a mouse.

While most of the attention on SaaS technology tends to be focused on how convenient and cost-effective they are, what is less often discussed is the potential impact they can have on a company’s financials. Unlike traditional or hosted software packages, SaaS and cloud-based applications are not seen as genuine software license purchases under the U.S. Generally Accepted Accounting Principles (GAAP). While there are exceptions, SaaS customers do not typically own the rights or license for the software they use. What this means is that SaaS does not qualify for the common capitalization treatment for software purchases under GAAP and is instead viewed as an expense.

Because of this, many software contracts may now ultimately be treated as service contracts, with periodic payments being expensed as incurred rather than capitalized, depreciated or amortized (much to the chagrin of managers who have grown accustomed to budgeting software as capital or intangible assets). While understanding this accounting change is important, careful consideration of its impact is critical as an improper classification could lead to higher administrative expenses or unused budgeted resources.

To help clarify how cloud-based software computing would be viewed under U.S. GAAP, the Financial Accounting Standards Board (FASB) created the Accounting Standard Update Number 2015-05 (ASU 2015-05), a rule that removes any requirements for acquired software licenses. Issued in 2015, the accounting standard went into effect for public companies after Dec. 15, 2015 with private companies following a year later on the same date.

ASU 2015-05 has now established conditions for cloud-based software arrangements to determine whether or not they qualify as internal-use software under ASC 350-40, which in-turn would require software be treated as intangible assets. When it comes to meeting the criteria for internal-use software, however, many cloud-based products and SaaS contracts may fall short of the FASB definition. In addition to the standard considerations, it also depends on whether or not there is a software license in the product’s “hosting arrangement,” which the ASU defines as any arrangement connected to the licensing of the software where the end user does not actually own it. Instead, these applications are hosted by third-party vendors and live on their hardware, with the customer accessing the product through an online portal.

So, how can you tell if a software contract contains a software license, and thus qualifies as an intangible asset? There are two quick, straight-forward questions that can help determine this.

Is it possible for the customer or another unrelated, third-party end user to run or host the software on their own separate hardware?

Does the customer have the contractual right to take possession of the software at any time during the hosting period without significant penalty?

If the answer to both questions is “Yes,” then the SaaS product agreement does contain a software license by FASB standards and qualifies for intangible asset treatment under US GAAP ASC 350-40. However, if the answer is “No,” to either question, it does not qualify and therefore must be treated as a service agreement rather than an asset, with all payments being recorded as incurred expenses. If not properly considered ahead of time, this can cause problems down the road, as something that was listed on the balance sheet as an asset can suddenly become an expense, and thus impact a bank’s capitalization strategy.

Another issue with these types of service contracts is that often, in addition to their standard fees, they can have significant, upfront costs associated with their implementation and customization. Because determining how these costs are treated from an accounting perspective is not always clear, FASB’s Emerging Issues Task Force (EITF) proposed a new ASU early in 2018 focusing exclusively on these arrangements. The ASU proposes that companies should capitalize these implementation costs and certain enhancements (such as customization) over the entirety of the contract period as part of their service contracts. These deferred implementation costs would then be expensed over the term of the overall hosting agreement, including not only the non-cancelable term but any renewal terms in the contract that are deemed reasonably certain.

Ultimately, this would provide companies with a clearer long-term view for their financial planning and budgeting when it comes to their software contracts and capital expenditures. While this latest ASU is currently pending final approval, the proposal has already received positive feedback.

SaaS or cloud-based software can be a powerful and attractive option for today’s banks. With the digital world continuing to redefine how business is done, their popularity will only continue to grow. Because of this, banks should pay close attention when it comes to planning or interpreting their cloud-based software contract arrangements, as it could be the difference between your assets staying put or vanishing in the cloud.

Nick Smialek is a CPA and senior audit manager at PKM, an Atlanta-based accounting and advisory firm serving public and private organizations in the financial services, insurance and technology industries.