Capitalized Software GAAP: ASC 350-40 vs ASC 985-20 Compliance

GAAP software capitalization follows two primary standards: ASC 350-40 for internal-use software and ASC 985-20 for software sold to external customers. The critical difference is the capitalization trigger — ASC 350-40 begins at the application development stage (when management commits and feasibility is confirmed), while ASC 985-20 begins only after technological feasibility is established. The best software capitalization tracking tools — including Glue, Anrok, Apptio, and FloQast — automate the classification of engineering time into capitalizable vs. expensable categories under both standards.

At Salesken, our finance team initially applied ASC 985-20 to all our software development costs — until an auditor pointed out that our voice AI platform was internal-use, not for sale. That misclassification affected our balance sheet for two quarters. Getting the ASC 350-40 vs 985-20 distinction right isn't academic — it has real financial consequences.

GAAP software capitalization rules exist in two primary codifications, and choosing the wrong one can lead to significant accounting misstatements. For CFOs managing software development budgets—whether building internal tools or software products for sale—understanding the distinction between ASC 350-40 (internal-use software) and ASC 985-20 (software to be sold) is essential.

This guide provides a technical breakdown of both standards, the decision tree for determining which applies to your situation, key thresholds and amortization treatments, impairment testing requirements, and practical strategies for maintaining the audit-ready documentation that standard setters expect.

The Two Software Capitalization Standards

ASC 350-40: Internal-Use Software

ASC 350-40 applies when your organization develops or purchases software intended for internal use. Internal-use means the software supports your business operations, but you don't plan to sell or license it to external customers.

Common examples:

• Custom ERP systems and financial management platforms
• Proprietary tools for operations, HR, or supply chain
• Internal analytics and reporting systems
• Workflow automation and document management systems
• Manufacturing control systems
• Data integration and ETL platforms

Key Characteristic: You're building an asset for yourself, not a product for the market. The software may have a long useful life and strategic value, but it's not a revenue-generating product.

ASC 985-20: Software to Be Sold

ASC 985-20 applies when you develop software intended for sale or license to external customers. This includes:

• Commercial software products (SaaS, on-premise, mobile apps)
• Software components sold to other vendors
• Firmware bundled with hardware products
• Custom software developed under contract for a specific customer

Key Characteristic: You're developing a product to generate revenue. Even if development costs exceed initial revenue, the intent is commercial sale.

When Each Standard Applies: The Decision Tree

The critical first question: Is the software developed or purchased for external sale or license, or for internal use only?

START
  |
  Does the software have external customers or is it designed for external sale?
  |
  ├─ YES → ASC 985-20 applies (Software to be sold)
  |
  └─ NO → Is it for your internal operations?
         |
         ├─ YES → ASC 350-40 applies (Internal-use software)
         |
         └─ BOTH → HYBRID SITUATION
                  (Different rules apply to product development vs.
                   internal operations component)

Hybrid Situation: The Complication Most Organizations Face

Many software organizations develop platforms with both internal-use and commercial components. For example:

• A SaaS company develops infrastructure that serves both internal analytics (internal-use) and customer-facing features (product development)
• A financial services firm builds a proprietary trading system for internal use but also licenses components to other firms
• A healthcare organization builds a patient management system for internal use but develops modules for external sale

Solution: Apply both standards to the appropriate component. Establish clear accounting policies that segregate:

• ASC 985-20 costs: Software development activities directly tied to external product development
• ASC 350-40 costs: Infrastructure, frameworks, and tools used internally to support both product and operations

This requires careful tracking at the project and cost center level.

ASC 350-40 Deep Dive: Internal-Use Software Rules

Three-Phase Capitalization Structure

ASC 350-40 uses the three-phase model we introduced earlier:

Phase 1: Preliminary Project Stage (EXPENSED)

• Conceptualization and feasibility studies
• Architecture planning
• Technology selection
• Vendor evaluation and selection
• Process redesign and requirements gathering
• Project approval and authorization

Phase 2: Application Development Stage (CAPITALIZED)

• Detailed design and architecture
• Development labor and costs
• Testing and quality assurance
• Data conversion and migration
• Third-party software integration
• Infrastructure and servers directly identifiable to the project

Phase 3: Post-Implementation Stage (EXPENSED)

• System stabilization and bug fixes
• Training and documentation
• Parallel operations with legacy systems
• Initial data validation and cleanup
• User acceptance testing

The critical moment: When does Phase 2 begin? ASC 350-40-25-6 states that the application development stage begins when "the entity has determined it is probable that the project will be completed and the software will be used to perform the intended function."

This typically means:

• Formal project authorization has been obtained
• Funding has been approved
• Technical feasibility has been confirmed
• Management commitment exists

Capitalization Thresholds for ASC 350-40

Unlike some accounting standards, GAAP does not specify a dollar threshold for capitalizing internal-use software. However, two practical thresholds apply:

