Software Development Costs: How to Capitalize or Expense Them in 2026

Yury Pukhov CEO & Mobile Engineering Lead, YuSMP Group

Software development costs are the money you spend on people, contractors, tools and infrastructure to design, build and test software — and in 2026 the harder question is no longer only how much they are, but where they land in your financial statements. The same $500,000 can be a one-year hit to operating profit or an asset that is spread over three to five years, depending on what the money was spent on, when, and under which accounting standard.

Accounting for software development costs usually becomes urgent at a predictable moment: the first audit, a fundraising round or the first large invoice from an outside team. Companies that buy product engineering services for software companies often meet the question when the auditor asks them to split a vendor’s monthly invoices into research, new functionality and maintenance — and nobody planned for that split when the contract was signed.

Two changes make 2026 a good year to revisit your policy. In the US, the FASB’s ASU 2025-06 rewrites the internal-use software rules for the first time in decades, and the One Big Beautiful Bill Act restored immediate tax deduction of domestic research and experimental expenditures through new Section 174A. This guide explains both, alongside the IFRS rules many European companies follow. It is general information, not tax or audit advice: confirm your policy with your auditor and tax adviser.

What are software development costs?

Software development costs are all costs directly attributable to creating software: in-house payroll, contractor and agency fees, licences and tools, cloud environments and data work used during the build. Indirect costs such as office rent or general management are part of the cost of running the business, but accounting standards rarely let you treat them as part of the software asset.

For accounting, it helps to sort costs by nature first and by activity second. The nature tells you what was paid; the activity, covered in the next section, tells you whether it can be capitalized. The table summarises the usual components and their typical treatment under US GAAP for internal-use software.

This article focuses on how those costs are recorded, not on what they should be. If you need price ranges by project type, team size and region, see our software development cost benchmarks for 2026.

Should software development costs be capitalized or expensed?

Software development costs are capitalized when they create or add functionality to software that will deliver future benefits and the relevant accounting threshold has been met; everything else is expensed as incurred. In practice that means research, planning, maintenance, training and overhead go to the income statement, while design, coding and testing of new functionality can become an asset.

The decision is made activity by activity, not invoice by invoice. A single sprint can contain capitalizable work on a new module, expensed bug fixes on an old one and expensed research spikes. The table shows the typical outcome for internal-use software under US GAAP; IFRS reaches similar results for most rows but through a different test, explained later.

The deciding test for post-launch work is simple to state and hard to apply: does it give the software a capability it did not have before? A new reporting module passes; refactoring for performance or fixing defects usually does not. Write the rule down, give examples, and apply it the same way every month.

How does ASC 350-40 work for internal-use software today?

Under current ASC 350-40, internal-use software follows a three-stage model: costs in the preliminary project stage are expensed, costs in the application development stage are capitalized, and costs in the post-implementation and operation stage are expensed. Until a company adopts ASU 2025-06, this remains the rule for US GAAP reporters.

Internal-use software is software acquired, built or modified solely to meet the company’s internal needs, with no substantive plan to market it externally. That covers ERP customisations, internal tools, customer portals and, importantly, most SaaS platforms, which are covered below.

The three stages

• Preliminary project stage — conceptual formulation, evaluation of alternatives, determination of required technology and final selection. All costs are expensed.
• Application development stage — design of the chosen path, coding, installation of hardware, and testing including parallel processing. Capitalization starts when the preliminary stage is complete, management authorizes and commits to funding the project, and it is probable that the project will be completed and the software used as intended.
• Post-implementation and operation stage — training and maintenance. Capitalization stops when the software is substantially complete and ready for its intended use, which generally means after all substantial testing is finished.

What you can and cannot capitalize

Capitalizable costs are external direct costs of materials and services consumed in developing the software, payroll and payroll-related costs of employees directly associated with the project to the extent of their time spent on it, and interest costs incurred during development under ASC 835-20. General and administrative costs, overhead, training and data conversion are expensed even when they occur during the application development stage.

Cloud computing arrangements: implementation costs of SaaS you buy

