Making Sense of The "Cloudy" Capitalization Rules

Introduction

Many of my fellow IT Executives started their careers in other fields and vocations.  I am no exception to that career trajectory as I got my start in accounting and switched to technology twenty-five years ago. I find in these recent days, my foundation as an IT executive who is also a CPA is essential when trying to understand how to manage both operational and capital costs and financial planning. Especially these days as technology is changing rapidly causing large holes in interpretation by the accountants. The flurry of the latest pronouncements by the FASB is trying to help but at times only adding to the confusion. 

This article will provide some lessons learned and tips for IT leaders responsible for their organizations' cloud transitions of non-licensed, internal-use software. We as managers are tasked with coordinating not just the technical change but also how to account it. Being responsible for the capital and operating expenses surrounding the implementation of the new platforms requires us to know the rules. The costs for the cloud in their nature for non-licensed, internal-use software are fraught with challenges in proper separation, identification, categorization, and a misstep that can be catastrophic in the success of the implementation as it relates to financial planning.  So, with as little accounting jargon as possible, I will focus on some tips on managing unlicensed cloud internal use software deployments to align with the latest accounting rules.  Since each IT Leader has different circumstances, you should consult your own finance teams to confirm the best practices that fit your organization. The tips I provide should provide some clarity of what is going on in layperson terms as well as identify a huge gap in assignable cloud costs used during implementation that should qualify for capital treatment.

Overview of Capitalization Rules for Internal Use Software

In the past, identifying the various elements of capitalization rules for internal use software was relatively cut and dried. Hardware, software, and services were clearly identifiable. During the Y2K push there needed to be standards around how to account for internal-use software and rules were created in 1998. Under the practices outlined in Statement of Position 98-1 'Account for the Costs of Computer Software Developed or Obtained for Internal Use’ (AICPA, 1998), which guided both finance and IT professionals, identified the types of capitalizable costs in a relatively straight forward way. In those days, the purchase of the software, servers, hardware, and labor defined to phases of the project deployment served as the means to efficiently plan, associate costs, and provide guiding principles for accountants and operators.

Time marches on and with the introduction of cloud services, platforms for technology transitioned to the cloud for Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS), and Software-as-a-Service (SaaS). The old principles of in house 1998 accounting rules no longer fit cleanly in the new architecture. Just as IT professionals had to manage the new frontier of technology, their internal and external accountants were left trying to determine which rules to use when capital planning and execution commenced during these deployments. There were no longer servers purchased, but these cloud arrangements operated closer to lease or rentals of services. 

The accounting authorities needed to catch up on the architectural realities most IT operators faced. In turn, there were relevant pronouncements from the Financial Accounting Standards Board (FASB) to clarify the circumstances when cloud computing for internal use software could capitalize on individual costs. ASU 2015-05 in 2015 and ASU 2018-15, which became active in this current year. This new ASU also impacts how the cloud costs are presented in the financial statements with IT Leaders needing to provide a breakout of costs, the type of cloud spend in greater detail. This breakout impacts the balance sheet, income statement, and statement of cash flows presentment of cloud expenditures along with disclosure requirements for implementation costs. This means an increased collaboration need for IT Leaders to partner with finance when setting up the programs and monitoring mechanisms. So, the need for IT to identify, segment, track, measure, and monitor both the individual components of the cloud and cloud activities are rapidly growing.

In fulfilling the requirements for segmenting the capital activities, the implementation phases will continue to guide you as a general rule in terms of the activities that are eligible for capitalization treatment. The preliminary stages that involved planning activities, relevant project management tasks related to planning, and the analysis phases of the project are expense activities. Only the stages of design, coding, development, and pre-deployment are capitalizable with the noted exceptions, such as conversion and training, which are expense activities. Any post-implementation activities are also expenses. There are other qualifiers, but these general rules are most comfortable to digest in terms of aligning the plans to the events of the cloud move.

The simplified phases of implementation of internal-use software to the cloud:

‘Cloudy Areas’ in Assigning Capitalizable Costs Internal Use Software in the Cloud

