Software Capitalization and Technical Debt

Accounting rules decide whether your engineering work becomes an asset on the balance sheet or a cost against this quarter's earnings. Debt paydown almost always lands in the expensive column.

This is the mechanism behind budget decisions that look irrational from an engineering seat. Refactoring hits operating income immediately. A rebuild may not. Understand the accounting and you stop losing arguments you should be winning.

Read This First: General Information, Not Advice

This page explains accounting concepts so engineers and engineering leaders can have a productive conversation with their finance organization. It is general information. It is not accounting, tax, audit, or legal advice, and nothing here creates a professional relationship.

Capitalization treatment varies by company, by reporting framework, by jurisdiction, by materiality threshold, and by the judgment of your external auditor. Two companies doing identical engineering work can legitimately reach different answers. Before you change how anything is recorded, confirm the treatment with your own controller, CFO, and audit firm. Nothing on this page describes any specific company's policy, and no policy described here should be assumed to be universal.

Why Engineers Need to Understand This

Most engineering leaders learn to argue for technical debt work in engineering terms: velocity, defect rates, incident counts, developer experience. Those arguments are correct and they are frequently ignored, because the person deciding is not weighing your argument against another engineering argument. They are weighing it against a number on a financial statement.

Software capitalization is the accounting mechanism that determines whether the money spent on a piece of engineering work shows up as an expense that reduces this period's operating income, or as a capitalized asset that sits on the balance sheet and is charged to income gradually over several years. Same engineers. Same salaries. Same cash out the door. Radically different effect on the numbers your executives are measured on.

The consequence is uncomfortable. A large greenfield rebuild frequently qualifies for capitalization. Incremental refactoring of an existing system frequently does not. If a CFO is under pressure to protect operating margin this year, the accounting treatment quietly rewards the rebuild and punishes the refactor, even in cases where every engineer in the building knows the refactor is the better decision. That is not finance being obstructive. It is the rules working exactly as written.

You do not need to become an accountant. You need to know enough to ask the right questions, to structure and document proposals so that legitimately capitalizable work is recognized as such, and to recognize when the answer to "why was the rewrite approved and the cleanup was not" is an accounting answer rather than a technical one. If you are also building the business case, pair this page with selling tech debt work to management.

CapEx and OpEx: The Two Buckets

Every dollar of engineering effort lands in one of two buckets. The bucket is not chosen for convenience; it is determined by what the work does and when it happens.

Capitalized (CapEx)

The cost is recorded as an intangible asset rather than an immediate expense. It appears on the balance sheet and is then amortized, meaning a slice of it is charged against income each period across the asset's estimated useful life.

Softens the hit to current-period operating income
Spreads cost across the periods that benefit from the work
Typically requires timesheets or a defensible effort allocation
Creates an asset that must later be amortized, reviewed, and possibly written off

Expensed (OpEx)

The cost is charged against income in the period it is incurred. There is no asset. The full amount reduces operating income now, in the quarter the work happens.

Immediate, visible reduction in reported profit
Simpler to administer, no tracking of asset lives
Where routine maintenance and bug fixing normally land
Where most technical debt paydown normally lands

Cash does not care. Both treatments spend the same money at the same time, and both reduce cash flow identically in the period the salaries are paid. Capitalization changes the timing of the charge to income, not the cash. That distinction is why an engineering leader who talks only about cost is talking past the person who is actually being measured on operating income, earnings, and margin.

ASC 350-40: The US GAAP Stage Model

In US GAAP, software a company builds for its own use is governed by FASB Accounting Standards Codification Subtopic 350-40, Intangibles - Goodwill and Other - Internal-Use Software. For decades its central device has been a three-stage model: the accounting treatment of a cost depends on which stage of the project the cost was incurred in.

Stage 1: Preliminary Project Stage - Expense

Conceptual formulation, evaluating alternatives, determining required technology, and vendor selection. According to accounting firm EisnerAmper's 2023 guidance on ASC 350-40, internal and external costs incurred during the preliminary project stage are expensed as they are incurred. This is the discovery work, the spikes, the architecture bake-offs, and it all lands in operating expense.

Stage 2: Application Development Stage - Capitalize