When your company is the customer of a hosted SaaS product, implementation costs follow the same ASC 350-40 stage rules under ASU 2018-15, even though you never own the software. Costs of configuring, integrating and testing the hosted solution during the application development stage are capitalized, amortized over the term of the hosting arrangement including reasonably certain renewals, and presented in the same income-statement line as the subscription fees. The subscription fee itself stays an operating expense.

For companies running several systems at once, these rules apply to every integration project. Our custom software development teams document configuration and integration work separately from support for exactly this reason.

What does ASU 2025-06 change?

ASU 2025-06, issued by the FASB on 18 September 2025, removes the three project stages from ASC 350-40 and replaces them with a single recognition threshold: capitalize once management has authorized and committed to funding the project and it is probable that the project will be completed and the software used to perform its intended function. Advisers such as RSM describe it as the largest revision of internal-use software accounting since 1998, driven largely by agile development.

The stage model assumed a linear, waterfall project where planning ended before coding began. Agile teams plan, design, build and test in every sprint, so the stages never mapped cleanly onto their work. The new standard drops that assumption and asks a more practical question about uncertainty.

The probable-to-complete threshold and significant development uncertainty

When judging whether completion is probable, a company must consider whether there is significant development uncertainty. The standard gives two indicators:

• the software has novel, unique or unproven functions or features, and the uncertainty about them has not yet been resolved through coding and testing;
• the significant performance requirements have not been identified or are still being significantly revised.

While either indicator is present, the threshold is not met and costs are expensed. That can delay capitalization for experimental products — a new machine-learning feature, for example — while making capitalization start earlier and more predictably for routine builds such as a customer portal on proven technology.

Old three-stage model vs ASU 2025-06

Effective date and transition options

ASU 2025-06 is effective for annual reporting periods beginning after 15 December 2027 and interim periods within them, which means fiscal 2028 for calendar-year companies. Early adoption is permitted as of the beginning of an annual reporting period. Companies can adopt it in one of three ways:

• Prospectively — apply the new rules to costs incurred after adoption;
• Modified transition — apply them to projects still in progress at adoption, with a cumulative-effect adjustment to opening retained earnings;
• Retrospectively — restate prior periods presented.

Should you early-adopt in 2026?

Early adoption makes sense for companies whose development is mostly agile and routine, and less sense for companies with heavy experimental work or investors who compare periods closely. Weigh these points with your auditor:

• For: less manual mapping of sprints to stages, and fewer judgement calls to document each quarter.
• For: a policy that matches how agile and product teams actually work, which is easier to explain to new auditors and investors.
• For: website development costs move into the same model, so one policy covers the product and the marketing site.
• Against: policies, controls and system configuration have to be rewritten before the year of adoption begins.
• Against: projects with novel features may capitalize later than today, lowering reported assets and operating profit in the short term.
• Against: comparability with prior periods suffers under the prospective method, and full restatement takes effort.
• Either way: the new ASC 360-10 style disclosures need data — asset roll-forwards, useful lives and impairments — that many companies do not collect today.

How do you account for software you sell or license (ASC 985-20)?

Software to be sold, leased or otherwise marketed follows ASC 985-20: all costs are expensed as research and development until technological feasibility is established, and only costs incurred after that point and before general release are capitalized. Because feasibility often arrives late in the project, most companies under ASC 985-20 capitalize very little.

Technological feasibility is established when the company has completed a detailed program design or, without one, a working model of the product. Teams that do not write a detailed program design up front — the usual case in agile development — reach a working model close to the end of development, so the capitalizable window may be a few weeks of final testing and production of product masters.

Capitalized costs are amortized product by product, using the greater of two amounts: the ratio of current gross revenue to total current and expected future revenue, or straight-line amortization over the product’s remaining estimated economic life. At each balance sheet date, the unamortized balance is compared with net realizable value and written down if it is higher. ASU 2025-06 does not change any of this.

Where do SaaS products fall?