1. Materiality Threshold While not required by the standard, most organizations only capitalize software projects exceeding a materiality threshold (often $50,000 to $250,000 depending on organization size). Projects below this threshold are typically expensed immediately due to the cost of tracking and documentation.

2. Useful Life Threshold ASC 350-40-35-1 states that capitalized software should have an estimated useful life of more than one year. If the software will be replaced or obsolete within 12 months, capitalize the full cost as a short-term asset.

Amortization Rules for Internal-Use Software

Once capitalized, internal-use software is amortized (depreciated) over its useful life. Key rules:

Useful Life Estimation:

• Typical range: 3 to 7 years
• Consider: Technology evolution, business process changes, planned replacements
• Document your assumptions in the accounting policy

Amortization Method:

• Straight-line amortization is most common
• Begin amortization when the software is placed in service (not during development)
• Do not begin amortization during Phase 3 (post-implementation)

Example:

• Software placed in service: January 1, 2026
• Capitalized cost: $600,000
• Useful life: 5 years
• Annual amortization: $120,000 ($600,000 / 5 years)
• First year partial amortization (Jan-Dec 2026): $120,000 (full year)

ASC 985-20 Deep Dive: Software to Be Sold

Different Capitalization Stages

ASC 985-20 uses different capitalization stages than internal-use software:

Stage 1: Conceptual Formulation and Evaluation Stage (EXPENSED)

• Identification of new product candidates
• Evaluation of market potential
• Technology assessment
• Business case analysis
• Project approval decisions

Stage 2: Development Stage (CAPITALIZED)

• Design and architecture work
• Development labor
• Coding and testing
• Quality assurance specific to product
• Documentation for users and support teams

Stage 3: Pre-Release Stage (EXPENSED)

• Beta testing and user acceptance testing
• Marketing preparation
• Sales training and materials
• Manufacturing setup (if physical product included)
• Bug fixes and stabilization

Stage 4: Post-Release Maintenance (EXPENSED)

• Ongoing bug fixes and patches
• Customer support
• Performance monitoring
• Enhancements beyond initial product scope

Software to Be Sold: Capitalization Rules

ASC 985-20-25-1 requires that software development costs be capitalized only after both:

1. Technological feasibility is established, and
2. A commitment exists to produce the software (management authorization and funding)

Technological Feasibility Definition:

• For purchased software: receipt of the software and successful initial operation
• For internally developed software: completion of a detailed program design or, in some cases, completion of a working model

This is more prescriptive than ASC 350-40 and emphasizes demonstrating that the software can actually be built.

Amortization for Software to Be Sold

Begins: When the software is available for release Method: Straight-line or based on revenue recognition pattern Useful Life: Typically 3-5 years, but some software (e.g., cloud-based) may be shorter

Many software companies use a "revenue-based" amortization method when appropriate:

Example:

• Capitalized software costs: $2,000,000
• Expected total revenue from this product over 5 years: $10,000,000
• Revenue generated in Year 1: $3,000,000 (30% of total)
• Amortization for Year 1: $2,000,000 × 30% = $600,000

This approach aligns the amortization expense with actual product revenue.

Impairment Testing: When You Need to Write Down Software Assets

Both ASC 350-40 and ASC 985-20 require impairment testing when facts and circumstances suggest the software asset may not generate expected economic benefits.

Impairment Triggers to Monitor

For Internal-Use Software (ASC 350-40-35-4):

• Changes in intended use of the software
• Technology obsolescence
• Changes in regulatory environment making software obsolete
• Discontinued operations or product lines using the software
• Cost overruns or technical difficulties in deployment
• Significant reduction in revenue from operations the software supports

For Software to Be Sold (ASC 985-20-35-3):

• Product sales below expectations
• Significant market changes or competitive pressure
• Technology or product line discontinuation
• Regulatory changes affecting product viability
• Key customer losses or market share erosion

Impairment Testing Process

1. Indicator Assessment: Does an impairment indicator exist?
2. Undiscounted Cash Flow Test: Estimate future cash flows (undiscounted) that the software will generate. If this amount is less than the book value, impairment exists.
3. Fair Value Measurement: Measure the impairment loss as the difference between book value and fair value (discounted cash flows)
4. Documentation: Record the impairment loss and document your analysis for audit purposes

Example:

• Capitalized software cost: $500,000 (net book value after amortization: $350,000)
• Estimated future undiscounted cash flows: $300,000
• Impairment indicator exists (book value $350,000 > undiscounted cash flows $300,000)
• Fair value based on discounted cash flows: $250,000
• Impairment loss: $350,000 - $250,000 = $100,000

Audit-Ready Documentation: What Standards Require

Auditors will request documentation supporting your capitalization and amortization decisions. Prepare:

1. Software Capitalization Policy

   • Defines which standard applies to which projects
   • Outlines phase transition criteria
   • Documents materiality thresholds
   • Specifies useful life assumptions

