Accounting Policy
6
Minutes Read
Published
June 6, 2025
Updated
June 6, 2025

US GAAP for SaaS and Deeptech: Capitalizing versus Expensing Software Development Costs

Glencoyne Editorial Team
The Glencoyne Editorial Team is composed of former finance operators who have managed multi-million-dollar budgets at high-growth startups, including companies backed by Y Combinator. With experience reporting directly to founders and boards in both the UK and the US, we have led finance functions through fundraising rounds, licensing agreements, and periods of rapid scaling.

For SaaS and Deeptech startups, your engineering team is almost always the single largest expense. Every dollar spent on development salaries and tools is a direct trade-off against runway. But from an accounting perspective, not all of that spending is the same. Some of it is an immediate expense that reduces this month’s profit, while some is an investment that builds a long-term company asset. Understanding internal-use software capitalization is not just a compliance exercise for US companies; it is a strategic tool for accurately representing your company’s value. The key is knowing which software development costs to capitalize and which to expense, a process governed by a specific US GAAP framework. See our accounting policy documentation hub for templates and examples.

Foundational Understanding: What It Means to Capitalize Software Costs

In the simplest terms, capitalizing a cost means you do not record it as an immediate expense on your Profit & Loss (P&L) statement. Instead, you record it as an asset on your balance sheet. Think of it like buying a building. You would not put the entire purchase price on one month's P&L; you would add the building to your balance sheet and gradually expense its cost over many years through depreciation.

Software development costs work similarly. When you capitalize the costs of building a new software feature, you formally recognize that this work has created a tangible asset with future economic value. This has two significant impacts on your financials. First, it results in higher reported profit (or a smaller loss) in the short term, since the large development expense is not hitting your P&L all at once. Second, it increases the total assets on your balance sheet, which can present a stronger financial position during fundraising or due diligence.

This newly created asset is then expensed over time through a process called amortization. According to accounting rules, capitalized software assets are amortized on a straight-line basis over their estimated useful life. While Deloitte discusses considerations for timing amortization under different development methodologies, the reality for most startups is more pragmatic: a typical useful life for capitalized software is 3-5 years. This process systematically allocates the cost of the asset to your P&L over the period it is expected to generate value.

The ASC 350-40 Framework for Internal-Use Software Capitalization

The governing standard for internal-use software is US GAAP, specifically Accounting Standards Codification (ASC) 350-40. This framework provides clear software capitalization rules by breaking down a project into three distinct phases. The phase a specific activity falls into determines whether its associated costs should be expensed immediately or capitalized. Correctly applying this three-stage approach is the foundation of a compliant software capitalization policy. For a deeper dive into the specific language of the standard, ASC 350-40 provides the full text.

Stage 1: The Preliminary Project Stage (Expense)

This is the "idea" or planning phase. It includes all activities that occur before management commits to a specific development project. The work here is exploratory, conceptual, and strategic. Under US GAAP, all costs associated with this stage must be expensed as they are incurred, often as Research and Development (R&D). Per the guidelines in ASC 350-40, costs incurred in the Preliminary Project Stage for planning and research must be expensed as R&D.

Example activities that are always expensed include:

  • Brainstorming new features or products.
  • Evaluating technological feasibility and alternative technology solutions.
  • Gathering and documenting initial system requirements.
  • Proving out a concept with a high-level prototype.

If your engineering team spends a week debating three potential architectural approaches for a new AI module, the salaries for that week are expensed. No asset has been created yet.

Stage 2: The Application Development Stage (Capitalize)

This is the “building” phase, where the actual creation of the software takes place. This stage begins once the preliminary work is complete and management has formally authorized and committed funding to the project. The critical rule is that capitalization of software development costs is only permitted during the Application Development Stage, according to ASC 350-40.

Capitalizable costs are the direct costs associated with creating new functionality. This includes direct labor costs like salaries and benefits for engineers writing code, as well as fees for third-party developers. If you hire a contractor to build out a new analytics dashboard, their invoice is a capitalizable cost. For guidance on consistent categorization, see our Cost Classification Policy for Startup Accounting.

However, not every cost during this phase qualifies. Non-capitalizable costs include indirect costs like general overhead, administrative expenses, team training, and data conversion. Sending your development team to a conference or training them on a new programming language are operational expenses, not direct costs of building the asset.

Example activities that are typically capitalized include:

  • Designing the software configuration and interfaces.
  • Writing the code for new features and modules.
  • Installation of hardware directly related to the project.
  • Testing, including unit, integration, and quality assurance, performed during the coding phase.

Stage 3: The Post-Implementation and Operation Stage (Expense)

This phase begins once the software has been tested and is ready for its intended use. In essence, the asset is built and is now “live.” From this point forward, the focus shifts from creation to maintenance. Consequently, ASC 350-40 requires that costs incurred in the Post-Implementation/Operation Stage for maintenance and support must be expensed.

This distinction is crucial for ongoing development. Work that creates significant new functionality could potentially be treated as a new development project, cycling back to Stage 2. However, work that keeps the existing software running, fixes bugs, or provides minor enhancements is considered maintenance and must be expensed.

Example activities that are always expensed include:

  • Routine bug fixes and troubleshooting.
  • Ongoing customer support and help desk activities.
  • Server hosting, cloud infrastructure, and other operational costs.
  • Minor tweaks and performance optimizations to existing features.