Most SaaS products fall under ASC 350-40 as internal-use software, not under ASC 985-20. If customers only access the software through a hosting arrangement and have no contractual right to take possession of it and run it themselves, the provider is using the software internally to deliver a service. Founders often assume that “we sell software” means ASC 985-20, which leads to expensing development that could have been capitalized — or to inconsistent policies once an on-premise version is added. If you are planning or scaling a SaaS platform, our guide to SaaS software development covers the product side of the same decisions.

How are software development costs treated under IFRS (IAS 38)?

Under IFRS, IAS 38 Intangible Assets splits every internal project into a research phase, which is always expensed, and a development phase, which must be capitalized once the company can demonstrate all six criteria in paragraph 57. Unlike US GAAP, IFRS uses the same model whether the software is used internally or sold.

The six criteria in IAS 38 require the company to demonstrate:

1. the technical feasibility of completing the software so that it will be available for use or sale;
2. its intention to complete the software and use or sell it;
3. its ability to use or sell the software;
4. how the software will generate probable future economic benefits, for example a market for it or its usefulness internally;
5. the availability of adequate technical, financial and other resources to complete the development and use or sell the software;
6. its ability to measure reliably the expenditure attributable to the software during development.

When all six are met, capitalization is required, not optional. If a company cannot tell the research phase from the development phase, IAS 38 treats the whole project as research and expenses it. Capitalized software is amortized over its useful life and tested for impairment under IAS 36; software not yet available for use must be tested at least annually. The revaluation model is allowed only where an active market exists, which is practically never the case for bespoke software.

For SaaS that a company buys rather than builds, IFRS differs from ASU 2018-15. Following IFRS Interpretations Committee agenda decisions in 2019 and 2021, configuration and customisation costs of a cloud service the customer does not control are usually expensed, unless they create a separate asset the customer controls, such as bespoke code.

US GAAP vs IFRS at a glance

Groups reporting under both frameworks — a European parent with a US subsidiary, for example — should track costs at the level of detail the stricter framework needs and derive both results from the same data.

How should you amortize capitalized software?

Amortization of internal-use software starts when the software is ready for its intended use and usually follows the straight-line method over the estimated useful life. Many companies use three to five years, but that is common practice rather than a rule: the period should reflect how long the software will realistically deliver value before it is replaced or rebuilt.

• Start date — when the software, or a separately usable module, is substantially complete and ready for use, even if it has not yet been rolled out to all users.
• Method — straight-line unless another pattern better reflects how benefits are consumed; ASC 985-20 software uses the greater of the revenue-based and straight-line amounts.
• Useful life — consider your release history, the pace of change in the underlying technology and any plan to replace the platform.
• Reviews — revisit useful lives at least annually and adjust prospectively if expectations change.
• Impairment triggers — abandoning the project, a major change in how the software is used, cost overruns far beyond plan or a decision to replace it early.
• Abandoned projects — when completion is no longer probable, stop capitalizing and write the asset down; do not keep carrying it.

How do taxes treat software development costs in 2026 (Section 174A)?

For US federal tax, the One Big Beautiful Bill Act of July 2025 added Section 174A, which lets companies deduct domestic research and experimental expenditures — explicitly including software development — in the year they are incurred, for tax years beginning after 31 December 2024. Research performed outside the United States must still be capitalized and amortized over 15 years under Section 174.

The foreign rule matters for anyone who builds software with an offshore or nearshore team. US-performed development is now deductible immediately, while the same work done abroad is spread over 15 years. That difference should be part of any total-cost comparison between in-house, onshore and offshore delivery.

• Small businesses with average annual gross receipts of $31 million or less can apply the domestic expensing retroactively to tax years beginning after 31 December 2021 by amending their 2022–2024 returns.
• Other taxpayers can deduct the remaining unamortized domestic Section 174 balance from 2022–2024 in full in 2025 or spread it evenly over 2025 and 2026.
• Procedure — the IRS set out the elections and accounting-method changes in Rev. Proc. 2025-28.
• Book vs tax — tax and financial reporting no longer move together: a capitalized asset on the books with an immediate tax deduction creates a deferred tax liability that needs tracking.

