In this article
Successfully bringing innovative software to the external market often involves substantial upfront investment in development. The methods companies use to account for these significant expenditures are governed by specific accounting principles related to capitalizing software development costs. This practice means treating certain development costs as assets on the balance sheet, rather than immediately expensing them as they are incurred.
The core objective of this accounting treatment is to more accurately match these substantial initial outlays with the future revenues the software is anticipated to generate over its useful life.
This guide will focus on the rules and considerations for software developed specifically for external use—products intended to be sold, leased, or otherwise marketed.
Diligent application of guiding accounting standards, such as ASC 350-40 in the U.S. Generally Accepted Accounting Principles (GAAP) or IAS 38 under IFRS, is paramount for compliant and transparent financial reporting in this complex area.
External Use Software Capitalization Rules
External Use Software Capitalization Rules
Before a company can begin capitalizing development costs for software intended to be sold, leased, or otherwise marketed externally, several critical criteria must be met.
These criteria, primarily derived from accounting standards such as U.S. GAAP (specifically ASC 985-20, Costs of Software to Be Sold, Leased, or Otherwise Marketed) and IFRS (IAS 38, Intangible Assets), ensure that capitalization is appropriate and that the resulting asset accurately reflects its economic potential.
Establishing Technological Feasibility
This is the pivotal point at which the project transitions from a research phase, where costs are typically expensed, to a development phase suitable for capitalization.
- Technological feasibility is generally achieved when the company completes all planning, designing, coding, and testing activities necessary to establish that the software can be produced to meet its design specifications, including its intended functions, features, and technical performance requirements.
- Key indicators that technological feasibility has been reached include the completion of a detailed program design or, in its absence, the creation of a functional working model of the software.
Confirming Intent to Market
It’s not enough for the software to be technologically sound; the company must also clearly demonstrate its commitment and a viable plan to actually sell, lease, or otherwise market the finished product to external users. This confirms a commercial objective for the developed software.
Verifying Resource Availability
The company must demonstrate that it possesses, or can reliably obtain, the necessary financial, technical, and human resources to complete the software’s development, test it thoroughly, and successfully bring it to the intended market. Without adequate resources, the project’s completion and ability to generate future benefits are questionable.
Assessing Probable Future Economic Benefits
A reasonable expectation and supporting evidence must exist that the software, once completed and marketed, will generate future revenues or other economic benefits that will exceed the capitalizable costs. This assessment underpins the economic justification for treating the development costs as an asset on the balance sheet.
Identifying Costs for Capitalization
Identifying Costs for Capitalization
Once the criteria for capitalization are met and technological feasibility is established, the next step is to accurately identify which specific software development costs can and should be capitalized. Proper classification is essential for compliant financial reporting and to ensure the asset’s value is correctly stated.
Direct Costs Eligible for Capitalization
These are expenses that can be directly attributed to the software development project during the capitalization period (i.e., after technological feasibility is established and before the product is ready for general release).
Direct capitalizable costs typically include:
- Salaries and benefits for employees, such as software engineers, testers, and project managers, who are directly involved in hands-on activities of the software development project.
- Materials and services consumed directly in the development process, for instance, software licenses for development tools, specific cloud service costs incurred for development activities, or fees for specialized third-party components.
- Fees paid to external third-party contractors or consultants for services directly rendered in the detailed software design, coding, and testing phases.
Allocating Overhead Costs
A portion of indirect costs, often referred to as overhead, can also be capitalized if these costs are clearly related to and benefit the software development activities. These allocations must be reasonable, consistently applied, and directly attributable to the development effort:
- Facility expenses, which can include a rational and systematic allocation of rent, utilities, and other operational costs for the portion of the facility housing the development team and their activities.
- Depreciation of tangible assets, such as computers, servers, and testing equipment, used directly and extensively in the software development process during the capitalization period.
Costs Explicitly Excluded from Capitalization
It is equally important to identify types of costs that should not be capitalized and must be expensed as incurred, regardless of the project stage. These typically include:
- Preliminary project stage costs: Expenses incurred during activities such as idea generation, conceptual formulation, evaluation of design alternatives, and other exploratory work performed before technological feasibility is established.
- Training costs: Costs for employees involved in the software project, as these are generally considered operational expenses.
- Post-implementation costs and ongoing maintenance: Costs such as those for ongoing customer support, routine maintenance costs, bug fixes that do not qualify as enhancements or upgrades, and data conversion activities performed for customers after the software is available for general release (unless such conversion is necessary for the software to perform its intended functions for the customer).
- General and administrative overhead: G&A costs not directly attributable to the software development project, such as corporate office expenses, human resources, accounting, marketing, and sales costs.
- Costs associated with creating duplicate software masters or adapting existing software for a specific customer, unless these meet separate criteria for capitalization as significant enhancements or upgrades providing additional functionality.
Amortizing Capitalized Software Costs
Amortizing Capitalized Software Costs
Once your software product is complete and ready for external use, the capitalized development costs aren’t just left on the balance sheet. Instead, they need to be systematically expensed over the period they are expected to generate economic benefits.
This crucial accounting process is known as amortization.
When to Start Amortization
You must begin amortizing capitalized software development costs as soon as the software product is available for general release to customers. This point is reached when the software is substantially complete, has been thoroughly tested, and is ready to be sold, leased, or otherwise marketed. It’s important to note that amortization starts when the product is ready, not necessarily when the first actual sale is made.
Determining the Amortization Period
The capitalized costs should be amortized over the estimated useful life of the software. This period is your best estimate of the time during which the software is expected to contribute to future cash flows or provide other economic benefits to your company.
When estimating this useful life, carefully consider several factors, including:
- The expected market life of the product, considering potential changes in customer demand.
- The pace of technological obsolescence for that type of software.
- The competitive landscape and the potential impact of rival products.
- Any known trends or legal factors that could shorten its revenue-generating capacity.
Selecting an Amortization Method
The method you choose for amortization should be rational, systematic, and aim to reflect the pattern in which the software’s future economic benefits are expected to be consumed. Common and prescribed approaches include:
- The straight-line method: This method allocates an equal amount of amortization expense to each period over the software’s estimated useful life. It’s often used for its simplicity if the pattern of economic benefits isn’t more clearly defined by another model.
- Revenue-based method (common under US GAAP): For entities following US GAAP (specifically ASC 350-40), amortization expense is typically the greater of the amount calculated using (a) the ratio that current gross revenues for the product bear to the total of current and anticipated future gross revenues for that product, or (b) the straight-line method over the remaining estimated economic life of the product. This approach directly links the expense to the revenue generated.
- Pattern of economic benefits (IFRS): Under IFRS (IAS 38), the amortization method used should reflect the pattern in which the asset’s future economic benefits are expected to be consumed by the entity. If that pattern cannot be determined reliably, the straight-line method must be used
Addressing Impairment of Capitalized Costs
Addressing Impairment of Capitalized Costs
Even after you’ve capitalized software development costs and started amortizing them, your job isn’t quite done. You need to regularly assess whether the value of this capitalized asset as shown on your balance sheet is still recoverable.
If circumstances suggest that the software will no longer generate the economic benefits originally anticipated, it might be impaired. Recognizing impairment is crucial for ensuring your financial statements accurately reflect the asset’s true economic value.
When to Test for Impairment
You should test your capitalized software costs for impairment at least once a year. Beyond this annual check, you also need to perform an impairment test whenever events or significant changes in circumstances indicate that the carrying amount of the software asset might not be recoverable. This means staying alert to internal and external factors that could devalue your software.
Recognizing Impairment Indicators
Be vigilant for specific signs—often called impairment indicators—that suggest your capitalized software might have lost value. Key indicators to watch for include:
- A significant decrease in the software’s market value, perhaps due to new, superior competitive products or rapid technological shifts.
- Adverse changes in the extent or manner in which the software is being used or is expected to be used, such as a strategic decision to discontinue a major feature or a noticeable decline in user adoption or engagement.
- A significant adverse change in legal factors or in the business climate that could negatively affect the software’s value, its marketability, or its legal right to be sold.
- An accumulation of costs significantly in excess of the amounts originally budgeted or expected to complete and launch the software.
- Current-period operating or cash flow losses specifically associated with the software, or a history of such losses, or reliable projections that demonstrate continued losses from the software’s use.
Recording an Impairment Loss
If an impairment indicator is present, you’ll need to perform an impairment test. If this test confirms that the software’s carrying amount (its capitalized cost less accumulated amortization) is indeed higher than its recoverable amount, you must recognize an impairment loss.
The impairment loss is calculated as the difference between the software’s carrying amount and its recoverable amount. The recoverable amount is typically the higher of:
- Its fair value less the costs to sell it
- Its value in use (which is the present value of the estimated future cash flows expected to be derived from the software’s continued use and eventual disposal).
This impairment loss is then recorded as an expense in your income statement for the period, reducing your net income and the carrying value of the capitalized software asset on the balance sheet.
Meeting Disclosure Requirements
Meeting Disclosure Requirements
Properly accounting for capitalized software costs doesn’t end with recording and amortizing them; clear and comprehensive disclosure in your financial statements is also crucial. This transparency allows investors, creditors, and other stakeholders to understand your accounting policies, the extent of your investment in software assets, and the impact of these activities on your financial performance.
To meet these requirements, ensure your financial statement notes clearly disclose the following information for each reporting period:
- Your accounting policy for the capitalization of software development costs. This should detail the specific criteria you apply to determine when capitalization begins and the methods you use for amortizing these capitalized costs over their useful lives.
- The gross carrying amount of your capitalized software costs. This is the total amount capitalized before deducting any accumulated amortization or impairment
- The total accumulated amortization related to your capitalized software costs, presented separately from the gross carrying amount. You should also separately disclose any accumulated impairment losses that have been recognized against these assets.
- The amortization expense charged for capitalized software costs during each period presented in the financial statements. This shows the portion of the capitalized costs allocated to expense in the current period.
- The total amount of research and development (R&D) costs that were charged directly to expense during each period. It’s important to clearly distinguish these expensed R&D costs from the amounts that were capitalized.
- A reconciliation of the unamortized capitalized software costs (the net book value) at the beginning and end of each reporting period. This reconciliation should clearly show:
- Additions from new software development costs capitalized during the period.
- Amortization expense recognized during the period.
- Any impairment losses recognized against capitalized software during the period.
- The carrying amount of any capitalized software that was sold or otherwise disposed of during the period.
The Challenge of Aligning GAAP with Agile Development
The Challenge of Aligning GAAP with Agile Development
Applying traditional GAAP software capitalization rules to Agile development is challenging because GAAP’s phased approach (preliminary stage, technological feasibility, post-release) doesn’t naturally fit Agile’s iterative, continuous cycle.
This mismatch creates several practical challenges:
- Pinpointing technological feasibility: Defining this critical GAAP trigger for starting capitalization is ambiguous when software is developed and released incrementally in Agile sprints.
- Distinguishing project phases: Clearly separating expensible research and preliminary stage costs from capitalizable development work is difficult as Agile sprints often blend these activities.
- Tracking costs accurately: Precisely allocating labor and other costs to specific capitalizable features becomes complex with Agile’s fluid scope, evolving priorities, and concurrent development efforts.
- Meeting documentation needs: Agile’s emphasis on working software over extensive upfront documentation can make it challenging to produce the detailed audit trails typically expected to support capitalization.
- Defining product completion for amortization: With continuous releases and updates, determining when a distinct software product is “available for general release” to commence amortization requires careful, consistent policies.
Navigating these often requires clear internal guidelines to interpret and apply GAAP principles within an Agile framework, fostering collaboration between finance and engineering teams.
Leveraging Engineering Intelligence: How Jellyfish Help
Leveraging Engineering Intelligence: How Jellyfish Help
While engineering intelligence platforms like Jellyfish don’t perform accounting, they offer valuable data to help apply GAAP software capitalization rules more effectively within Agile environments:
- Clarify development progress: They track feature completion and code stability, providing objective data points that can assist in determining when “technological feasibility” (a key GAAP milestone) is achieved for new functionalities.
- Distinguish types of work: By allowing engineering tasks to be categorized (e.g., new feature development, research, bug fixes), these platforms help in separating capitalizable development efforts from expensed activities within sprints.
- Improve cost allocation insights: They visualize how engineering time and resources are allocated across different projects and initiatives, offering a clearer basis for allocating labor costs to capitalizable software assets.
- Support documentation needs: Reports on development activity, project timelines, and resource deployment generated by these platforms can serve as valuable supplementary evidence for auditors and support capitalization decisions.
- Inform amortization timing: Data on release frequency and the stability of new features helps in consistently determining when software increments are “available for general release” and amortization should begin.
Jellyfish provides the data-driven visibility necessary for more informed and consistent capitalization decisions in an Agile world.

