By Leonard Greski, Chief Scientist, LiminalArc
Twenty-five years of change in the cost structure of technology created a minefield of risk as executives fund software application development, regardless of whether the software is sold or leased to customers or developed for internal use. Conflicting pressures lead to one breakthrough solution: Stop arguing about CapEx versus OpEx. Fund the next increment with the value you just shipped.
An Historical Perspective
Organizations have treated software applications as capital assets since the 1950s, based on early go to market models for computer hardware where the software was included in the price of capitalized hardware. The 1969 U.S. antitrust suit against IBM forced the company to begin charging separately for most software programs. Implementation of the antitrust agreement created an independent software industry as IBM and other companies separated their hardware and software businesses.
As software became a separate entity from hardware, companies relied on existing accounting standards to decide how to treat software expenses. During the 1970s the Federal Accounting Standards Board’s guidance about research and development (including software) was very conservative – costs were to be expensed as they occurred. Beyond R&D the standards were unclear, leading to a diversity of accounting treatment of the expenses to build software for sale or in-house use.
The accounting environment changed significantly with the 1985 introduction of SFAS 86, which allowed capitalization of software development costs for computer software to be sold, leased or marketed after “technological feasibility” was established [1]. Guidance for internal use software took another decade to emerge, eventually articulated in the Association of International Certified Public Accountants statement of position (SOP) 980-1, and later codified as ASC 350-40. [2] The AICPA took a three-stage position on expense vs. capitalization, where preliminary planning and operations are expensed, but application development post-planning may be capitalized.
The goal of these changes was to more effectively align the costs of building software with the benefits generated over the software’s useful life. However, life, for technology executives, was about to get a lot more complicated.
Cloud, SaaS, and Agile Exert Pressure on OpEx Budgets
Cloud computing, an infrastructure model that allows companies to pay for computing as they use it rather than making large up-front purchases of capital assets, had relatively minor impact on budgets between 2006 and 2014. At the time, cloud consumed a small proportion of IT budgets, usually less than 15% for most enterprises. By 2020, enterprise spending on cloud infrastructure ($130 billion) surpassed spending on data center hardware and software ($90 billion) for the first time. [3] More recently, enterprise spend on cloud as a percentage of IT budgets has grown to as much as 30 – 50% of total IT spend, with Gartner pegging it at 47% in a 2024 research article. [4]
Bottom line: Subscription-based infrastructure moved roughly half of IT spend from the balance sheet to the income statement.
The net effect of these structural changes in the finances of IT is increased scrutiny on infrastructure costs, as the immediacy and variability of cloud spend (often driven by factors outside the IT department’s control) require a different form of financial management than the typical 5 to 7-year capital asset planning, purchase and depreciation cycle.
SaaS Follows the Same Cost Pattern as Cloud
A similar storyline emerged with Software as a Service (SaaS), with Concur (1993), NetSuite (1998) and Salesforce (1999) challenging the traditional way that software was purchased and consumed by companies. The key innovation was a multi-tenant architecture that would enable multiple customers’ workloads to be managed by a single instance of the application. Multi-tenancy was further enabled by cloud computing, as SaaS vendors could build their applications on highly scalable / pay per use cloud infrastructure. Together, these innovations reduced the cost per customer of SaaS applications from $12,000 – 18,000 annually to under $2,000 as of 2026. [5]
That said, as SaaS usage grew, IT departments began to experience the same capex to opex cost migration challenge they experienced with cloud computing. A 2024 Gartner article, Software and SaaS Contracts: New Negotiation Tactics for CIOs, asserted that companies spend as much as 29% of their IT budgets on SaaS and software, with price increases as high as 30%. [6]
Capex: The IT Budget Relief Valve?
If cloud charges consume 47% of the typical IT budget and SaaS / purchased software claims another 29%, that leaves only 24% to fund everything else. Unfortunately, overall personnel costs are running at 35% of total IT spend [7], leaving many IT departments over budget by 900 basis points.
How might a CIO relieve this form of budget pressure? An obvious approach would be to capitalize enough application development labor to reduce operational spending by 900 – 1,000 basis points. I have observed multiple companies address short-term budget challenges in this manner, but after three or four years of increasing labor capitalization to meet an OpEx target, CIOs find themselves squeezed between the rock of the operating expense budget and the hard place of the amortization schedule.
The Straw that Breaks the Camel’s Back: Accounting for Agile Development
Earlier we described how the American Institute of Certified Public Accountants codified an accounting standard for software development into ASC 350-40. It took a stage-based approach, where capitalization is only permissible during the second, “application development” stage. This stage occurs after preliminary planning but before the initial production deployment to customers or end users.
The theory is that work organized in an agile manner can be capitalized as it goes through the ASC 350-40 stages. The reality, however, is that a high functioning Scrum team passes through all three of these stages during every two-week sprint.
The agile emphasis on frequent delivery of working tested product becomes an accounting nightmare when the organization tries to capitalize the expenses. Companies take three major approaches to capitalization, each of which has significant implications for audit defensibility and operational cost.
| Approach | Description |
| Story Level Tagging | Each ticket marked as new development vs. maintenance at story refinement.
Pros: Highest audit defensibility Cons: Creates the heaviest process overhead and associated team friction. |
| Epic Mapping | Capitalize by epic or initiative, not feature or story. Attempts to balance audit rigor with impact to team velocity.
Pros: Moderate audit defensibility Cons: Less labor intensive than story level tagging |
| Percentage Survey | Conduct quarterly surveys of engineering activity to capitalize a blanket percentage of engineering cost.
Pros: Least effort required Cons: least defensible in an audit |
In current practice the trend is clear: as firms implement continuous delivery, software capitalization rates are falling. Direct expensing of software development costs simultaneously reduces non-value adding labor and audit risk.
The Breakthrough Solution: Earn the Right to Invest Again
What does “earning the right to invest again” look like? It consists of three steps, including:
| 1) Ship a thin slice | Working with business partners, identify the smallest unit of value that someone will pay for or measurably reduce cost – targeted in 30 to 60-day cycles. |
| 2) Monetize the slice | Tie revenue, cost reductions, or a binding usage metric to the release. If the value is an increase in revenue, add the slice’s value to the firm’s revenue plan. If it is a cost reduction, cut the relevant labor and/or materials budgets accordingly to force monetization of the savings. |
| 3) Fund the next tranche | Board or Portfolio-level executive approval for next scope of work releases per verified outcomes, not an annual spending plan. Align units of funding with value streams or products. |
This approach reframes accounting treatment of application development as a second-order concern, that is, it shifts the conversation from accounting treatment to accountability for value generation.
AI-enabled Software Development: Tilting the Scales towards OpEx
AI-enabled software development is reducing the cycle time and cost of producing working tested product. For example, survey respondents in Google’s 2025 DORA report indicated that more than 80% of respondents reported that AI has increased their productivity. [8] An MIT study of almost 5,000 software developers at Microsoft, Accenture and an anonymous Fortune 100 manufacturer resulted in a 26% increase in the weekly number of tasks completed by users of Github Copilot relative to developers who weren’t using the tool. [9]
When the time it takes to obtain an increment of end user value is measured in days as opposed to quarters, the effort to capitalize a “project” no longer represents the reality of how software is built and deployed. In this situation the appropriate unit of accounting is an experiment or investment hypothesis, and therefore the correct unit of funding becomes the business outcome.
Furthermore, AI-enabled software development introduces new categories of spending such as AI tool usage charges, content storage in vector databases, and code analysis infrastructure that are all inherently operational in nature because they are not compiled into the “created asset.” The accounting treatment for these items is consistently Opex.
Applying a Strategic Lens
Given the above conditions, the main question about software application for C-suite leaders is no longer “what can we capitalize?” but rather “how do we obtain value most quickly?” A second question, almost as important as the first, is “what funding model keeps us honest about cost and risk?”
A delivery approach that delivers working tested product to customers or end users in 30 to 60-day cycles will generate value more rapidly than one driven by annual planning cycles. A product-focused funding model that considers the useful life of the product is more aligned with reality than a project-focused one [10]. A funding model that explicitly accounts for uncertainty of value will also be biased toward frequent delivery cycles.
The idea of uncertainty of value (described in Kersten 2018) can be combined with the accounting treatment for the useful life of an asset to establish a 2×2 framework for funding decisions as follows.
| Experiment | Short life & unproven value
When both the useful life and business case are open questions, spend as little as it takes to answer them. Run these as clearly bounded pilots – a fixed dollar spend limit, a defined decision date, and written kill criteria the sponsor agrees to prior to the start of work. The result or output is an answered business question, not a running system. |
| Expense & Measure | Long life & unproven value
When the software is likely to be around for years but the business case is uncertain, develop it as a measured expense rather than a capitalized asset. Book the costs to operating expense, include instrumentation to prove value, and let the evidence decide whether the work earns its keep as a capitalized asset or gets wound down. This is where most strategic ‘platform’ bets begin before they become infrastructure. |
| Subscribe | Short life & clear value
When value is clear but the underlying technology evolves faster than it can be amortized, attempt to rent rather than owning it. Treat these workloads as operating expenses from day one, subscribe to a managed service, and redirect the organization’s engineering capacity on problems the market doesn’t already solve for you. The failure model is “sentimental” – keeping a custom stack alive long after the build versus buy math has flipped to favor “buy”. |
| Capitalize | Long life & clear value
This is the textbook ASC 350-40 candidate – past a preliminary scope phase, has defined users, a demonstrable revenue or cost-savings path. Capitalize application development costs and amortize them across the expected life of the resulting asset. Core platform services, billing, identity management, and foundational infrastructure on which other value streams depend belong here. Highly regulated industries may require a higher capitalization rate for compliance. The leadership challenge is being honest about when a project clears this bar. |
The pattern is that leaders should capitalize what is clearly durable. Expense what is honestly uncertain. Fund what can pay for itself. Let the feedback loop – ship, measure, learn, invest – set the pace of everything else.
Beyond the pattern, we recognize that some industries are more highly regulated than others, and these sectors may require more extensive capitalization for compliance. That said, the 90-day cycle for delivery of value is valuable regardless of the accounting treatment of an increment of value.
Moving Forward
The new economics of software development dictate that the sharpest leaders have stopped optimizing the accounting treatment. Instead, they optimize the feedback loop. If this article has provoked fresh thinking about your capital and expense budgets, consider taking the following actions within the next 90 days.
- Review your capitalization rate
Measure the percentage of spend that is capitalized. If your organization uses agile development and your capex rate is above industry medians, you have an audit risk and transparency problem. - Fund value streams or products, not projects
Replace annual project capital expenditures with outcome-gated envelopes lasting no longer than 90 days. Reward shipping a slice and monetizing it, not completing work breakdown structure items in a plan. - Instrument every release
No release goes live without a revenue, cost, or usage metric attached to it. This is essential to the monetize-to-fund loop. It also aligns with the measurement guidance provided in The Emperor’s (not so) New Clothes: the scam of corporate performance frameworks and what to do about it. - Pre-write your AI policy
Decide in advance how AI-assisted code, model usage and evaluation infrastructure map to capitalization, before your auditors ask. - Make FinOps a senior executive role
The combination of cloud and SaaS spend are the largest controllable IT expense lines. Treat them like cost of goods sold (COGS) with ownership, forecasts, variance analysis, and accountability for results.
References
[1] Financial Accounting Standards Board (1985) – SFAS 86, retrieved from FASB website on April 17, 2026.
[2] Munter, Paul (1999) – Accounting for Software Development Costs, The CPA Journal, retrieved from cpajournal.com website on April 17, 2026.
[3] Carey, Nolan (2021) – Cloud spending outstrips on-premises investments for the first time, InfoWorld, retrieved from infoworld.com website on April 17, 2026.
[4] Banerjee, Ashish (2024) – Maximize the ROI of Cloud Investments, Gartner, Inc. Document G00816239, published December 4, 2024.
[5] CloudNuro (2026) – A Brief History of SaaS: from ASPs to the Subscription Economy, CloudNuro, retrieved from the cloudnuro.ai website, published January 12, 2026.
[6] Decker, H., Lozada, C., Alexander, M. (2024) – Software and SaaS Contracts: New Negotiation Tactics for CIOs, Gartner Inc., document G00820833, published December 11, 2024.
[7] Stegman, E., Guevara, J., Sharma, A., Mehta, P., Tyagi, P. (2025) – IT Key Metrics Data 2026: Industry Measures – Executive Summary, Gartner Inc., document G00840319, December 11, 2025.
[8] DeBellis, D., Storer, K., Harvey, N., et. al. (2025) – DORA Report, Google Inc., retrieved from the Google website (login required), published September 23, 2025.
[9] Cui, K., Demirer, M., Jaffe, S., Musolff, L., Peng, S., and Salz, T. (2025) – The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers, Massachusetts Institute of Technology, retrieved from the Economics department’s website on April 18, 2026.
[10] Kersten, M. (2018) – Project to Product: how to survive and thrive in the age of digital disruption with the flow framework, Kindle Edition, IT Revolution, Portland OR. 97210
[11] Greski, L. (2026) – The Emperor’s (not so) New Clothes: the scam of corporate performance frameworks and what to do about it, Architecture & Governance Magazine, January 7, 2026, IASA Global, San Antonio TX, 2026.
About the Author
Len has over 30 years of experience helping large organizations generate billions of dollars in economic value by leading high risk, high visibility business and digital transformations. In his role as Chief Scientist at LiminalArc, Len leads the development of new service offerings that enable customers to organize around business capabilities, build products and services that customers love to use, and improve operational efficiency. He also leads engagements with large clients to help them increase quality, productivity and business value. Len received Bachelor and Master of Arts degrees in Sociology from the University of Illinois at Chicago with concentrations in Organization Theory, Research Methods and Statistics.