Capitalizing internal-use software costs is governed by ASC 350-40, and the rule is narrower than most project budgets assume: costs become a balance-sheet asset only after management with the right authority commits to funding the project and completion is probable, and capitalization stops again once the software is ready for its intended use. Everything spent before that commitment is expensed. Everything spent after the software is substantially complete is expensed. The capitalization window sits between those two points, and misreading where a project is in its lifecycle is one of the most common GAAP errors in technology accounting.
What Internal-Use Software Means Here
Internal-use software is any application developed or acquired for the company’s own operations, with no substantive plan to sell, lease, or license it to outside customers. A payroll system built by your IT team, an internally developed inventory tracker, and a purchased ERP platform all qualify. The classification matters because software intended for external sale or licensing is governed by a different standard, ASC 985-20, which uses technological feasibility rather than project commitment as its capitalization trigger.
If a project starts as internal-use and the company later decides to market the software externally, the accounting pivots at the decision point. Costs incurred after that decision follow ASC 985-20. Costs already capitalized under ASC 350-40 stay on the books at their existing carrying amount.
When Capitalization Starts and Stops
ASC 350-40 organizes every project into three stages, and only the middle one produces a capitalizable asset.
Before Commitment: Preliminary Project Stage
Everything before management greenlights the project is expensed as incurred. Typical activities are feasibility studies, build-versus-buy analysis, vendor comparisons, and high-level requirements definition. Salaries for the people running that analysis and fees for outside advisors hit the income statement immediately, because there is no probable future economic benefit yet.
This stage ends only when two things happen together: management with the relevant authority commits to funding the project, and completion plus intended use become probable. A vague intention to “look into it further” doesn’t clear the bar. The commitment has to be specific enough that the company is prepared to allocate resources to design, code, and deploy.
The Capitalization Window: Application Development Stage
Once both triggers are met, qualifying costs go on the balance sheet as an intangible asset. This stage covers detailed design, coding, configuration, installation, and testing. It ends when the software is substantially complete and ready for its intended use, even if the formal production launch hasn’t happened yet.
The “substantially complete” line trips people up. If the software works and could be deployed, but the go-live date slips for business reasons, capitalization still stops. Extra months of rollout delay don’t buy extra months of capitalization.
After Go-Live: Post-Implementation Stage
Once the software is ready for use, every subsequent cost is expensed. Maintenance, routine bug fixes, minor tweaks, end-user training, and leftover data migration all flow through the income statement as operating expenses.
One exception reopens the window: a significant upgrade or enhancement that delivers genuinely new functionality, meaningfully extends useful life, or materially improves efficiency can restart capitalization for that enhancement. Bolting a new analytics module onto an existing ERP could qualify. Patching a security vulnerability or refreshing a user interface without changing what the software does would not.
What You Can Capitalize During Development
Even inside the capitalization window, not every cost qualifies. Four categories do:
- External direct costs, meaning payments to third-party developers, consultants, or contractors working on design, coding, or testing. These are the easiest to identify because they appear on invoices.
- Internal payroll and payroll-related costs for employees spending time directly on the project, including programmers, systems architects, testers, and anyone installing or configuring the software. Only the portion of time directly attributable to development qualifies. If a developer splits the week between the project and day-to-day support, only the project hours get capitalized.
- Interest costs incurred during development, which may be capitalized under ASC 835-20 if the software project qualifies as an asset being constructed for the entity’s own use.
- Dedicated hardware or infrastructure purchased solely for and used exclusively during development, such as a dedicated testing server. General-purpose assets used across multiple projects do not qualify.
What You Cannot Capitalize, Even During Development
Some costs are expensed no matter when they occur:
- General and administrative overhead such as rent and utilities cannot be allocated to the software asset.
- Training costs are always expensed, regardless of when the training occurs.
- Data conversion, including migrating, cleansing, reconciling, or reformatting data from old systems to the new one, is expensed as incurred even when the work happens squarely inside the application development stage.
- Maintenance and support costs that keep the software running to its original specifications are never capitalizable.
Data conversion catches people off guard because it often runs in parallel with core development work, and the invoices may come from the same vendor. The timing doesn’t matter. The nature of the cost does.
Cloud and SaaS Implementation Costs
When a hosting arrangement is a service contract rather than a software license, the company doesn’t own the underlying software and can’t capitalize the subscription fees themselves. ASU 2018-15 extended the ASC 350-40 framework to the implementation costs of configuring and setting up that hosted software. If a cost type would be capitalizable for an on-premise internal-use project, it’s capitalizable for the SaaS implementation too. Costs that fail the test for internal-use software, including training and data conversion, also fail for SaaS.
Presentation differs. Capitalized SaaS implementation costs sit on the balance sheet in the same line as a prepayment of hosting fees would, not as an intangible asset. Amortization runs over the term of the hosting arrangement rather than the software’s useful life, and the amortization expense lands in the same income statement line as the hosting fees. Cash flows follow the classification of the hosting payments.
Amortizing the Capitalized Asset
Amortization begins when the software is substantially complete and ready for use, not when it enters production. Straight-line is standard for internal-use software, spreading the cost evenly across the estimated useful life.
Useful lives typically range from three to seven years, depending on the technology, the pace of expected obsolescence, and the planning horizon of the business function the software supports. A customer-facing mobile app on a fast-moving platform might warrant three years. A core financial system could justify five to seven. The estimate takes judgment and should be revisited if circumstances change.
Impairment and Abandonment
Capitalized software must be tested for impairment when events suggest the carrying amount may not be recoverable, following the long-lived asset model under ASC 360-10. Common triggers include abandoning the project before completion, a shift in business strategy that makes the software unnecessary, and a technological change that renders it obsolete.
The test compares carrying value to undiscounted expected future cash flows. If carrying value is higher, the asset is written down to fair value. For software abandoned outright, the presumption is zero value, so the entire remaining balance is written off.
What Changes Under ASU 2025-06
FASB issued ASU 2025-06 in early 2026 to modernize ASC 350-40 for teams that no longer develop software in a linear waterfall. The update is effective for annual reporting periods beginning after December 15, 2027, with early adoption permitted at the start of any annual period. Calendar-year companies that want to adopt early can do so as soon as their 2026 fiscal year begins.
The most visible change is the elimination of the three stage labels. FASB concluded that preliminary, application development, and post-implementation don’t match how agile teams work, where design, coding, and testing cycle continuously.
Capitalization under the new framework begins when management authorizes and commits to funding the project and it is probable the project will be completed and the software will perform its intended function. Those criteria are conceptually similar to the current rules, but dropping the stage labels gives companies more flexibility in iterative workflows.
The update introduces “significant development uncertainty,” which blocks capitalization even when management has committed funding. It exists when the software involves novel, unique, or unproven features whose feasibility hasn’t been confirmed through coding and testing, or when significant performance requirements haven’t been identified or are still being substantially revised. Until that uncertainty is resolved, costs are expensed.
The list of costs that can and cannot be capitalized stays the same. Data conversion, training, and maintenance remain expensed as incurred. The update also folds the old website development guidance from ASC 350-50 into ASC 350-40 and adds disclosure requirements under ASC 360-10 for all capitalized software costs regardless of how they’re presented on the balance sheet.
GAAP Treatment Is Not the Tax Treatment
Book and tax rules for software development costs have diverged, and anyone managing both needs to track them separately. The One, Big, Beautiful Bill Act, signed into law on July 4, 2025, restored immediate deduction of domestic research or experimental expenditures, including software development costs, for tax years beginning after December 31, 2024. A taxpayer may instead elect to capitalize and amortize those costs over at least sixty months. Foreign research expenditures still must be capitalized and amortized over fifteen years.
For companies that capitalized domestic R&D during the 2022 through 2024 tax years under the prior TCJA rules, an accounting method change election allows the remaining unamortized domestic costs to be deducted ratably over 2025 and 2026.
The practical result for 2026 is that domestic software development costs can be fully expensed on the tax return in the year paid or incurred, even when the same costs are being capitalized and amortized for GAAP. The gap creates a deferred tax liability that unwinds as the GAAP asset amortizes.