Coding, configuration, interface development, installation of hardware, and testing including parallel processing. This is the stage where qualifying internal payroll and external contractor costs are capitalized. Note that not everything in this window qualifies. Training costs and data conversion costs are generally excluded even when they happen concurrently with development, which is exactly the sort of detail that makes effort tracking necessary.

Stage 3: Post-Implementation and Operation - Expense

Once the software is substantially complete and ready for its intended use, the capitalization window closes. EisnerAmper's 2023 guidance states that internal and external costs incurred during the post-implementation-operation stage are expensed as incurred. Training, support, and ongoing maintenance all sit here. So does the overwhelming majority of what an engineering team does across a system's real lifetime.

The Upgrades and Enhancements Carve-Out

The stage model has one door left open after go-live. Work on already-deployed software that provides additional functionality can be treated as an upgrade or enhancement and capitalized, while work that merely keeps existing functionality running cannot. Cohen & Company's 2024 guidance puts the rule bluntly: expense maintenance and bug fixes as incurred. That single sentence is where most technical debt work goes to die, and it is worth reading twice before you write your next proposal.

What Changes Under ASU 2025-06

The stage model was written for a world of sequential, waterfall-shaped software projects, and it has aged badly against continuous delivery. FASB responded with Accounting Standards Update 2025-06, published by AICPA and CIMA under its full title, Intangibles - Goodwill and Other - Internal-Use Software (Subtopic 350-40): Targeted Improvements to the Accounting for Internal-Use Software, issued September 18, 2025.

According to BDO USA's 2025 summary, the ASU removes all references to project stages in ASC 350-40 and provides a principles-based recognition threshold to determine capitalizable software costs. BDO gives the effective date as annual reporting periods beginning after December 15, 2027, including interim reporting periods within those annual reporting periods, with early adoption permitted.

RSM US described the change in 2025 as removing the need to differentiate between project stages, making the rules neutral to development methodology and more operable for iterative environments. Under the amended guidance, capitalization begins when management has authorized and committed to funding the project and it is probable the project will be completed and the software will be used to perform the function intended - and it is deferred while there is significant uncertainty about the development, for example where the work depends on novel or unproven functionality whose uncertainty has not yet been resolved through coding and testing.

What this does not change: the amendment is about when capitalization starts and how the rules map onto modern delivery. It does not reclassify maintenance as a capital asset, and it does not turn refactoring into an investment. If your read of the ASU is "great, now we can capitalize the cleanup," take that to your auditor before you take it to your board. Also note the effective date: unless your company early-adopts, the stage model above is still the operative guidance for the next couple of reporting cycles.

IAS 38: The IFRS View

If your company reports under IFRS rather than US GAAP, ASC 350-40 does not apply to you. The relevant standard is IAS 38, Intangible Assets, and it uses a different frame: instead of project stages it splits spending into a research phase and a development phase. The IFRS Foundation's summary of the standard states plainly that research expenditure is recognised as an expense, and that development expenditure that meets specified criteria is recognised as the cost of an intangible asset.

The specified criteria are the six conditions in IAS 38. All six must be demonstrated before any development cost can be capitalized:

Technical feasibility of completing the asset so that it will be available for use or sale
Intention to complete the asset and use or sell it
Ability to use or sell the asset
How the asset will generate probable future economic benefits
Availability of adequate technical, financial and other resources to complete the development and to use or sell it
Ability to reliably measure the expenditure attributable to the asset during its development

The criteria list is from KPMG's 2025 comparison of research and development cost treatment under IFRS Accounting Standards and US GAAP. That same comparison highlights the difference that trips up multinational teams: under US GAAP, research and development costs in the scope of ASC 730 are expensed as incurred, whereas IAS 38 requires capitalization once the six criteria are met. Internal-use software under US GAAP escapes the blanket ASC 730 expensing rule because it falls under ASC 350-40 instead, which is the entire reason software capitalization exists in US GAAP at all.

The practical difference for a debt conversation is the direction of the default. Under US GAAP the question tends to be framed as "may we capitalize this?" Under IFRS, once the criteria are met, capitalization is not optional. Either way, refactoring an existing production system rarely presents a clean story about future economic benefits from a newly created asset, which is where the argument usually stalls.