Take a Deeper Look with Jellyfish
Ready to see how engineering intelligence can bring clarity to your development efforts and support your capitalization processes?
Get a DemoFAQs
FAQs
What’s the difference between capitalizing external use vs internal-use software?
The primary differences relate to the software’s intended use, the specific U.S. GAAP standard applied, and, most importantly, when you begin to capitalize costs:
- External-use software: This software is developed to be sold, leased, or otherwise marketed (guided by ASC 985-20). Capitalization of development costs starts after technological feasibility is established – meaning the company has confirmed the product can be built to its design specifications, often through a detailed design or working model.
- Internal-use software: This software is developed solely for a company’s own operational needs (guided by ASC 350-40). Internal-use software capitalization begins after the preliminary project stage (where ideas are explored and alternatives weighed) is complete, and management formally commits to funding and completing the project for its intended internal function.
Generally, capitalization begins earlier for internal-use software because its threshold for starting the development stage is often met sooner than the stricter technological feasibility requirement for external-use products.
What are the main benefits of capitalizing software development costs?
Capitalizing software development costs offers several key benefits:
- Better matching: It aligns the significant costs of software development with the revenues or economic benefits the software is expected to generate over its useful life, rather than expensing all costs upfront.
- Improved financial reporting: It can result in a more accurate representation of a company’s financial position by recognizing a valuable intangible asset on the balance sheet and can lead to higher net income in the initial periods of the software’s life.
- Enhanced comparability: Adhering to capitalization rules allows for more consistent financial statement comparisons between different companies in the same industry.
- Reflects investment: It treats significant software development as an investment in a long-term asset that will provide future value, which is often a more accurate economic portrayal than treating all such costs as immediate operational expenses.
How are costs for developing SaaS products typically capitalized?
Developing a SaaS product generally follows external-use software rules (e.g., ASC 985-20), with capitalization of the core platform starting after technological feasibility. Ongoing development of new features or significant upgrades requires separate assessment for capitalization versus expensing maintenance costs. Hosting infrastructure costs are accounted for separately.
When should we consult a CPA regarding software capitalization?
Consult a CPA or a specialized accounting firm when setting your initial capitalization policies, facing complex scenarios, if unsure about capitalizable costs, or before an audit to ensure your application of accounting guidance is sound.
About the author

Kevin Graney is a Senior Sales Engineer at Jellyfish where he works to bridge the gap between complex engineering workflows and executive decision-making. With more than six years in SaaS and over ten years of military leadership, Kevin specializes in aligning stakeholder needs across Engineering, Product and Finance.