For operational policy on expense recognition, refer to our Expense Recognition Policy.

A Practical Playbook for Implementing ASC 350-40

Understanding the theory is one thing; implementing a system to track software development expenses is another, especially with a lean finance team. The goal is to create a practical, repeatable process that provides the audit-ready documentation needed to support your capitalization decisions.

Step 1: Establish a Formal Capitalization Policy

First, document your approach in a simple internal memo. This document should state your materiality threshold, your defined useful life for software assets, and your process for tracking costs. A capitalization threshold (e.g., $10,000 or $25,000) is a common policy to avoid tracking trivial costs. This means you will not bother with capitalization for very small projects, which saves significant administrative effort.

Step 2: Implement a Tracking System

What founders find actually works is a simple combination of project management and time-tracking tools you likely already use. You do not need expensive, specialized software.

  1. Tag Projects in Jira: Create specific tags, labels, or epics in your project management software to clearly identify work as either “Capitalizable” (new features) or “Expense” (maintenance, bug fixes). This should be done when a project is first defined.
  2. Track Time Against Tags: Require your engineering team to log their hours in a time-tracking tool like Clockify or Harvest against these specific Jira tickets or epics. This creates a direct link between an engineer's time and a specific type of work.
  3. Calculate Costs in a Spreadsheet: At the end of each month, export the time-tracking data. You can then calculate the capitalizable labor cost for each engineer by multiplying their hours on “Capitalizable” projects by their fully-loaded hourly rate. This rate is typically their annual salary plus benefits, divided by total annual work hours. For a startup, this calculation is usually managed in a simple spreadsheet.

Step 3: Calculate and Record the Asset

With the data from your tracking system, you can perform the capitalization calculation. This calculation becomes the basis for your journal entry.

Example Capitalization Calculation:

Consider a new feature project, “Module X,” that took one month.

  • Two engineers worked on it, each with a fully-loaded annual salary of $150,000.
  • Their monthly cost is $12,500 each ($150,000 / 12).
  • Engineer A spent 80% of their time on Module X (a capitalizable project).
  • Engineer B spent 50% of their time on Module X and 50% on bug fixes (an expense).

Calculation:

  • Capitalizable cost from Engineer A: $12,500 * 80% = $10,000
  • Capitalizable cost from Engineer B: $12,500 * 50% = $6,250
  • Total Capitalized Software for the month: $16,250

This $16,250 would be recorded as an asset on your balance sheet, and you would begin amortizing it over its useful life. For practical guidance on setting useful lives and depreciation policies, see our Fixed Asset Policy for Growing Startups. This process, documented in your policy memo, becomes the cornerstone of your audit-ready documentation. For templates, see our guide on Accounting Policy Documentation for US Startups.

Key Principles for Compliant Software Capitalization

For a growing SaaS or Deeptech company, accounting for software projects correctly is essential for financial health and investor reporting. The ASC 350-40 framework provides the rules, but practical implementation is what matters. Remember the simple breakdown: the idea phase is expensed, the building phase is capitalized, and the live and maintenance phase is expensed. The distinction between developing new features versus fixing existing ones is the core of the capitalization decision.

Implementing a system does not require expensive software. A disciplined process using Jira tags, time-tracking software, and a summary spreadsheet is sufficient to create the documentation you need. By defining a clear software capitalization policy in a simple memo and applying your tracking system consistently, you create a robust, auditable record. This process ensures your financial statements accurately reflect the value of the technology asset you are building. As the FASB continues to review software cost accounting, you can follow commentary and updates from sources like KPMG. For broader templates, see our accounting policy documentation hub.

Frequently Asked Questions

Q: What is a typical useful life for capitalized software under ASC 350-40?
A: While ASC 350-40 does not prescribe a specific period, a typical useful life for capitalized software at a startup is between three to five years. The period should represent the time over which the software is expected to generate economic value before it becomes technologically obsolete or requires significant replacement.

Q: Can I capitalize costs related to fixing bugs?
A: No. Under US GAAP, bug fixes are considered maintenance activities. They restore the software to its originally intended functionality but do not add new capabilities. Therefore, costs associated with troubleshooting and fixing bugs must be expensed as incurred in the post-implementation stage.

Q: How does ASC 350-40 differ from rules for software sold to customers?
A: ASC 350-40 applies to internal-use software, which is software acquired or developed for your company's own operations. Software developed to be sold, leased, or marketed to external customers is governed by a different standard, ASC 985-20, which has different criteria for when capitalization begins.

Q: Do I need special software to track capitalizable development costs?
A: Not necessarily. While dedicated software exists, most early-stage companies can create an audit-ready system using tools they already have. A combination of disciplined tagging in a project management tool like Jira, consistent time-tracking, and a summary spreadsheet is generally sufficient for compliance.

This content shares general information to help you think through finance topics. It isn’t accounting or tax advice and it doesn’t take your circumstances into account. Please speak to a professional adviser before acting. While we aim to be accurate, Glencoyne isn’t responsible for decisions made based on this material.

Curious How We Support Startups Like Yours?

We bring deep, hands-on experience across a range of technology enabled industries. Contact us to discuss.