Glueglue
AboutFor PMsFor EMsFor CTOsHow It Works
Log inTry It Free
Glueglue

The Product OS for engineering teams. Glue does the work. You make the calls.

Monitoring your codebase

Product

  • How It Works
  • Platform
  • Benefits
  • Demo
  • For PMs
  • For EMs
  • For CTOs

Resources

  • Blog
  • Guides
  • Glossary
  • Comparisons
  • Use Cases
  • Sprint Intelligence

Top Comparisons

  • Glue vs Jira
  • Glue vs Linear
  • Glue vs SonarQube
  • Glue vs Jellyfish
  • Glue vs LinearB
  • Glue vs Swarmia
  • Glue vs Sourcegraph

Company

  • About
  • Authors
  • Contact
AboutSupportPrivacyTerms

© 2026 Glue. All rights reserved.

Blog

Capitalizing Software Development Costs: A CFO's Complete Guide

Learn when to capitalize vs expense software development costs under GAAP. The three phases, common audit risks, and how automation eliminates manual tracking.

GT

Glue Team

Editorial Team

March 5, 2026·8 min read
GAAP software capitalizationapplication development phasecapitalizing software development costsengineering cost accountingpost-implementation costspreliminary project phasesoftware asset capitalizationsoftware development capitalization rules

Capitalizing Software Development Costs: A CFO's Complete Guide

At Salesken, our engineering budget was roughly 45% of operating costs. Whether those costs were capitalized or expensed had a material impact on our EBITDA — and our board conversations. I spent more time than I'd like to admit working with our CFO to build a classification framework that both engineering and finance could actually use.

Software development costs represent one of the most complex accounting decisions CFOs and finance teams face today. With engineering teams spending millions annually on internal software projects, understanding when these costs qualify for capitalization—rather than immediate expensing—can significantly impact your balance sheet, cash flow statements, and tax position.

This guide walks you through the definitive rules for capitalizing software development costs under GAAP, the three distinct phases where capitalization decisions matter, and practical strategies to maintain audit-ready documentation without burdening your engineering teams with manual time tracking.

Why Capitalizing Software Costs Matters to Your Bottom Line

When you capitalize software development costs, you're creating an intangible asset on your balance sheet that depreciates (or amortizes) over time. When you expense them, they hit your profit and loss statement immediately. This distinction affects:

  • Operating margins (capitalization reduces current period expenses)
  • Cash flow analysis (capitalization appears in investing activities)
  • Debt covenants (asset-to-liability ratios are affected)
  • Tax position (section 179 and bonus depreciation implications)
  • Audit complexity (investors and auditors scrutinize capitalization decisions)

The challenge: ASC 350-40 (internal-use software capitalization) requires precise documentation of which development activities fall into which phase. Get this wrong, and you risk audit adjustments, restatements, or aggressive examinations by the IRS.

The Three Phases of Software Development

Under ASC 350-40, software development activities fall into three distinct phases, each with different capitalization treatment. Understanding these phases is the foundation of correct accounting.

Phase 1: Preliminary Project Stage

The preliminary project stage runs from initial conceptualization through the completion of your project plan. This phase includes:

  • Evaluating alternative systems
  • Determining feasibility and performance requirements
  • Selecting vendors or platforms
  • Planning the overall architecture
  • Cost-benefit analysis and approval processes
  • High-level design documentation
  • Initial vendor selection and contract negotiations

Capitalization Treatment: These costs are EXPENSED immediately. You cannot capitalize preliminary project costs, even if the project eventually proceeds. This includes management meetings, consultant reviews, and planning activities.

Finance Reality Check: Many organizations struggle here because these activities feel like essential groundwork. However, GAAP treats preliminary work as period costs, not asset creation. If your CFO or audit team challenges this, cite ASC 350-40-25-1, which explicitly excludes preliminary project stage costs from capitalization.

Phase 2: Application Development Stage

Once you've approved the project plan and authorized development to begin, you enter the application development stage. This is where the actual capitalization opportunity exists.

Capitalizable costs in this phase include:

  • Software design and architecture work (detailed design, not conceptual)
  • Development labor (engineers writing code for the system)
  • Software testing specifically tied to the application being built
  • Purchased software components and libraries for this project
  • Data conversion and migration directly related to the new system
  • Infrastructure costs directly identifiable to development (development servers, cloud resources)
  • Third-party integration costs and API development

Capitalization Treatment: These costs ARE capitalized as long as they meet the criteria above. You accumulate them in construction-in-progress and then transfer them to the intangible asset account when the system is placed in service.

Critical Distinction: This is where the time-tracking challenge emerges. Your engineering team needs to segregate time spent on application development from other activities. But here's the practical issue: engineers work on multiple projects, context-switch frequently, and rarely track their time in detail suitable for accounting purposes.

Phase 3: Post-Implementation Stage

Once the software is complete and placed into service, you enter the post-implementation stage. This phase includes:

  • System stabilization and minor bug fixes (typically within 60-90 days)
  • Training and documentation finalization
  • Conversion activities and data loading
  • Parallel system operation with legacy systems
  • Remediation of identified issues discovered during initial operation

Capitalization Treatment: These costs are EXPENSED immediately. Even though the software exists, post-implementation costs are treated as period expenses. The exception: significant enhancements or modifications that extend useful life are capitalized as Phase 2 activities.

Common Audit Risks and Red Flags

Auditors and examiners scrutinize software capitalization more heavily than most accounting areas because the materiality is often significant. Here are the most common issues they flag:

