In research conducted by the Economist Intelligence Unit for BSA | The Software Alliance it was estimated that software contributed over $1 trillion to total value-added GDP in 2015, almost half of which was direct value-add vs. indirect or induced.
In fact, investment rates in intangible assets surpassed tangible assets in the late ‘90s and are now roughly 50% larger. Of course, software assets have played large part of this change.
Still, there is much debate around the accounting treatment of software development efforts. PWC published a very nice point of view on this topic last year and is definitely worth the read. In short, they contend that it is time to evaluate the current models for accounting for software development to determine if they still fit in today’s business environment. Some of the specific reasons behind this relate to the two different accounting guidelines for internal-use software (IUS) and software for sale or lease. SaaS businesses typically fall under IUS guidelines, but that is potentially largely because the guidelines were written before SaaS was predominant.
While the interpretation of the guidelines is often a point of confusion for accounting departments, ultimately, this becomes a thorny issue because it impacts company processes and budgets.
This all starts with the fact that companies employ people, and headcount expenses are always defaulted as operating expenses. In our previous post on agile accounting, we discussed the analogy of software to more physical, tangible assets like machinery. The reality is that determining CAPEX vs. OPEX as it relates to physical capital is far easier because the defaults there are already embedded in our accounting processes and logic, and are far easier to identify. Software assets are created through people’s effort, and it fundamentally requires a cost accounting method to be applied to transfer the default operating headcount expenses to capital expenses.
The vast majority of arguments people make on why not to capitalize are largely driven by this issue, whether on the surface or in a more behind the scenes way.
The reality is that it is hard to define software development as anything other than asset creation. Companies and people do not develop software for short-term (ie current accounting year benefits). In fact, the whole point of software is to drive long-run efficiency gains whether it be through process automation, transaction cost minimization or any other benefit that software drives.
While we have made the argument that it is not ideal for finance to impede business process adoption, it is also probably worse if we do not recognize the value of Generally Accepted Accounting Principles (GAAP) as important to providing investor confidence across industries.
A little diligence in company annual reports will show that it is not uncommon to find companies operating largely in direct competition with each other that have wildly different relative software asset balances because of how they choose to treat the issue. PWC references this as one of the major criticisms of GAAP in that many company’s major assets are not reflected on their accounting statements.
Here is a simple scenario that serves as a litmus test for what the standard should be.
Let’s take a small to mid-market company (say $50M in annual revenue) who is looking to develop a SaaS application to sell to its customers as an add-on to their core product subscription. They have two options in developing the first version of this application, they can outsource it to another firm for $2M, or they can develop it internally with their staff, by shifting them off other product work. In both cases, it is estimated to take 6 months to develop the first product version and feature set. The same asset is being developed in both scenarios.
In the first scenario, a company will receive a $2M invoice at completion (or set of invoices along the way), and it is almost never the case that a company would expense that $2M as incurred. So why would the accounting result change if the company has its internal staff run development? The fundamental idea is that this is a question of ‘what’ and not ‘how’ or ‘who’.
There is no doubt that companies have flexibility on the margins here in terms of being conservative or aggressive as it relates to this topic. And, as previously argued, there is more value in simply having solid measurement across initiatives than the capitalization decision on its own. Still, capitalization of labor should exist.
The critical component here is that companies have flexibility to implement simple and streamlined solutions that are not over-engineered. If that is not possible, then the question does come back to one of feasibility.