The Core Problem: Accounting Can Reward the Worse Engineering Decision

Here is the mechanism, stated as plainly as it can be stated. Building new functionality can often be capitalized. Maintaining, repairing, and improving what already exists usually cannot. Cohen & Company's 2024 guidance on internal-use software says to expense maintenance and bug fixes as incurred, and the same logic captures most of what engineers mean by paying down technical debt: restructuring code, replacing a fragile module, removing duplication, upgrading a framework, adding the tests that should have existed. None of it delivers new functionality to a user. All of it is real, valuable engineering. Most of it hits operating income this quarter.

Now put a rewrite next to it. A ground-up replacement of the same system is a new project with a defined scope, a development phase, and, at the end, a new asset that does things the old system could not. That story maps cleanly onto the capitalization criteria in a way "we are going to spend two quarters making the existing system less awful" never will.

So two proposals arrive on a CFO's desk. The refactor costs three million dollars and reduces operating income by three million dollars this year. The rewrite costs eight million dollars, and a substantial share of it is capitalized and charged to income over the following several years. The rewrite consumes more cash, carries far more delivery risk, and - as anyone who has read the rewrite versus refactor literature knows - fails more often. It also looks better on this year's income statement.

This is not a conspiracy and it is not incompetence. It is a genuine, structural incentive that almost no engineering organization ever names out loud, because engineers rarely see the accounting and accountants rarely see the codebase. It explains a category of decision that looks inexplicable from the inside: why "let us rebuild it" keeps beating "let us fix it," why cleanup work is perpetually deferred to a quarter with slack in it, and why the answer to a well-argued refactoring proposal is sometimes a flat no with no engineering counter-argument attached.

What to do about it. Do not try to win by getting refactoring reclassified. That is the auditor's call, not yours, and pushing it is how companies end up restating results. Win by making the true comparison visible: the rewrite's total cash cost, its delivery risk, the cost of running two systems in parallel, the features not shipped during the migration, and the fact that a rewritten system starts accruing debt from its first commit. Then show what happens to income across three to five years rather than one. If the refactor is genuinely better, it usually wins on a multi-year view even when it loses on a single-year view. Make the finance team your co-author on that model rather than your audience.

Amortization: The Accounting Version of Interest

Capitalizing a cost does not make it disappear. It defers it. Once the software is ready for its intended use, the capitalized amount is amortized: charged to income in slices over the asset's estimated useful life. Cohen & Company's 2024 guidance describes the common practice as amortizing internal-use software on a straight-line basis over a three- to five-year life. That range is convention rather than rule; the useful life is an entity-specific estimate that has to be defensible.

The parallel to the debt metaphor is close enough to be genuinely useful. Capitalization is the borrowing. Amortization is the repayment schedule. And the schedule keeps running whether or not the asset is still doing anything useful, which produces some distinctly uncomfortable situations for debt-laden systems:

Carrying a Corpse

A platform capitalized over five years that the team abandoned in year two is still being amortized against income in years three, four, and five. The engineering organization has moved on. The income statement has not.

The Write-Off Cliff

If a capitalized system is retired or is no longer expected to deliver the service it was built for, the remaining unamortized balance generally has to be written off. Killing a bad system can therefore produce a visible, one-time charge to earnings, which is a powerful and entirely non-technical reason a doomed platform stays alive.

Stacked Schedules

Years of capitalized projects leave overlapping amortization schedules running simultaneously. A company can be paying down the accounting cost of three generations of the same system at once while the current generation is the only one anybody is running.

If you want a metric-driven version of this argument, the compound interest effect of technical debt and the practical guidance on measuring technical debt give you the engineering-side numbers to sit beside the accounting-side ones.

What Auditors Will and Will Not Accept

Capitalization is an estimate built on judgment, which makes it a standing area of audit focus. Aggressive capitalization of maintenance is a real risk, not a clever tactic.

Generally Supportable

Effort tracked against a specific, authorized project with a documented scope
Work that demonstrably delivers functionality the system did not previously have
Timesheets or a consistently applied, evidence-based allocation method
A capitalization policy written down, applied consistently period over period, and reviewed with the auditor in advance
Useful lives supported by an actual view of how long the system is expected to serve