1. Phase Timing Disputes Auditors often question when Phase 1 ends and Phase 2 begins. Have clear documentation of your project authorization and approval process. A formal project charter or steering committee approval memo dated and stamped creates the boundary.

2. Allocated Costs That Don't Belong If you're allocating IT infrastructure, management overhead, or corporate IT support to software projects, auditors will push back. These are period costs, not project costs. Only directly identifiable costs should be capitalized.

3. Maintenance Activities Capitalized as Development This is perhaps the most frequent adjustment. When you ship Version 1.0 and spend the next quarter fixing bugs and stabilizing the system, those are maintenance costs (expensed). Only enhancements that create new functionality qualify for capitalization.

4. Inadequate Documentation of Time and Activities If you can't produce timesheets, project tracking, or assignment documentation showing which engineers worked on the software development (versus other duties), auditors will either reduce your capitalization or disallow it entirely.

5. Mixed Internal and External Development If some development was outsourced to vendors, ensure you're treating vendor invoices the same way as employee time. Sometimes organizations capitalize vendor costs but fail to capitalize the internal labor doing equivalent work.

How Automated Classification Eliminates Manual Time Tracking

The fundamental problem in software capitalization is the accuracy and burden of tracking engineering time. Traditionally, CFOs face two painful options:

  1. Require detailed timesheets: Engineers hate filling out timesheets, and accuracy suffers. You end up with rounded entries, memory-based logs, and estimates rather than facts.

  2. Rely on manager estimates: Managers provide rough allocations (e.g., "that engineer spent 60% on Project A, 40% on Project B"), which lacks the documentation rigor auditors demand.

There's a third way: automated agent-based classification.

Systems like Glue monitor repository commits, pull requests, issue tracking, and code deployment patterns to automatically classify engineering work. By analyzing:

  • Which repository or codebase the work targets
  • The type of activity (feature development, bug fix, refactoring, optimization)
  • The development phase of the project
  • The issue or feature ticket designation

Glue's AI agents can automatically classify work into capitalization categories with an audit trail. This approach delivers:

  • Accuracy: Based on actual development artifacts, not time estimates
  • Audit Trail: Complete documentation of how each activity was classified
  • Reduced Burden: No manual timesheets or manager estimation
  • Consistency: Same classification rules applied across all engineers
  • Real-Time Visibility: Finance sees capitalization accumulation as work happens, not after the fact

This transforms software capitalization from a painful audit exercise into a continuous, data-driven process.

Building Your Capitalization Policy

Every organization should document a formal software capitalization policy that covers:

  1. Definition of "software development" in your context (internal tools, products, platform components)
  2. Phase transition criteria (how you determine when Phase 1 ends and Phase 2 begins)
  3. Cost inclusion rules (which cost types are capitalized)
  4. Documentation requirements (what evidence you'll maintain for audit purposes)
  5. Useful life assumptions (how long the software asset will be amortized)
  6. Impairment testing (when you reassess whether the asset maintains its value)

This policy should be approved by your audit committee and disclosed in your accounting policy footnotes if your organization is public or subject to SEC reporting.

The Path Forward

Capitalizing software development costs correctly requires clear phase definitions, rigorous time tracking, and ongoing discipline. The complexity increases with every new project, every acquisition that brings new codebases, and every audit cycle.

The most sophisticated finance organizations are moving beyond manual processes to automated, agent-assisted classification. By leveraging tools that monitor actual development activity, you can capitalize software costs with confidence, pass audits with documentation you didn't have to manually create, and give engineering teams back the hours they'd otherwise spend on timesheets.

Your balance sheet integrity—and your next audit—depends on getting this right.


Ready to eliminate manual software cost tracking? Glue automates the classification of engineering work, creating the audit trail you need while eliminating the manual burden on your team. Schedule a conversation with our finance engineering specialists to see how automated work classification transforms your capitalization process.


Related Reading

  • Capitalized Software GAAP: ASC 350-40 vs ASC 985-20 Compliance
  • Capitalizing Software Implementation Costs Under GAAP
  • Technical Debt: The Complete Guide for Engineering Leaders
  • Software Productivity: What It Really Means and How to Measure It
  • DORA Metrics: The Complete Guide for Engineering Leaders

Author

GT

Glue Team

Editorial Team

Tags

GAAP software capitalizationapplication development phasecapitalizing software development costsengineering cost accountingpost-implementation costspreliminary project phasesoftware asset capitalizationsoftware development capitalization rules

SHARE

Keep reading

More articles

blog·Mar 5, 2026·7 min read

Engineering Copilot vs Agent: Why Autocomplete Isn't Enough

Understand the fundamental differences between coding copilots and engineering agents. Learn why autocomplete assistance isn't the same as autonomous goal-driven systems.

GT

Glue Team

Editorial Team

Read
blog·Mar 5, 2026·19 min read

Product OS: Why Every Engineering Team Needs an Operating System for Their Product

A Product OS unifies your codebase, errors, analytics, tickets, and docs into one system with autonomous agents. Learn why teams need this paradigm shift.

GT

Glue Team

Editorial Team

Read
blog·Mar 5, 2026·12 min read

Devin AI Alternatives: Why You Need Agents That Monitor, Not Just Code

Devin writes code—but it's only 20% of engineering. Compare AI coding agents (Devin, Cursor, Copilot) with AI operations agents that handle monitoring, triage, and incident response.

GT

Glue Team

Editorial Team

Read

Related resources

Glossary

  • What Is Developer Onboarding?
  • What Is Bus Factor?

Use Case

  • Glue for Competitive Gap Analysis

Stop stitching. Start shipping.

See It In Action

No credit card · Setup in 60 seconds · Works with any stack