Your company just invested six months of engineering time into building a new internal platform. Now finance needs to know: should those software development costs hit the income statement as an expense—or belong on the balance sheet as an asset?
Get it wrong, and you face audit risk, misstated financials, and potential compliance issues. Get it right, and you improve EBITDA, strengthen your balance sheet, and demonstrate the true value of your technology investments.
This guide walks accounting teams through the software capitalization rules under US GAAP, including which costs qualify for capitalization, when to start and stop capitalizing, and how to avoid the most common compliance pitfalls.
What is software capitalization?
Software capitalization is an accounting method that treats certain software development costs as capital assets rather than period expenses. Instead of recognizing the full cost immediately on your income statement, you record capitalized costs on the balance sheet and amortize them over the software's useful life.
This approach aligns with the matching principle under generally accepted accounting principles (GAAP): the cost of creating an asset should be recognized over the same period in which the asset generates value for the business.
For accounting teams, this means tracking which costs incurred during software development meet the criteria for capitalization—and maintaining documentation that will hold up to audit scrutiny.
Internal-use software vs. external-use software: Which rules apply?
The accounting guidance for software capitalization depends on how the software will be used. US GAAP provides two primary frameworks:
Most corporate accounting teams deal primarily with ASC 350-40 and internal-use software accounting. The rules differ significantly between standards, so correctly identifying which type of software you're dealing with is the essential first step.
Software for internal use must meet specific criteria: the organization must intend to use it internally, and there should be no substantive plan to market the software externally during the development phase.
The three stages of internal-use software development
Under the Accounting Standards Codification Topic 350-40, capitalizing internal-use software depends on identifying which development stage the project is in. Each stage has different rules for how to account for the costs:
Stage 1: Preliminary project stage
This stage includes conceptual work: determining whether the software project should proceed, evaluating alternatives, identifying technology requirements, and selecting vendors. Costs incurred during the preliminary project stage must be expensed as incurred—they cannot be capitalized.
Activities in this stage typically include:
Stage 2: Application development stage
Once the preliminary project stage is complete and management commits to funding the project, you enter the application development stage. This is where capitalization begins.
Costs that qualify for capitalization during this stage include:
The application development stage ends when the software is substantially complete and ready for its intended use.
Stage 3: Post-implementation / operation stage
After the software is ready for use, you enter the post-implementation stage. Costs incurred during this phase—including training, maintenance, and minor enhancements—are generally expensed as incurred.
However, if you undertake significant upgrades or enhancements that add new functionality, those costs may qualify for capitalization under the same rules as the original development.
What software costs qualify for capitalization?
Not all software development costs can be capitalized. The accounting standards are specific about which internal and external costs meet the criteria for capitalization:
Costs you can capitalize
Costs you must expense
The challenge for many accounting teams is that engineers don't track their time by accounting category. They work on capitalizable application development one hour and non-capitalizable maintenance the next—often without clear documentation of how time was spent.
Common software capitalization challenges for accounting teams
Even with clear accounting guidance, applying software capitalization rules in practice creates friction. Here are the obstacles most accounting teams face:
Engineering is a "black box"
Finance often lacks visibility into what engineers actually work on. Without reliable time data tied to specific projects and development stages, you can't determine which labor costs are eligible for capitalization. Nearly 25% of companies have lost R&D tax credits due to inadequate documentation—and capitalization requires the same audit-ready records.
Agile development complicates stage identification
Traditional software capitalization rules were designed for waterfall development, where stages are sequential and distinct. In agile environments, teams iterate continuously. Determining when the preliminary stage ends and application development begins—or whether a sprint represents new development or maintenance—requires judgment and consistent methodology.
Inconsistent tracking across projects
When different teams track time differently (or not at all), you end up with inconsistent capitalization practices. Some software projects get fully capitalized while similar projects are fully expensed—creating audit risk and inconsistent financial reporting.
Substantiation for auditors
Auditors want to see clear evidence that capitalized development costs meet the criteria for capitalization. That means contemporaneous records showing who worked on what, when, and how those activities map to capitalizable stages. Reconstructing this data after the fact is expensive, error-prone, and often unconvincing to auditors.
Companies that invest in CapEx labor tracking solve these challenges by capturing development time in real-time, tied to the projects and cost categories that matter for capitalization decisions.
Software capitalization and amortization: What happens after you capitalize?
Once you capitalize software development costs, you amortize them over the software's useful life. Under GAAP, the useful life of software should reflect the period over which the asset will provide economic benefit to the organization.
Key considerations for amortization:
The useful life of the software should be reassessed periodically. Technology changes, business strategy shifts, or decisions to replace systems may require adjustments to remaining amortization periods.
GAAP software capitalization rules vs. IFRS
While this guide focuses on US GAAP under ASC 350-40, multinational organizations may also need to consider International Financial Reporting Standards (IFRS). Under IAS 38, internally developed software is treated as an intangible asset with similar capitalization criteria—but with some differences in application.
Both frameworks require that the software project be technically and financially feasible before capitalization begins. However, the specific criteria for what constitutes "feasibility" and which costs qualify differ between standards. Organizations reporting under both frameworks need clear policies for each.
Best practices for software capitalization compliance
To apply software capitalization rules consistently and maintain audit-ready records, accounting teams should:
Establish clear capitalization policies
Document your organization's approach to software capitalization, including:
Implement real-time time tracking
The foundation of defensible capitalization is accurate labor cost data. Implement systems that capture development time as work happens—not retroactively during close. Time entries should tie directly to projects, phases, and cost categories that map to your capitalization policies.
Organizations using time tracking software connected to their project management tools can automatically categorize engineering hours into capitalizable and non-capitalizable buckets based on the work being performed.
Coordinate with engineering leadership
Finance can't determine capitalization eligibility without engineering context. Establish regular communication with development leadership to understand:
Document, document, document
Maintain contemporaneous documentation supporting your capitalization decisions. This includes:
Twenty-three percent of companies have faced audit failures from poor labor cost records. Don't let software capitalization be where your documentation gaps are exposed.
How software capitalization connects to R&D tax credits
The same engineering time that qualifies for capitalization often overlaps with research and development activities eligible for R&D tax credits under Section 41. While the criteria differ, the documentation requirements are similar: you need verifiable records of who did what work, when, and how it relates to qualifying activities.
Organizations that invest in robust time tracking for capitalization purposes often find they can also support larger, more defensible R&D tax credit claims. The key is capturing finance-ready data from the start—data that serves both accounting and tax purposes without reconstruction.
Learn more about R&D tax credit tracking and how accurate labor cost data supports compliance across multiple requirements.
Getting started with software capitalization
If your organization is developing internal-use software and not yet capitalizing—or capitalizing inconsistently—start with these questions:
For many organizations, the answer is that millions in development costs are sitting on the income statement that could legitimately be capitalized—improving EBITDA and better reflecting the true investment in technology assets.
The path to compliant software capitalization starts with accurate, auditable labor cost data. Finance-ready reporting that connects engineering activity to accounting requirements turns software capitalization from a compliance burden into a strategic advantage.
This content is provided for informational purposes only. ClickTime does not provide legal, tax, or financial advice. Laws and regulations vary by jurisdiction and change over time—please consult a qualified professional before making decisions based on this information.