Section 174A governs the deduction; the research credit under Section 41 is a separate benefit with its own four-part test. Our guide to the R&D tax credit for software development explains eligibility and documentation in detail.

How do you track capitalizable costs in an agile team?

To track capitalizable costs in an agile team, tag work at the epic and ticket level as new functionality, maintenance or research, record time by person and epic, and require outside vendors to invoice in the same structure. Done this way, capitalization becomes a monthly report rather than a quarter-end reconstruction.

1. Write a capitalization policy. Define which activities are capitalized, the threshold you apply (stage-based or ASU 2025-06), a minimum project size, default useful lives and who approves exceptions.
2. Tag epics and tickets. Every epic gets a category — new functionality, enhancement, maintenance, research or infrastructure — and tickets inherit it. Product owners set the tag; finance reviews it.
3. Record time by person and epic. Lightweight weekly time allocation per epic is enough; minute-level timesheets are not required, but estimates must be reasonable and consistent.
4. Set rules for contractors. Ask development vendors to invoice by epic or feature with hours per role, so external costs can be classified the same way as payroll.
5. Close monthly. Cut off at month end, calculate capitalizable payroll and vendor costs, book the entries and move completed modules into service so amortization starts on time.
6. Keep the evidence. Store funding approvals, roadmaps, release notes and the reasoning behind probable-to-complete judgements; auditors will ask for them.
7. Review quarterly. Check tagging quality, re-test useful lives and look for abandoned or stalled projects that need impairment.

What are the most common mistakes in software development accounting?

The most common mistakes in software development accounting are capitalizing work that is still research, capitalizing maintenance, picking the wrong standard for SaaS and failing to document judgements. Each one tends to surface in the first serious audit, when fixing it is most expensive.

• Capitalizing research and prototypes — proof-of-concept spikes and experiments before funding is approved belong in expense.
• Capitalizing maintenance — bug fixes, refactoring and minor UI tweaks do not add functionality, even when they take a whole sprint.
• Treating SaaS as ASC 985-20 — hosted products without a customer right to take possession are internal-use software.
• Loading overhead into the asset — rent, HR and general management are expensed for internal-use software.
• No evidence for probable completion — without funding approvals and roadmaps, auditors may push the start of capitalization later.
• Forgetting impairment — an abandoned module still sitting on the balance sheet overstates assets.
• Treating foreign development as domestic for tax — work performed outside the US is amortized over 15 years, not deducted under Section 174A.

Worked example: one $600k build, two accounting outcomes

The same $600,000 build can produce a $480,000 asset or a $40,000 asset depending on which US GAAP model applies. The example below is hypothetical, uses round numbers and assumes the project meets the funding and probable-completion conditions after discovery; it illustrates the mechanics rather than any real company.

Outcome A treats the product as internal-use software or a SaaS platform under ASC 350-40. Outcome B treats it as licensed software sold for customers to install under ASC 985-20, with technological feasibility established through a working model late in testing.

In Outcome A, amortizing $480,000 straight-line over four years adds $120,000 of amortization a year. If the software goes live at the start of the year, the first-year income-statement charge is $240,000 ($120,000 expensed plus $120,000 amortization) instead of $600,000. In Outcome B, almost the whole build reduces operating profit in the year it is spent.

ASU 2025-06 adds a third possibility to Outcome A. If $150,000 of the coding relates to a novel feature whose uncertainty was only resolved late in development, that amount is expensed under the new rules. The capitalized asset falls to $330,000 and annual amortization over four years to $82,500. The arithmetic is simple; the judgement about uncertainty is what needs documentation.

FAQ

Published 26 October 2026. Sources: FASB ASU 2025-06 full text via PwC Viewpoint; Deloitte DART Heads Up (2025); AICPA & CIMA, RSM US and Grant Thornton commentary on ASU 2025-06; IFRS Foundation, IAS 38 Intangible Assets; Baker Newman Noyes and Kaufman Rossin on Section 174A and Rev. Proc. 2025-28; The Tax Adviser (AICPA) on defining software development costs. This article is general information, not accounting, audit or tax advice.