ASC 985 software capitalization comes down to a single line: under ASC 985-20, every dollar you spend on a software product before you establish technological feasibility is expensed as research and development, and costs incurred after that point through general release are capitalized on the balance sheet. Where that line falls depends on how your engineering team documents its progress, and misplacing it distorts both earnings and asset values.
Confirm ASC 985-20 Is the Right Standard
ASC 985-20 governs software you plan to sell, lease, or market, whether as a standalone product or embedded in another product. Software developed strictly for your own internal operations falls under ASC 350-40 instead, which uses a different capitalization threshold and different rules on eligible costs.
The distinction matters most for SaaS companies. If customers access your software through a hosted arrangement and never take possession of the underlying code, you’re providing a service rather than delivering a software product, which typically puts you under ASC 350-40. The test is whether the customer receives a software license or just uses your platform. Companies that both use their own software internally and sell it to third parties face a rebuttable presumption that the software is intended for external sale, pulling it under ASC 985-20.
Applying the wrong standard is one of the more common accounting errors in software companies. Sort this out at the start of a project; reclassifying costs later is expensive.
Technological Feasibility Is the Trigger
ASC 985-20 doesn’t use named development stages. The framework is binary. Costs before technological feasibility hit the income statement as R&D. Costs after technological feasibility get capitalized until the product is available for general release.
Technological feasibility means you’ve completed the planning, designing, coding, and testing needed to confirm the product can be built to meet its design specifications, including intended functions, features, and performance. That’s a high bar, and the standard requires you to demonstrate it through one of two paths.
The Detailed Program Design Path
If your development process includes a detailed program design, all three of the following must be satisfied before you start capitalizing:
- Both the overall product design and the detailed program design are complete, and you’ve confirmed the team has the skills, hardware, and software technology needed to build the product.
- The detailed program design has been documented and traced back to the product specifications, confirming completeness and consistency.
- Any high-risk development issues, such as novel features or unproven technology, have been identified and resolved through actual coding and testing.
The resolution of high-risk issues is where most teams either meet or fail this threshold. Coding and testing are required; a plan on paper isn’t enough.
The Working Model Path
When a detailed program design isn’t part of your process, the alternative is a working model. ASC 985-20 defines this as an operative version of the software, written in the same programming language as the final product, that performs all major planned functions and is ready for initial customer testing (typically beta). The working model must be tested and confirmed as consistent with the product design.
Most software companies establish technological feasibility through the working model path, and they reach it late in the development cycle. The result is that the overwhelming majority of development spending ends up expensed as R&D, with only a thin capitalizable window between the working model and general release. That’s why technology company balance sheets often show little or no capitalized software relative to total development spending.
One rule to keep in mind for multi-module products: when modules aren’t sold separately, technological feasibility applies to the entire product. You can’t start capitalizing Module A while Module B is still in early development.
What You Can Capitalize Once the Window Opens
Between technological feasibility and general release, the direct costs of finishing the product qualify for capitalization:
- Wages, salaries, and benefits for engineers, developers, and testers working directly on coding, testing, and final documentation.
- Specialized software licenses, hardware for testing environments, and other materials consumed in completing the product.
- Fees paid to outside consultants or contractors for code finalization, testing, or other direct development work.
- A proportional share of indirect costs clearly tied to the development team, such as equipment depreciation and an allocable portion of facility costs like rent and utilities.
General and administrative expenses, marketing costs, executive salaries, and selling costs are never capitalizable under ASC 985-20, regardless of how closely an executive oversees the project. Those stay on the income statement as period expenses.
The capitalization window closes when the product is available for general release, meaning ready to ship or deploy. The first actual sale doesn’t matter; readiness does.
Amortization After Release
Once the product is available for general release, capitalization stops and amortization begins on a product-by-product basis. ASC 985-20 requires a “greater of” test each period, comparing two methods:
- The revenue ratio: unamortized cost multiplied by current-period gross revenue divided by total expected gross revenue (current plus anticipated future) for the product.
- Straight-line amortization over the product’s remaining estimated economic life.
You record whichever amount is larger. The rule has a practical effect that’s easy to overlook: it accelerates amortization when a product earns heavy revenue early. If your product generates 60% of its lifetime revenue in year one, the revenue ratio will far exceed the straight-line amount, forcing a larger write-down. If revenue is slow early on, the straight-line floor prevents you from carrying the asset at an inflated value.
When management revises total expected revenue downward, the revenue ratio denominator shrinks and the amortization rate goes up. That adjustment is prospective. You don’t restate prior periods.
Impairment and Write-Downs
At each balance sheet date, compare the unamortized cost of each software product to its net realizable value: estimated future gross revenue from the product minus estimated costs to complete and dispose of it. If unamortized cost exceeds net realizable value, the asset is impaired and you write it down immediately. Common triggers are a steep drop in sales, the emergence of a superior competing product, or a shift in technology that makes your product less relevant.
The write-down equals the gap between carrying amount and net realizable value, and it hits the current period as an expense. Two features of this model deserve attention. First, the written-down amount becomes the new cost basis for all future amortization, and the greater-of test continues to apply on that reduced balance. Second, once you record an impairment loss, you cannot reverse it. Revenue picks up, a new customer segment emerges, the market shifts back in your favor; none of that undoes the write-down. This one-way ratchet keeps the balance sheet conservative but can leave a profitable product on the books at a fraction of its actual value.
Support your net realizable value calculation with solid documentation of the revenue and cost projections behind it. Auditors scrutinize these estimates closely.
Maintenance Versus Enhancements After Release
Post-release spending splits into two categories. Routine maintenance (bug fixes, patches, customer support, performance tuning that doesn’t change functionality) is expensed as incurred. It keeps the product running as designed but doesn’t create new economic value.
Significant enhancements are different. If post-release work adds new features, materially improves functionality, or delivers substantial performance gains, those costs may qualify for capitalization. The enhancement has to independently clear the technological feasibility threshold, just like the original product did. Capitalization begins when you establish technological feasibility for the new feature and ends when the enhanced version is available for general release. Pre-feasibility work on the enhancement, including market research or planning, is expensed as R&D.
The capitalized cost of an enhancement is amortized over the shorter of the enhancement’s own useful life or the remaining useful life of the original product.
Distinguishing a minor fix from a capitalizable enhancement is one of the harder judgment calls in software accounting. A patch that rewrites a core algorithm to run three times faster might qualify. Renaming menu items obviously doesn’t. The gray area in between is wide, and rigorous technical documentation from engineering is the best defense against both audit risk and unintentional misstatement.
Federal Tax Treatment Is a Separate Question
GAAP capitalization under ASC 985-20 and federal tax treatment of software development costs are separate regimes and can produce very different results on your financial statements versus your tax return. Under the Tax Cuts and Jobs Act of 2017, domestic R&D expenditures (including software development costs) had to be capitalized and amortized over five years for tax purposes starting in 2022.
The One Big Beautiful Bill Act, signed August 5, 2025, created new Section 174A of the Internal Revenue Code. For tax years beginning after December 31, 2024, domestic research and experimental expenditures, including software development costs, can once again be deducted immediately. Taxpayers can alternatively elect to capitalize and amortize domestic R&D costs over a period of at least 60 months.
Foreign research expenditures don’t get this treatment. Costs tied to research conducted outside the United States must still be capitalized and amortized over 15 years under the original Section 174 framework. Companies with offshore development teams need to allocate costs between domestic and foreign activities to track this correctly.1Internal Revenue Service. Audit Guidelines on the Application of the Process of Experimentation for All Software