Should Your CFO Be Concerned About Software Value?
CFOs hate to be surprised. And they work very hard to make sure every line item on the balance sheet has a reason, and explanation, for being there. This is no different when it comes to understanding software value – and the business value of the software assets on the balance sheet. Of course, the
CFO should also be very aware of how the activities of the software development group are going to affect that number tactically in the short term and strategically in the medium and long term through new initiatives such as investment in developing a new or replacement application or the impact of any M&A activity.
Any CFOs reading this will be well aware that some of the costs of software development must be expensed in the year in which they are incurred – these are called operational expenses, often shortened to “OpEx”. These costs have a direct negative effect on the organization’s profit or loss in that year. From a CFO’s perspective in any given year, the business value of the software in the company as represented on the balance sheet will decrease if OpEx associated with software value is high because profits and cash in the bank will be reduced. However, if some of the costs of software development can be “capitalized” then those costs will move onto the balance sheet as an “asset” to be amortized over time – usually three to five years for software. This part of the annual software development cost is capital expenditure or “CapEx.” Capitalization has the effect of increasing “natural” profit in the first year that it is introduced but reducing “natural” profit in subsequent years as the capitalized amounts are amortized (charged back).
How do CFOs decide which software can be capitalized and which cannot? Naturally, there is some “devil in the detail” and expert advice should always be sought, especially from the organization’s auditors. That said, the general principle to apply is that the proof of concept of an “idea” to be implemented in software cannot be capitalized, however, the implementation of the idea can be capitalized. The “maintenance” of the implemented idea must be expensed in the year that it occurs.
Requirements definition and design are generally considered to be about “fleshing out” the idea so these must be operational expenses. Coding and testing are certainly implementations of the idea and can be capitalized. Maintenance is an operational expense. For cost allocation purposes, the CFO simply has to put in place a way to capture the time spent in each activity. In some cases, it is necessary and appropriate to have software development staff record their time by task on an hourly basis. Often though, it is broadly sufficient to apportion the project cost by numbers of headcount associated with each activity.
If a company is using the Waterfall methodology for software development, the separation of CapEx and OpEx activities is usually fairly clear and easy to estimate and document. For the Agile methodology, separating of CapEx and OpEx activities is harder to estimate and document without any a burden of bureaucracy to the Agile teams.
Again, the real challenge for the CFO in managing balance sheet value is the avoidance of surprises. This means that the CFO has to develop an understanding of software development plans to comprehend the future impact on the balance sheet and on profits. This requires CFOs to be more involved in software development planning several years ahead. Perhaps, more than their natural inclination would dictate.
“The Business Value of Software”, my new book releasing next month, covers this very topic in a specific chapter. It addresses how the business (eg: CFOs, C-Suite, product owners) can start to address how to create practices that define the value of software.
Michael D. Harris