capitalizing software

Accounting for Utility Software Services

By Jeff Lipton
Accounting-for-Utility-Software-Services-blog
The software vendor business model has evolved rather dramatically in the past decade or so. Traditionally, utility software providers (including SCADA, customer information systems, work order management, rebate tracking, and other common solutions used by water utilities) would sell a perpetual license to their water utility customers who would then install the software on a local computer or server. Customers would have the option of purchasing annual maintenance and support packages and could upgrade the installed software every few years as new versions with additional functionality became available. This business model allowed customers to 'own' the software which also meant they could budget for the technology expense in a single fiscal period and then decide whether or not to update to a newer version in the future.
 
Unfortunately this model has some inherent disadvantages for the water utility customer: 
  • The utility needs to maintain their own computer hardware to run the software systems. This means hiring IT staff, investing in server technologies, and incurring ongoing costs to build and maintain the systems. 
  • By offering perpetual licenses to software, technology vendors have an incentive to design obsolescence into their products to continue to drive revenue from future software upgrades. These upgrades can be expensive and disruptive to the utility, and many times the upgrades are not backwards compatible which requires reconfiguring existing systems to work with new software versions from the vendor.
 
Over the past decade a new approach to delivering software emerged through the evolution of high speed internet services along with pioneering business models in the software industry. Inelegantly named Software-as-a-Service (or SaaS), this new model moved software out of the utility premise and into a series of servers managed by the software vendor (or a third party 'cloud' service provider) and was offered as a service on a monthly or annual subscription. In essence, utility customers no longer purchased software to own and run in their own data center, but rather subscribed to the services offered by a given software provider.
 
This new service model provided a number of benefits to the water utility: 
  • Utilities no longer had to purchase and maintain their own computer hardware for many system critical applications. The availability of cloud services allows utilities to easily scale software services as needs change without the need for costly infrastructure upgrades. 
  • SaaS provides utilities with a clear upgrade path as new software features are automatically rolled out to service subscribers - the notion of software versions dissolves under a multi-tenancy structure. This means that all customers share a single instance of the software and the software provider doesn't have to manage multiple versions of the code base. This lowers costs for the vendor, which translates to greater functionality and value to the utility.
  • The ability to maintain a single code base for all subscription customers not only offers a consistent set of upgrades and new features, but it also ensures backwards compatibility with other legacy systems as the interfaces to the platform remain stable. This is another cost reducing benefit of the SaaS business model.
 
While the benefits of SaaS are becoming better understood by many utility managers, a new challenge has emerged in the procurement of software that is delivered as a service. In the legacy regime, software was purchased under a perpetual license which meant that the utility effectively owned the asset and could treat the cost of the software as a capital expense (CapEx). A majority of costs that utilities incur are related to capital expenditures such as pipes and pumps, so adding a software expense to CapEx was easy to understand.
 
Also, the vast majority of the annual budget for a typical water utility goes to capital expenses. The cost of even a large software system was considered relatively modest in the context of a much larger capital budget. And for investor-owned utilities that are able to recover capital expenses plus a regulated profit through the rate making mechanisms overseen by state-level public utility commissions, it made sense to 'capitalize' software purchases and build those costs and profit margins into future rate increases which would be paid by the end-use customers.
 
As software sales have moved to a service delivery model, the cost associated with SaaS is now generally treated as an operating expense (OpEx). The operating budgets of most water utilities are considerably smaller than the capital expenses, and operating expenses are not generally eligible for a rate of return at investor-owned utilities. This quirk between the way that capital and operating expenses are accounted for creates an impediment for water utilities to budget for SaaS purchases, even when the total cost of ownership for a multi-year services agreement is lower than the cost for a perpetual software license which is often the case when you factor in configuration and ongoing maintenance and support costs.
 
In order to remove impediments to purchasing SaaS solutions, municipal water utilities and public utility commissions should reconsider the way that they account for these costs. By allowing utilities to recover the costs of operating expenses (or conversely, capitalizing software service expenses), utilities will have a greater incentive to invest in lower-cost, higher value software services which will provide more value to the utility, their customers, and the communities they serve.

Posted in capitalizing software, capital expenses, operating expenses, Software-as-a-Service, purchasing software, utility software

Check out these similar articles:

0 Comments