Expect Challenge

A flat percentage of engineering headcount capitalized with no underlying evidence
Renaming maintenance as an "enhancement" without new functionality behind it
Capitalization rates that move conveniently with earnings pressure
Useful lives stretched well past the point the system will plausibly survive
Continuing to capitalize long after the software went live
Keeping a fully impaired asset on the books to avoid a write-off

Why this matters to engineers specifically. Engineering leaders are frequently the ones who classify a ticket, name an epic, or sign off on the effort split that feeds the capitalization calculation. That means an engineer's labelling decisions can end up as an input to a financial statement. Calling a refactoring epic "Platform Modernization Phase 2" because it sounds better in a roadmap review is harmless right up until someone downstream uses the name as evidence of new functionality. Describe work accurately, and let finance decide what it is. Getting this wrong is not a rounding error; systematic over-capitalization of maintenance is the kind of thing that produces restatements.

Cloud and SaaS: Hosting Arrangements and Implementation Costs

Software you subscribe to rather than build raises a different question, and FASB answered it in Accounting Standards Update 2018-15. Deloitte's 2018 Heads Up publication on the amendment states that a customer should apply ASC 350-40 to determine which implementation costs related to a hosting arrangement that is a service contract should be capitalized. In other words, the internal-use software model was extended to cover the effort of implementing somebody else's hosted software.

The amortization period differs, though. The same Deloitte publication states that an entity would be required to amortize capitalized implementation costs over the term of the hosting arrangement on a straight-line basis unless another systematic and rational basis is more representative of the pattern in which the entity expects to benefit from access to the hosted software. The subscription fees themselves remain an operating expense; only the implementation effort is potentially capitalizable.

Three consequences worth internalizing before your next build-versus-buy debate:

Buy shifts the shape of the cost. A build produces a capitalizable asset with a multi-year life. A subscription produces a recurring operating expense with a smaller capitalizable implementation component tied to the contract term. Those look very different in a budget even when the total cash is similar.
A lift-and-shift migration is not automatically an asset. Moving an existing on-premise system to the cloud without changing what it does is closer to maintenance than to new functionality. Migrations that genuinely re-architect are a different conversation from migrations that simply relocate. Be honest with finance about which one you are actually proposing.
Configuration debt has a shorter fuse. Implementation costs amortize over the contract term, so heavily customized SaaS implementations create an asset with a life bounded by a renewal date. If your cloud cost debt includes a pile of bespoke integration work, the accounting horizon may be a lot shorter than the engineering one.

How to Actually Work With Finance

The goal is not to become the person who argues about accounting. It is to become the engineering leader whose proposals finance can evaluate without a translation layer.

Ask What the Policy Is

Start with four questions. Do we capitalize internal-use software at all? What is our written capitalization policy and who owns it? What useful life do we apply? What evidence does our auditor expect for the effort split? Most engineering leaders have never asked any of these, and the answers reshape how you write every subsequent proposal.

Separate the Work Honestly

A single epic that mixes new capability with cleanup is impossible to allocate and invites an unfavorable blanket treatment. Split them at the planning stage: this stream builds new functionality, that stream restores maintainability. Honest separation is also the only version that survives an audit.

Document at the Start

Capitalization depends on evidence that existed while the work happened, not on a narrative assembled afterwards. Written scope, dated management authorization, and a record of what functionality is being added are cheap to produce up front and impossible to reconstruct at year end.

Model More Than One Year

Single-year comparisons are where refactoring loses. Show cash, operating income, and risk across three to five years, including amortization of any capitalized alternative and the write-off exposure if a rebuild is abandoned. The multi-year view is usually the honest view.

Argue Risk, Not Just Cost

Debt work that prevents outages, security incidents, or compliance failures has a value that is not about capitalization at all. Risk reduction is a language finance already speaks fluently, and it does not require the work to be an asset to be worth funding.

Bring Finance In Early

Invite your controller to the planning conversation rather than the approval conversation. A finance partner who understands why the system is fragile will structure the proposal with you. One who sees it for the first time in a funding request will simply price it.

Related Resources

For Executives

