Accounting for Software as a Service (#270)
/In this podcast episode, we discuss the accounting for software as a service. Key points made are noted below.
Software as a service is when a customer accesses software over the Internet, as needed. This discussion can come from both sides of the equation, which is from the perspective of the customer and the service provider. From the customer’s side of things, there’s some fairly new guidance that only covers the fees paid by the customer in a cloud computing arrangement.
Relevant Accounting Guidance
In case you want to look it up, this is Accounting Standards Update 2018-15, which was issued by the Emerging Issues Task Force. The EITF is a group within the Financial Accounting Standards Board that issues guidance on some fairly narrowly-defined topics. According to the EITF, if the arrangement includes a license for internal-use software, which it usually doesn’t, then the customer recognizes an intangible asset for the software license and amortizes it over time. If there is no software license, then the customer instead accounts for the arrangement as a service contract; which means that the customer charges the monthly hosting fees to expense as incurred.
Another issue for the customer is what to do with the cost of implementing the arrangement when it’s been classified as a service contract. Training and data conversion costs mostly have to be charged to expense right away. Any costs related to application development are capitalized, depending on what they are. And, any costs incurred during the preliminary project and post-implementation stages are charged to expense. That advice is probably not going to apply to most software as a service arrangements, because there is no application development.
But if it does happen and these costs are capitalized, they have to be amortized over the term of the hosting arrangement, beginning when the hosting arrangement is ready for its intended use, which is when all substantial testing is completed. The term of that arrangement is the initial non-cancelable period, as well as any extension periods, as long as the customer is reasonably certain to exercise it. There’re some other variations on the term of the arrangement, but that’s the most likely scenario.
Even though there are some capitalization possibilities here, in most cases, from the perspective of the customer, the bills from the hosting provider will probably be charged to expense as incurred.
Subscription Revenue Accounting
Now, let’s turn things around and look at the situation from the perspective of the seller. First, subscription revenue accounting. The accounting for customer payments will depend on the terms of the underlying contract, so I can only talk in general about how this might work. Let’s say a customer makes a large up-front payment, and in exchange the service provider commits to provide services for the next year. If so, the up-front payment is initially recognized as a liability, and you can flip it over to revenue at the rate of one-twelfth per month. Or, maybe you gave the client two months of free services up front, so that up-front payment is only for months three through twelve. It doesn’t matter. You’re still providing 12 months of services, so divide the up-front payment by 12 and recognize one-twelfth of it in every month. There can be so many variations on this that I can’t possibly address them all.
Customer Cancellations
A variation on the revenue theme is customer cancellations. Again, how you account for it depends on the terms of the underlying contract. If the customer can back out at any time and get its money back for any subsequent periods, then revenue recognition ends when the arrangement is officially cancelled. Or, if the cancellation just means that the customer doesn’t plan to renew its annual contract, then there is no special accounting. You’re presumably already recognizing revenue over the term of the original service contract, so just keep doing it through the end date of the contract.
Multi-Part Arrangements
Another revenue variation is multi-part arrangements, where the provider is also providing other services, such as training. Once again, it depends on the terms of the contract, but you’ll probably need to split apart the amount of the revenue and allocate it to each element based on its market value, and then recognize each part separately. This can be a big deal when some of the services are being provided up front, like training, because the revenue for those elements can be recognized sooner.
Over-Budget Implementations
A second topic is over-budget implementations. There could be some different positions taken on how a service provider accounts for the implementation of each of its customers. The most conservative approach is that these expenditures are an element of selling costs, and so would be charged to expense as incurred. Which means that, when an implementation goes over budget, there is no special accounting for it, because you’re still charging it to expense as incurred.
A less conservative approach is that the implementation cost is initially capitalized and then amortized over the life of the underlying contract. In this case, you’d want to set a budget for each implementation and charge off whatever expenses go over the budget, as an unexpected variance. This requires a lot of accounting work to accumulate and then amortize implementation costs, so if implementations aren’t very expensive, it could make sense to ignore the whole issue and charge everything to expense as incurred.
Software Development Costs
And finally, we have software development costs. This is covered in two entirely different parts of GAAP. Section 350 of the Accounting Standards Codification covers software that’s developed for internal use, while Section 985 covers software that’s developed for external use. There is a reason why they split it up, which is that internal-use software is considered an intangible asset, which is what Section 350 is all about, but it’s still confusing. For our situation, we only need Section 985. Under Section 985, the capitalization of software development costs can take place when technological feasibility has been proven. If not, you have to charge it to expense. And, once development is complete and the software has been made available for release to customers, then you have to stop capitalizing. After that, all remaining expenditures are assumed to be ongoing maintenance and support, which have to be charged to expense as incurred.
So, what is technological feasibility? It’s been established when – and I quote – the business has completed all planning, designing, coding, and testing activities that are necessary to establish that the product can be produced to meet its design specifications, including functions, features and technical performance requirements. End quote. This requirement applies even if you’re paying an outside party to develop the software.
So, there’s obviously some documentation needed to prove to the auditors that you’ve established technological feasibility. To do that, you’ll need either a detailed program design or a working model that’s ready for customer testing. In the latter case, that can mean that you’ll end up charging a very large part of the development costs to expense as incurred, because GAAP isn’t allowing all that large of a window for capitalizing expenditures.
And what about ongoing update work on the software? Unless it involves an entirely new feature, charge the cost of those activities to expense.