At a cursory glance, the new rules look like the old rules for assigning the costs during the phases of the project and associating the capitalizable activities against the cost outlays of technology, software, and labor. The cloud adds a wrinkle first in evaluating if the cloud agreement has an internal-use software license or just the cloud computing arrangement (CCA), which operates in simple terms, like a lease. In both cases, the phases of when to recognize the costs incurred in the implementation use the traditional rules of software deployment. However, the gray areas arise in which costs associated with the cloud itself can be eligible for capitalization treatment.

The largest gap in the ASU and interpretations by accountants who have written interpretive papers lies in the handling of non-production cloud components which are implementation identifiable within CCA agreements. This vagueness creates confusion and consternation for those trying to manage the costs. An example of this ambiguity can lie directly in the cloud agreement itself. Overall, cloud agreements that are software use CCA (non-license) arrangements are operating expenses. Yet, some elements of that agreement may require you to expand the deal to allow for development and deployment, which are separable and identifiable as candidates for capitalization. The accounting pronouncements are unusually muddy around this area of handling the deployment costs in the cloud for clearly identified elements used only during the application development phases.  

Simple SaaS arrangements, which include the purchase of the production, a 'sandbox', and development instances of the product, provide an example of the challenge. These additional instances used for development activities can, and should, generate capitalizable items. Instance-management often requires the flex up of these non-production instances to help design, code, and test before deployment. In this case, the accounting pronouncement assigns and 'runs the meter' for operating expense on the production instance as prescribed while taking the view this is a lease even during non-production time as you 'leasehold improve' the core application. Thus, the production instance of SaaS is an operating expense. What of the non-production instances that only exist for the design, build, test, and deploy phases?

There are no official specific positions on assignable capitalizable costs incurred in the cloud, nor for the identifiable elements such as additional instances, virtual instances. The pronouncements focus on some costs and the phases that capitalizable activities can occur. Researching the topics, the ASU 2018-15 and Subtopic 350-40 (AICPA, 2018) overall mentions just the theory that the costs around the cloud production instance are an expense. The pronouncement is silent on directly addressing direct CCA cloud costs within the cloud agreement that should be 'apportioned' and 'separable' to the development, code, and deploy phases of the cloud implementation. 

Logically to me, the cloud costs for additional instances, services, virtual machines, code, and similar services should be capitalizable. These objects used, managed, and monitored under the development phase, align with the accounting standard. These should be eligible costs provided that they are identifiable and separable in the agreement and used exclusively for those phases of implementing enhanced features within the CCA cloud instances. Additionally, in post-production, the development instances of these cloud applications should qualify provided they are active and used only for qualified capital task activities. This should also be true when evaluating capitalizable post-production enhancements.

Recently, I read as many articles as I could find but there is a gap in the treatment of CCA cloud charges identifiable exclusively for implementation and enhancements. So, for the first time in thirty years, I called the AICPA technical hotline with these very questions seeking clarity. Specifically, the focus of the issue was around the capitalization treatment of charges that have separate, indefinable components that are used exclusively during the qualified phases of implementation. Using SaaS products like Workday, Kronos, and Oracle Financial Cloud, I explained that there are needs to have development instances that enrich the code base, enhance value and have activities that align with the phases expressed. The response supported the theory that non-production, development phase instances, and costs in the cloud used for the initial deployment to a specific instance or cloud platform are, in theory, eligible but nowhere spelled out. 

The theory is based on the fact these identifying items are not specifically excluded and are in the spirit of the ASU pronouncement. To me, having the non-production CCA costs in the cloud used for the design, development, and testing phases separated, measured, and only used for those purposes being eligible for capital treatment appears sound. I wish the accounting board can provide more definitive interpretations but the logic appears sound until then. The challenge is in keeping the instances, cloud objects, and elements aligned to the phases that qualify for capital treatment. Beware of any mixed-use cloud objects such as using development instances for non-eligible activities like training or conversion. Additionally, idle development instances should only exist for that activity may invalidate the eligibility for the associated costs to be capitalized.  

Tips to Align Cloud Costs Capitalizable Candidates

Tip 1 - Separate Non-production Instances for Specific Implementation Use

