Software is not an asset

Photo credit: Fabian Blank via Unsplash

Which side of the balance sheet does your software sit on? Is it an asset or a liability?

When people enter the technology profession, they often expect to spend their time solving coding problems – and are surprised to find that they spend much of their time solving accounting problems. It’s an especially shocking revelation when they realise that money comes in at least two flavours – opex and capex, or revenue and capital, or whatever terms are used to distinguish money spent on continuous running costs and money spent on the purchase of new assets. And they thought that regular expressions were difficult to understand.

Furthermore, once they grasp the distinction between the two buckets that money is put in too, they quickly realise that the money is in the wrong buckets.

The way in which we account for technology has been under pressure for many years. Back in the past, we used to treat all parts of a new system as a capital purchase: we bought some hardware, and we bought or built some software, then we put them on our balance sheets and recorded their depreciation over a number of years. The exact number of years varied, usually depending on how much financial pressure the organisation was under, but the principle was the same: systems have a value when they are implemented, and this value declines over time, until they are ultimately worthless.

That approach sort of worked – at least, for accounting purposes – until the growth of cloud, and of software-as-a-service. Suddenly, servers, storage and networks were not boxes that you shipped to your data centre, recorded on your inventory, asset register and balance sheet, and started the clock on depreciation. They were services that you subscribed to. The amount that you used – and the cost you paid – varied from month to month, and attempting to identify the specific piece of equipment that was ‘yours’ was a fruitless mistake.

Similarly, the nature of commercial software shifted from packages that you bought and installed to subscription based services. The pricing was more flexible, but if you stopped paying, so did the service – and there was no asset to write off or depreciate.

If used well, this shift provides more control and flexibility and can be much more cost-effective – as well as freeing up resources that would otherwise spend their time managing infrastructure and software installations. Nevertheless, it has caused problems for CFOs and CIOs, who have struggled to deal with the impacts on their traditional methods of accounting and budget allocation. It turns out that the shift from fixed costs to variable costs is not always easy to handle.

However, I think that we should regard the shift to cloud and subscription based services as more than a challenge to the depreciation model for purchased assets: it is a catalyst for us to realise that there has always been something wrong with the way we account for systems development.

This should be apparent from the treatment of legacy systems. Despite the weaknesses and challenges of these systems, they are often running the most important functions within our organisations. Look inside most banks, and you will typically find ever higher concentrations of legacy as you approach the core banking systems – the system that manages accounts and processes transactions, and makes it possible for a bank to be a bank. These systems were usually fully depreciated many years ago, meaning that they supposedly have zero value on the balance sheet – but they are essential to the existence of the organisation. It is hard to think of assets with greater value.

The problem is that treating software as a capital asset has always been a mistake. The growth of subscription based services and cloud have put this treatment under pressure because cloud has converted hardware into software, and subscription based services have revealed the nature of software as a continuously evolving and developing capability. Together, they show that when an organisation decides to create a new piece of software, it is not buying a static asset whose value will decline over time, but creating a new operational capability whose value should increase over time. If the organisation is not prepared to make that ongoing operational commitment, they probably should not make the investment – unless they want to add to their portfolio of decaying legacy.

At some point in their careers, most technologists have to climb a learning curve to understand how money works. Perhaps we should take the trouble to help our financial colleagues climb the learning curve to understand how software works.