Why software capitalization can be wasteful

There is a long-lasting debate among IT stakeholders and executives on whether software is a long-term asset or a cost of conducting business. In this article, I will interpret the rationale for both sides in the context of the enterprise IT in the digital age.

“Capitalization” is an accounting method used to spread out the cost of a new asset over its useful lifespan to align the recognition of associated expenses and benefits for an accurate reflection of asset’s financial performance. Most IT organizations capitalize application development expenses, as much as allowed by the accounting regulations, to minimize impact on their current year P&L, which constitutes the financial basis of many core management processes like investment planning, project prioritization, capacity planning, and performance management.

Example: A project spends $10 million on software development. The finance department determines that 40% of project expenses can be capitalized over a five-year period, which results in $6MM OpEx and $4 million CapEx. The current year P&L impact of this project becomes $6.8MM, and the remaining $3.2 million is depreciated over the next four years.

The logic behind software capitalization is to encourage investments with long-term value. Proponents argue that:

• Software expenses incur upfront, but benefits are realized later and over a long period – true for industrial-era enterprise solutions like ERP implementations. In the digital age, application lifespan has significantly shortened.
• Treating a software investment as an operational expense hides its true value, which may unfavorably impact company’s stock price and financial performance – an important consideration for newly established companies with limited revenue streams, but a nuance for long-established financial services companies, where software investments are only a small fraction of the same-period revenues.
• Capitalization allows companies save on taxes, and thereby hire more developers, accelerate projects and reduce go-to-market time – valid during the growth period of investments. These benefits are washed out by the accumulating depreciation as spending growth slows down and investments reach a steady-state (see Figure 1).
• Capitalization smooths departmental P&L performance, which drives hiring and firing of resources – at established financial services IT organizations, resource consumption at departmental level may fluctuate significantly; however, this rarely leads to a massive hiring or firing exercise as application resources are continually moved to new projects within the same enterprise.

Technology for Alpha LLC

In summary, the benefits of software capitalization are limited for long-established financial services companies, and they are further shrinking with the accelerating pace of business change in the digital age.

Let’s look at the unintended consequences of software capitalization:

• Technical debt accumulates: Improvement initiatives, e.g., portfolio rationalization and modernization, cannot be capitalized, and therefore, they are systematically deprioritized to minimize P&L impact in the current year. Similarly, applications are rarely sunset due to lack of funding (sunset projects cannot be capitalized).
• Project prioritization is distorted:  Minimizing the current year P&L impact, rather than the total cost of ownership, leads to suboptimal prioritization decisions: projects with a higher capitalization ratio are prioritized; nonfunctional requirements are neglected; locked-in portion of the P&L is not managed – 64% of P&L is not managed in Figure 2, and up to 80% at other organizations.
• Business outcome ownership is diluted: As current expenses are deferred, and budgets are locked in due to past decisions, the sense of accountability and empowerment for achieving committed business outcomes is weakened – 28% of development expenses are deferred in Figure 2, and up to 40% at other organizations.
• Overhead expense increases: Administration of software capitalization is a very laborious process with no tangible value-add to the final product, i.e., software due to:
  • Prolonged debates among business, finance and IT executives and professionals to determine what component qualifies as a new functionality. It is important to note that the bank illustrated in Figure 2, consumed extensive efforts to creatively increase the capitalization ratio, which partially explains the 4% gap between the capitalization credit and the depreciation. (Another driver for this gap was the increasing regulatory requirements.)
  • Artificial estimates of benefit size and timing since most enterprises don’t formally manage business outcomes at project level. This challenge is partially alleviated with agile development, where it is possible to establish a meaningful linkage between expenses and outcomes.
  • Clutter of management reports based on extensive dicing and slicing of financial data across projects, features, departments and providers.

Technology for Alpha LLC

Considering benefits and unintended consequences of software capitalization, I believe that financial services companies are better off by treating software spending as a cost of doing business except for one-time investments that are significant enough relative to the same-period enterprise (not department) revenues.

The treatment of application development cost as OpEx, rather than CapEx,  is a significant step in improving productivity of enterprise IT, but it is not trivial:

• Existing book value of previously capitalized software assets should be taken out of the individual departmental P&Ls, and transferred to the corporate finance.
• At minimum, investment planning and project prioritization decisions should be based on 100% of the new development cost. Advanced organizations should leverage the forward-looking total cost of ownership estimates for better accuracy.
• Capacity planning, performance management, and financial reporting processes should be streamlined to eliminate non-value-added activities.

As enterprise IT is shifting its focus from “doing things right” to “getting the rights things done,” its stakeholders and executives need to challenge their conventional wisdom by asking a simple question: “What customer value does it create?” The software capitalization practice is a good place to start.

What do you think?