Internally developed software is an intangible asset when it meets the recognition criteria in U.S. GAAP or IFRS: the software must be identifiable, controlled by the company, and expected to produce future economic benefits. When those tests are met, qualifying development costs sit on the balance sheet and are amortized over the software’s useful life. When they are not, every dollar spent is expensed as incurred. Two 2025 developments have reshaped the mechanics: FASB’s ASU 2025-06 replaced the long-standing stage-based capitalization model for internal-use software, and a new Section 174A of the Internal Revenue Code restored full expensing of domestic software development costs for tax purposes.
What Makes Software an Intangible Asset
Three conditions have to hold before any intangible, software included, earns a spot on the balance sheet. The asset must be identifiable, meaning it can be separated from the business and sold, licensed, or transferred on its own. The company must control it, with the legal ability to prevent others from using it or benefiting from it. And it must generate probable future economic benefits, either through revenue or measurable cost savings.
In the United States, ASC 350-40 governs internal-use software.1Financial Accounting Standards Board. Accounting Standards Update 2025-06 – Intangibles Goodwill and Other Internal-Use Software (Subtopic 350-40) Under IFRS, IAS 38 sets similar thresholds, allowing capitalization of development expenditures only when the company can demonstrate technical feasibility, intent to complete, and the ability to measure costs reliably.2IFRS Foundation. IAS 38 Intangible Assets Fail any test and the project’s spending hits the income statement.
When Capitalization Begins
The Current Three-Stage Model
Most companies still apply the stage-based framework. It splits the development timeline into three phases. During the preliminary project stage, teams brainstorm, evaluate technology, and decide whether to move forward; all costs are expensed. Once management formally authorizes the project and completion becomes probable, the work enters the application development stage, and qualifying costs from that point forward are capitalized. Capitalization ends when the software is substantially complete and ready for its intended use. Post-implementation spending, like routine maintenance and minor fixes, is expensed again.
The Probable-to-Complete Model Under ASU 2025-06
FASB issued ASU 2025-06 in 2025, eliminating the rigid three-stage boundaries for internal-use software.1Financial Accounting Standards Board. Accounting Standards Update 2025-06 – Intangibles Goodwill and Other Internal-Use Software (Subtopic 350-40) The new principles-based test has two triggers. Someone with the relevant authority must have implicitly or explicitly committed to funding the project, and it must be probable the software will be finished and used for its intended function. Once both conditions are met, capitalization starts.
The trade-off is more flexibility for more judgment. Significant development uncertainty, like unresolved novel functionality or undefined performance requirements, has to be resolved before capitalization can begin. The standard takes effect for fiscal years beginning after December 15, 2027, with early adoption permitted.
Which Costs Qualify
Once the capitalization window is open, the same categories qualify under both the current model and ASU 2025-06.
Capitalizable costs include salaries and benefits of developers, testers, and other staff working directly on the project, allocated by time actually spent on development. Third-party consulting and contractor fees that directly contribute to building the software qualify. Borrowing costs incurred during development can be capitalized when the project takes a substantial period to complete and involves significant expenditures. Stock-based compensation for developers on the project can be capitalized as long as the underlying work qualifies.
Several categories must stay on the income statement. Training employees to use the finished software is an administrative cost. Data conversion from legacy systems cannot be added to the asset’s value.1Financial Accounting Standards Board. Accounting Standards Update 2025-06 – Intangibles Goodwill and Other Internal-Use Software (Subtopic 350-40) General overhead like rent, utilities, and executive salaries not tied directly to the project doesn’t count. Routine maintenance and minor bug fixes after go-live are period expenses.
Whether a given developer hour qualifies often comes down to documentation. Engineers on these projects generally need to track their time so the company can split salary costs between capitalizable development work and everyday tasks that don’t qualify.
Software Built to Sell Follows a Different Rule
The classification depends on who the software is for. Internal tools, like a proprietary scheduling platform or an internal data system, follow ASC 350-40 and the timing rules above.
Software intended for sale, lease, or licensing to external customers is governed by ASC 985-20. Under that standard, all project costs are expensed as research and development until the product reaches technological feasibility, which requires either a completed detailed program design or a working model tested against the product’s design specifications. Only after that milestone can costs be capitalized. Because many software companies reach technological feasibility late in development, most of their spending ends up expensed regardless. ASU 2025-06 did not change the rules for software built to sell.
Cloud and SaaS Arrangements
When a company pays for a cloud-based platform rather than building its own, the treatment depends on the contract. If the arrangement lets the customer take possession of the software at any time without significant penalty, and the customer could feasibly run it on its own infrastructure, ASC 350-40 applies and the standard capitalization rules follow.
If the contract does not grant those rights, the customer is buying a service, not an asset. Implementation costs to configure and customize the hosted software still follow the same capitalization framework, but capitalized implementation costs are classified as a prepaid expense rather than an intangible asset, which changes where they land on the balance sheet.
Amortization and Useful Life
Once the software is placed into service, the company amortizes the capitalized cost over its estimated useful life. Most companies land between three and seven years, though the actual figure depends on the facts. Software in fast-moving fields like artificial intelligence or cybersecurity may warrant a shorter life because newer alternatives emerge quickly. If the software relies on third-party licenses with fixed terms, the useful life cannot exceed the license duration unless renewal is reasonably certain. A tool built for a specific project or regulatory requirement may have a useful life tied to that project’s timeline. Ongoing enhancement spending can extend practical usefulness but does not retroactively change the original amortization schedule.
Amortization is typically straight-line, spreading cost evenly across each period. It reduces the asset’s carrying value on the balance sheet and appears as a non-cash charge on the income statement. Companies must also disclose the capitalized software balance, accumulated amortization, and the amortization method.
Impairment
Capitalized software is not permanent. If the asset’s value drops below its carrying amount, an impairment loss has to be recognized. Common triggers include abandoning the project, a significant reduction in expected functionality, or a strategy shift that makes the tool obsolete before amortization ends. The company compares the carrying amount to fair value, and any excess is written off in the current period. Once recognized, the reduced carrying amount becomes the new baseline for future amortization.
Tax Treatment Runs on a Separate Track
The federal tax rules for software development operate independently of the GAAP treatment above, and 2025 brought a major change.
The One, Big, Beautiful Bill Act created Section 174A of the Internal Revenue Code, permanently restoring full expensing for domestic research and experimental expenditures, including software development costs, for tax years beginning after December 31, 2024.3United States Code. 26 USC 174 – Amortization of Research and Experimental Expenditures Before this change, Section 174 required capitalizing and amortizing domestic software development costs over five years, a rule that took effect in 2022. Foreign software development costs did not get the same relief and must still be capitalized and amortized over 15 years.
Section 197, which imposes 15-year amortization on many acquired intangibles, specifically excludes self-created software.4Office of the Law Revision Counsel. 26 USC 197 – Amortization of Goodwill and Certain Other Intangibles Software the company built itself never falls into the 15-year bucket. Software acquired as part of a business purchase does, and must be amortized over that longer period. The distinction matters when a company is deciding whether to build or buy.
Documentation Matters
Capitalizing software costs takes more paperwork than expensing them. The company needs to show exactly when the capitalization threshold was met, which costs qualify, and how developer time was split between development and other activities. In practice, that means project authorization records, developer time-tracking logs, and vendor invoices tied to specific milestones. For public companies, the stakes climb higher: misclassifying expenses as capitalized assets to inflate earnings is the kind of accounting choice that draws SEC enforcement attention.5U.S. Securities and Exchange Commission. Retention of Records Relevant to Audits and Reviews