2. Project Authorization Documents

   • Approval memos or steering committee minutes
   • Dated project charters
   • Budget authorization forms
   • Evidence of management commitment

3. Cost Tracking and Allocation

   • Timesheets or project tracking showing labor allocation
   • Vendor invoices for third-party costs
   • Allocation methodology for shared costs
   • Documentation of which costs were capitalized vs. expensed

4. Phase Transition Documentation

   • Evidence of when Phase 1 ended and Phase 2 began
   • Evidence of when Phase 2 ended and Phase 3 began
   • Approval for software placement into service
   • Testing completion documentation

5. Useful Life Justification

   • Analysis supporting useful life assumptions
   • Historical data on software retirements or replacements
   • Industry benchmarking data
   • Planned replacement schedules

6. Impairment Testing Analysis

   • Identification of impairment indicators
   • Cash flow projections supporting fair value
   • Analysis of obsolescence or technological change
   • Board-level documentation of decisions

Automating Audit Trail Creation

The challenge: Manual tracking of Phase 2 activities creates documentation gaps and audit headaches. Finance teams often struggle to reconstruct what happened months or years after development occurred.

Systems like Glue solve this by automatically creating audit trails. By monitoring code repositories, issue tracking, and deployment logs, Glue captures which engineers worked on which components, what activities were performed, and when Phase transitions occurred. This produces:

• Real-time capitalization tracking: Finance sees costs accumulating by project and phase
• Automatic phase identification: Based on project status and approval dates
• Complete audit trail: Every cost classification decision backed by code and activity evidence
• Reduced manual burden: No need to reconstruct timesheets or manager estimates

This transforms impairment testing and audit preparation from retrospective exercises into continuous monitoring.

Special Considerations: Cloud Computing and SaaS

The treatment of SaaS implementations and cloud services deserves special attention. ASU 2018-15 clarifies that costs of configuration and customization of cloud computing arrangements are capitalized if they create or enhance an intangible asset controlled by you. However, implementation services (labor) are typically expensed.

Example:

• SaaS implementation project cost: $150,000
• Vendor setup and configuration: $60,000 (CAPITALIZED)
• Your team's implementation labor: $50,000 (EXPENSED)
• Training and documentation: $40,000 (EXPENSED)

This distinction has tripped up many organizations that assumed all SaaS implementation costs were expensed.

Building Your Decision Framework

The most effective organizations build a decision matrix for their specific situations:

The Path Forward

GAAP software capitalization requires precision in determining which standard applies, disciplined phase transition documentation, and rigorous cost tracking. The stakes are high—auditors expect complete documentation, and errors can trigger restatements.

The most sophisticated organizations move beyond manual processes. By automating work classification and audit trail creation, you ensure capitalization accuracy, pass audits with documentation you didn't manually create, and free your finance and engineering teams from the burden of spreadsheet tracking.

Your financial statements and your next audit depend on getting these distinctions right.

---

Ready to streamline GAAP software capitalization? Glue automatically monitors engineering work to identify phases, classify costs, and create audit trails for both ASC 350-40 and ASC 985-20 situations. Speak with our accounting technology specialists to see how agent-assisted tracking transforms your software capitalization process.

---

Related Reading

• Capitalizing Software Development Costs: A CFO's Complete Guide
• Capitalizing Software Implementation Costs Under GAAP
• Software Productivity: What It Really Means and How to Measure It
• Technical Debt: The Complete Guide for Engineering Leaders
• DORA Metrics: The Complete Guide for Engineering Leaders

Frequently Asked Questions

What are the best software capitalization tracking tools for engineering teams?

The leading software capitalization tracking tools include Glue (AI-powered agent that automatically classifies engineering work into capitalizable phases), Anrok (tax and compliance automation with R&D tracking), Apptio (IT financial management), FloQast (accounting workflow automation), and Productiv (SaaS spend intelligence). The best tools automatically monitor engineering activity from Git, Jira, and CI/CD to classify costs by development phase — preliminary, application development, and post-implementation — without requiring engineers to manually log time. Look for platforms that generate audit-ready documentation and support both ASC 350-40 and ASC 985-20 compliance requirements.

What is the difference between ASC 350-40 and ASC 985-20?

ASC 350-40 covers internal-use software where the company builds or buys software for its own operations. ASC 985-20 covers software developed for sale or licensing to external customers. The capitalization criteria, timing, and amortization rules differ significantly between these two standards.

When can you start capitalizing software development costs under GAAP?

Under ASC 350-40 for internal-use software, capitalization begins during the application development stage after preliminary project planning is complete and management commits to the project. Under ASC 985-20 for external-sale software, capitalization begins after technological feasibility is established.

What software costs cannot be capitalized?

Costs that cannot be capitalized include preliminary project stage activities like research and brainstorming, post-implementation training and maintenance costs, data conversion costs for internal-use software, and general and administrative overhead not directly tied to development. For a full breakdown of capitalizable vs non-capitalizable costs, see our CFO's guide to capitalizing software development costs.