Capitalizing Software Development Costs: Rules and Best Practices

Capitalizing software development costs means recording qualifying development spending as an intangible asset on the balance sheet and amortizing it over the software's useful life, instead of expensing it all in the period it is incurred. Under US GAAP, internal-use software follows ASC 350-40 and software you sell or license follows ASC 985-20, and each has its own test for when capitalization starts. The rules for internal-use software were updated in 2025, so many companies will need to revisit their policies.

This guide is written for founders, finance leads and product owners who need a working understanding. It is not accounting advice: confirm your treatment with your auditor or CPA.

Expense versus capitalize: the core difference

When you expense a cost, it reduces profit in the period you spend it. When you capitalize it, the cost becomes an asset and moves to the income statement gradually through amortization. The total cost is the same either way. What changes is timing, and timing affects reported profit, margins and how the business looks to lenders and investors.

Internal-use software under ASC 350-40

Internal-use software is software you build or buy for your own operations and do not plan to sell: an internal ERP extension, a customer portal, or the platform behind a SaaS product where customers do not take possession of the software. Hosted SaaS platforms generally fall here, not under the rules for software sold to customers.

What changed with ASU 2025-06

In 2025 the FASB issued ASU 2025-06, Targeted Improvements to the Accounting for Internal-Use Software. The old guidance tied capitalization to three project stages: a preliminary project stage (expensed), an application development stage (capitalized) and a post-implementation stage (expensed). Those stages fit waterfall projects but were hard to apply to agile teams that plan, build and release in short cycles.

The update removes the references to project stages. Instead, capitalization begins when both of these are true:

• Management has authorized the project and committed to funding it.
• It is probable the project will be completed and the software will be used to perform the function intended.

The probability test has to consider whether there is significant uncertainty in the development itself, for example novel features that have not been proven or performance requirements that are still unclear. Where that uncertainty exists, costs are expensed until it is resolved. The update also folds the guidance on website development costs into the same subtopic. According to the ASU, it takes effect for annual periods beginning after December 15, 2027, with early adoption permitted. Check the standard and your auditor for the transition method that suits you.

Costs that typically qualify

• Payroll and benefits of employees directly working on coding, configuration and testing.
• Fees paid to external developers for build work.
• Costs to obtain software from third parties that becomes part of the asset.
• Interest costs in some cases, under the separate interest capitalization rules.

Costs that are usually expensed

• Early research, idea evaluation and vendor selection.
• Training and data conversion (other than building conversion software).
• General and administrative overhead.
• Maintenance, bug fixes and minor upgrades that do not add functionality.

Software for sale under ASC 985-20

Software you sell, license or market to customers follows ASC 985-20, which ASU 2025-06 does not change. Here, costs are expensed as research and development until the product reaches technological feasibility. That point is reached when the company has completed a detailed program design or, without one, a working model. Costs incurred after that, up to general release, can be capitalized.

In practice, many software companies reach technological feasibility very late, close to release, so the amount capitalized under this standard is often small. That is one reason companies selling packaged or downloadable software capitalize less than you might expect.

Best practices for capitalizing software costs

Write a clear capitalization policy

Document which projects qualify, what evidence shows management authorization and funding, how you judge probable completion and significant development uncertainty, which cost types are included and the minimum threshold below which you simply expense. A written policy keeps decisions consistent across teams and years, and auditors will ask to see it.

Track time and costs by project and activity

The biggest practical challenge is separating capitalizable development work from maintenance and support. Use time tracking or ticket tagging that links engineering effort to a project and to the type of work, such as new feature, bug fix or support. Many teams map their issue tracker categories directly to capitalization rules.

Keep thorough documentation

Keep the authorization approvals, funding decisions, scope documents, release records and the reasoning behind each judgment. If a project is paused or its scope changes, record it. Good documentation is what turns a judgment call into something an auditor can verify.

Choose a sensible useful life and review for impairment

Amortization usually starts when the software is ready for its intended use and runs on a straight line basis over its expected useful life. Pick a period that reflects how long the software will actually deliver value, and review it when plans change. If a project is abandoned or the software becomes obsolete, test for impairment and write down the asset.

Benefits of capitalizing development costs

• Smoother reported results. Large build phases do not produce sudden drops in profit, which makes trends easier to read.
• Costs matched to benefits. The expense appears over the years the software generates value, which many argue is a fairer picture.
• Better project discipline. The tracking needed for capitalization also gives management clearer data on what each project costs.
• A clearer view of investment. The balance sheet shows what the company has invested in technology assets.

Challenges and considerations

Tax treatment can differ from book treatment

US tax rules for software development spending are separate from GAAP and have changed more than once in recent years. What you capitalize for your financial statements may be deducted differently on your tax return. Work with a tax adviser so book and tax treatments are reconciled and you do not miss available deductions or credits.

Judgment and audit risk

Capitalization requires judgment on probability, uncertainty and useful life. Aggressive capitalization inflates profit and draws scrutiny from auditors and investors. Conservative, well documented decisions are easier to defend.

Agile and continuous delivery

Even under the new rules, teams that ship continuously need a way to separate new functionality from ongoing maintenance. Decide early how you will classify work in each sprint, so the finance team is not reconstructing it at year end.

Special situations

• Open source components. Costs to integrate or modify open source code can qualify if they are part of building functionality that meets the criteria. The open source software itself usually carries no cost to capitalize.
• Internal software later sold. If software built for internal use is later marketed externally, the accounting may need to change. Review the treatment with your auditor at the point the plan changes.
• Cloud computing arrangements. Implementation costs for a hosted service you buy, rather than build, follow related but separate guidance. Do not assume the same policy applies.
• MVPs and pilots. An early prototype built to test whether an idea works may still carry significant development uncertainty, which points toward expensing until that uncertainty is resolved.

Good capitalization starts with good project data: clear scopes, tracked effort and documented releases. If you are planning custom software, agree up front how scope, effort and releases will be recorded so your finance team can use them. Codeeo's product scoping session helps define what will be built and when, and our dedicated developers model gives you a team whose time maps cleanly to your projects. For finance products specifically, see our fintech work.