Board-level framing for technical debt, including the financial and risk language executives already use.

Selling to Management

How to build and present a technical debt business case that survives contact with a budget process.

Rewrite vs Refactor

The engineering side of the same decision, and why the rebuild option fails more often than its advocates expect.

Why Reduce Tech Debt

The cost case for paying debt down, with published figures you can cite in a funding conversation.

Measuring Tech Debt

Metrics that give a finance conversation something concrete to attach a number to.

Research and Citations

Every source behind the claims on this site, including the accounting guidance cited on this page.

Frequently Asked Questions

Usually not, and you should assume not until your own auditor says otherwise. Under the ASC 350-40 model, work on already-deployed software qualifies as a capitalizable upgrade or enhancement only when it provides additional functionality. Cohen and Company's 2024 guidance on internal-use software states the corollary directly: expense maintenance and bug fixes as incurred. Pure refactoring changes the internal structure without changing behavior, which is the definition of not adding functionality. Where refactoring is genuinely inseparable from building a new capability, some of that combined effort may fall inside a capitalizable project, but that determination belongs to your finance team and your external auditor, not to engineering.

Because a rewrite looks like a new project that produces a new asset, and a refactor looks like maintaining an existing one. New development can often be capitalized and charged to income over several years, while maintenance is expensed immediately. A three million dollar refactor can therefore reduce this year's operating income by three million dollars, while an eight million dollar rewrite reduces it by far less in year one even though it consumes more cash and carries more delivery risk. This is a genuine structural incentive, not a conspiracy, and the way to counter it is to model cash, income, and risk across three to five years rather than one, so that the rewrite's full cost and failure probability are visible next to its favorable first-year optics.

The preliminary project stage, the application development stage, and the post-implementation and operation stage. EisnerAmper's 2023 guidance on ASC 350-40 states that internal and external costs incurred during the preliminary project stage are expensed as they are incurred, and that internal and external costs incurred during the post-implementation-operation stage are expensed as incurred. Qualifying costs in the middle stage, the application development stage, are the ones that can be capitalized, although training and data conversion costs are generally excluded even when they occur during that window. Note that FASB's Accounting Standards Update 2025-06 removes the project-stage model in favor of a principles-based threshold for reporting periods beginning after December 15, 2027.

IFRS uses IAS 38, Intangible Assets, which splits spending into a research phase and a development phase rather than into project stages. The IFRS Foundation states that research expenditure is recognised as an expense, and that development expenditure that meets specified criteria is recognised as the cost of an intangible asset. Those criteria are the six conditions covering technical feasibility, intention to complete, ability to use or sell, probable future economic benefits, adequate resources, and reliable measurement of the expenditure. The practical difference is the default: under IFRS, capitalization is required once all six criteria are met rather than being a treatment you request. Either way, restructuring an existing production system rarely presents a clean case for a newly created asset.

There is no fixed number in the standard; the useful life is an entity-specific estimate that has to be defensible. In practice a common convention is described by Cohen and Company's 2024 guidance, which says companies amortize internal-use software on a straight-line basis over a three- to five-year life. For implementation costs in a cloud hosting arrangement the period is different again: those are amortized over the term of the hosting arrangement. The practical consequence for debt-laden systems is that the amortization schedule keeps running even after the team has abandoned the software, and retiring a capitalized system early can trigger a write-off of the remaining unamortized balance, which is a powerful non-technical reason a doomed platform stays alive.

Yes. Capitalization is an estimate built on judgment, which makes it a standing area of audit focus. Auditors generally look for effort tracked against a specific authorized project, evidence that the work delivers functionality the system did not previously have, a written policy applied consistently period over period, and useful lives that reflect how long the system will realistically serve. They tend to challenge flat percentages applied to headcount with no supporting evidence, maintenance relabelled as enhancement, capitalization rates that move with earnings pressure, and capitalization that continues long after go-live. Engineers matter here because the way a ticket or epic is named and classified can become an input to a financial statement. Describe work accurately and let finance classify it.

Speak Your CFO's Language

Debt arguments fail in finance meetings for accounting reasons, not engineering ones. Learn the mechanism, model more than one year, and bring finance in before the funding request.

Selling to Management For Executives Research and Citations