Since cloud costs often are combined on the order forms, it is vital to separate for identifying those elements that are capitalization eligible. ASU only discusses the treatment production instance in principle, but in reality, more instances exist for deployments. In the example below, the development and testing instances and copies of cloud services, along with the associated run costs, should be aligned to the capitalization phases.   Having the instance management align with the methodologies such as waterfall or DevOps is equally essential to ensure that only those eligible activities use their respective cloud instances. 

Tip 2 - Use ‘Tagging’ and ‘Rules’ within the Cloud Identify Eligible Capitalized Cloud Objects

For IaaS and PaaS deployments to the cloud, whereby you are using the cloud as a development platform, the costs associated with the implementation of virtual machines, software services, and objects used for design, development, and construction should be identifiable via 'tags'. For example, Microsoft Azure has built-in tagging features to assign to these objects along with the measurable cost runs for each of the tagged objects. The association of the cloud objects used during IaaS and PaaS deployments using 'tags' can be combined with 'rules' to ensure that capitalizable activities align with the cloud objects and related costs. 

Microsoft Azure (Microsoft, 2020b) provides tags, resource groups, and hierarchies to help manage objects, and these are used for capitalization assignments. 

Tip 3 – Tighter Instance Management and Controls

Cloud objects should only be active during development activities. Managing and monitoring the 'taxi meter' of cloud services is vital to ensure cost measurement and alignment to capitalization categorization. Starting and stopping the virtual machines and services should be done to associate the run costs of these cloud implementation objects to the capitalizable event. For all other times, this 'rental burn' is an operating expense as ineligible idle time is not eligible. Conveniently, cloud services allow for the starting and stopping of services that can help both cost management overall and monitoring.

Microsoft dashboards for VM management can ensure costs are aligned and associated with qualifying activities. (Microsoft, 2020a)

Conclusion

Just as the rapid technology challenges your IT professionals to learn the nuances of the cloud, accountants are equally held to task keeping up with the intricacies of how to manage the costs surrounding these deployments. Pronouncements from over twenty-plus years ago that expected servers, software, and activities to be in-house are out of date with the new age of cloud deployments. As a result, the pronouncements kept many of the capitalizations of qualified phases to assign activities that are eligible for capital treatment the same. The surrounding costs, such as integrations, labor, external software, and tools, as well as the statement that CCA arrangements function as 'leases' and, as such, are operating expenses, were made clear. What wasn't clear were portions of cloud costs and activities that are non-production, exist only for the implementation phases of the original cloud internal use software deployment or subsequent enhancements. Since the FASB is vague on these specific costs, the spirit of assigning the non-production cloud objects and activities should at least monitor and manage expenses when a pronouncement clarifies the position one way or the other.   Separating instances, objects, tagging cloud elements to assign costs is prudent and should be done by each IT leader to allow for capitalizable treatment; otherwise, the mixed-use of these cloud elements will be operating expenses.   

As with all advice, consult with your finance group and pose the specific question – 'What happens to cloud costs that represent non-production CCA items used only during the design, development, and deployment phases of the implementation and enhancement phases?' In theory, these costs, if separable, are capitalizable and qualify for treatment under the ASU. If you don't start separating these elements, then you guarantee a difficult time in any capital treatment.

Good luck and let me know your thoughts.

Bibliography

AICPA. (1998, March 4, 1998). Statement of Position 98-1 Accounting for the Costs of Computer Software Developed or Obtained for Internal Use. Retrieved from https://www.fasb.org/jsp/FASB/Document_C/DocumentPage?cid=1176156442651&acceptedDisclaimer=true

AICPA. (2018). ASU 2018-15 Intangibles - Goodwill and Other-Internal-Use Software ( Subtopic 350-40). Retrieved from https://www.fasb.org/jsp/FASB/Document_C/DocumentPage?cid=1176171138858&acceptedDisclaimer=true

Microsoft. (2020a). Start/Stop VMs during Off-Hours Overview. Retrieved from https://docs.microsoft.com/en-us/azure/automation/automation-solution-vm-management

Microsoft. (2020b). Use Tags to Organize your Azure Resources and Management Hierarchy. Retrieved from https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/tag-resources