Capitalization of Software: Navigating Recent Changes in Accounting Standards
Most CIOs I know would rather discuss almost anything other than accounting treatment. I understand the instinct, and I think it is a mistake. How software costs land on the financial statements shapes what projects get approved, how big they can be, and how your function’s spending looks to the board. The accounting landscape for software investments has shifted meaningfully in recent years, particularly around cloud services, and a CIO who understands the rules can structure projects that a CIO who doesn’t cannot get funded.
What Is Software Capitalization?
Software capitalization means treating certain development or acquisition costs as capital expenditures rather than operating expenses. Capitalized costs are spread over the useful life of the software through amortization, which aligns the expense with the years the asset actually delivers value and softens the hit to current-period profitability.
The categories that typically qualify include development costs for internal-use software, costs associated with cloud implementation and migration, and customization or configuration work that prepares a solution for its intended use.
Recent Changes in Capitalization Standards
The significant update came from the Financial Accounting Standards Board. Under FASB Accounting Standards Update (ASU) 2018-15, implementation costs for cloud computing arrangements (CCAs) can often be capitalized where they previously had to be expensed, provided the costs are incurred during the application development phase and relate directly to preparing the software for use (source).
This matters because the industry’s wholesale shift to SaaS had created an accounting penalty: the same configuration work that was capital when you bought a license became expense when you subscribed to the service. ASU 2018-15 substantially closed that gap, and in doing so removed a distortion that was quietly biasing some organizations toward on-premises decisions their architecture teams didn’t want.
Implications for CIOs
At Drummond I’ve seen the benefit firsthand. During the implementation of our Wavelength platform, we worked closely with finance to evaluate which implementation and development costs could be capitalized. Applying the updated guidelines let us amortize those costs over time and preserve operating budget for other work. The same analysis has applied to portions of our Azure migration: the migration and configuration work sits exactly in the territory the updated guidance addresses, and treating it correctly changed the project’s budget conversation.
The practical benefits we’ve realized: better financial alignment between IT and finance, clearer IT project budgeting, and cleaner reporting on what technology investments actually return.
How to Determine What Can Be Capitalized
Identify the eligible costs. Design, coding, testing, and configuration during the development phase typically qualify. Research-phase costs and post-implementation costs (training, maintenance) do not. The boundary questions are where finance judgment is required, which is why the next point matters most.
Collaborate with finance early. Not at project close, at project planning. At Drummond we established a framework for categorizing expenses on large IT projects before the spending starts, so time tracking and vendor invoicing are structured to support the treatment rather than reconstructed afterward. Reconstruction after the fact is painful and, from an audit perspective, weak.
Document thoroughly. Track costs by phase, purpose, and milestone. When your auditors ask why a given consulting invoice was capitalized, “the project manager remembers it was development work” is not an answer. Contemporaneous documentation is.
Challenges and Considerations
The flexibility carries real complications. Classifying work by development phase is genuinely tricky on agile projects, where design, build, and refinement interleave; expect judgment calls and make them consistently. Capitalization also improves short-term profitability at the cost of future amortization expense, and that trade-off belongs to the CFO, not to IT’s preference for a friendlier budget year. And the cloud keeps evolving faster than the guidance, so treat this as a standing conversation with your finance team rather than a settled policy.
Best Practices for CIOs
First, build financial fluency into IT leadership; a CIO who can discuss amortization schedules credibly is a better partner and gets better outcomes. Second, structure project plans with accounting phases in mind, since a little planning discipline makes the capitalization analysis nearly free. Third, keep your executive peers educated on how these rules affect what they see in the numbers; the transparency builds trust that pays off at budget time.
Looking Ahead
The standards will keep adjusting as cloud-first and hybrid strategies become the default. For Drummond, the ability to capitalize significant portions of our cloud and software implementation work has helped balance short-term financial demands against longer-term investment. Understanding these details is not the glamorous part of the CIO role, but it is part of the role, and it compounds quietly in your favor.
Sources:
- Financial Accounting Standards Board (FASB); www.fasb.org
- Journal of Accountancy: “How Cloud Computing Changes Accounting Practices”; www.journalofaccountancy.com