How Deeptech and SaaS Startups Should Capitalize Software Under ASC 350-40

Software Capitalisation for SaaS and Deeptech Startups Under ASC 350-40

For an early-stage SaaS or Deeptech startup, managing burn rate is everything. Every dollar spent on engineering feels like a direct hit to your runway. Yet, as you prepare for due diligence or your first audit, the question of capitalizing software development costs under US GAAP becomes unavoidable. It presents a difficult trade-off: improve short-term profitability metrics on paper, but create a long-term drag on your P&L. Accurately tracking these costs without burdening your engineering team or requiring an enterprise-level ERP seems impossible, especially when you’re running finance on QuickBooks and spreadsheets.

A practical understanding of ASC 350-40 is essential to solve this. This guidance defines the accounting for costs of internal-use software (ASC 350-40) for US companies, providing a framework to navigate these complexities. Note that this article focuses exclusively on US GAAP; other regions follow different standards like IFRS, which are not covered here.

When Should You Start Capitalizing Software Development Costs?

Deciding when to formalize software capitalization isn’t tied to a specific funding round. The trigger is materiality. When your engineering spend becomes a significant portion of your budget and you anticipate needing audited financials, it’s time to implement a process. The core concept is the distinction between a P&L expense and a Balance Sheet asset. An expense, like a marketing salary, hits your income statement immediately and reduces your current period’s profit. An asset, like a new server, is recorded on your balance sheet, and its cost is spread over its useful life.

Capitalizing software development costs moves a portion of your engineering spend from an immediate expense to a balance sheet asset. This improves short-term metrics like EBITDA, which can be appealing to investors. However, this asset must then be amortized, meaning a piece of its cost is expensed on your P&L each month for years. The standard amortization period for capitalized software assets is typically 3 to 5 years under US GAAP. This creates a long-term, predictable drag on your profitability.

The reality for most Pre-seed to Series B startups is more pragmatic: begin formalizing this process when you can no longer justify expensing all engineering costs as R&D.

The Three Stages of Internal-Use Software Accounting

To properly handle internal-use software accounting, ASC 350-40 splits the development lifecycle into three distinct phases. Correctly classifying activities into these buckets is the most critical part of ASC 350-40 compliance. Getting this wrong can lead to misstating your financials, a problem you do not want to discover during due diligence. Each stage has a different accounting treatment.

1. The Preliminary Project Stage (Expense)

Costs in the Preliminary Project Stage must be expensed as incurred. This phase includes all the upfront thinking before the decision is made to commit to a project. Think of it as the "ideation and planning" bucket. Activities here include conceptualizing the project, evaluating alternatives, determining requirements, and selecting vendors or consultants. Any time spent on discovery, brainstorming, or initial feasibility studies falls squarely in this category and must hit your P&L immediately.

2. The Application Development Stage (Capitalize)

Once the project has been green-lit and it is probable it will be completed and used as intended, you enter the Application Development Stage. Costs in this stage are capitalized. This is the "building" phase. This bucket includes the direct costs of creating the software, such as designing the architecture, coding, integration, and all forms of testing, including QA and user acceptance testing (UAT). Salaries and benefits for the engineers doing this work, along with fees paid to third-party contractors for development, are the primary costs capitalized here.

3. The Post-Implementation Stage (Mostly Expense)

After the software is deployed and ready for use, you enter the final stage. Costs in the Post-Implementation Stage are generally expensed. This is the "maintenance" bucket, covering ongoing operational costs like training, routine bug fixes, and general support. However, there is a crucial exception: costs are capitalized if they add significant new functionality. For example, fixing a minor UI glitch is an expense. Building an entirely new analytics module that was not part of the original plan would be capitalized, as it represents a significant upgrade.

Building a Lightweight and Auditable Tracking System

The biggest hurdle for founders is tracking this without creating administrative hell for the engineering team. You do not need a complex ERP system. What founders find actually works is a pragmatic approach using the tools you already have: Jira and a spreadsheet.

1. Configure your project management tool. In Jira, create specific labels or components to align with the three accounting stages. For example, you could use CapEx-Dev for new feature development, OpEx-Plan for preliminary research tasks, and OpEx-Maint for bug fixes. Train your engineering leads to apply these tags consistently to all tickets and epics.
2. Associate time and cost with tags. While direct time tracking is an option, it is often met with resistance. A more lightweight method uses story points. At the end of each sprint or month, you can calculate a “cost per story point.” This provides a reasonable allocation basis that auditors generally find acceptable if applied consistently.
3. Calculate the allocation. Based on the cost per story point and the tags applied to completed work, you can determine what to capitalize versus what to expense. Third-party contractor invoices for development work should also be coded to a capitalized software account in QuickBooks if the work falls into the Application Development Stage.

Here is a simple calculation example:

• Total Sprint Engineering Payroll & Benefits: $80,000
• Total Story Points Completed in Sprint: 125
• Cost Per Story Point: $80,000 / 125 = $640

Next, you analyze the completed tickets:

• Story Points tagged CapEx-Dev: 90
• Story Points tagged OpEx-Plan or OpEx-Maint: 35

From this, you can calculate the journal entry for your accounting system:

• Amount to Capitalize: 90 points * $640/point = $57,600
• Amount to Expense: 35 points * $640/point = $22,400

This system connects engineering output directly to financial reporting in a way that is auditable and does not require engineers to fill out timesheets.

Crafting Your Software Capitalization Policy: The Strategic Trade-Offs

Once you have a tracking system, you need to formalize your approach in a written capitalization policy. This document is crucial for consistency and serves as key evidence for your auditors. It does not need to be long, but it must clearly define your company’s rules around several key decisions. Crafting this policy involves strategic trade-offs that balance accurate reporting with operational simplicity.

The first key decision is the amortization period. As noted, the standard amortization period for capitalized software assets is typically 3 to 5 years under US GAAP. A 3-year period accelerates expense recognition, which is more conservative but hits your P&L harder in the short term. A 5-year period smooths the expense over a longer time, improving near-term profitability but extending the drag. Your choice should reflect the software’s estimated useful life.

The second critical component is a 'de minimis threshold'. This is a policy-based rule that allows you to expense smaller projects to avoid the administrative burden of capitalizing immaterial costs. For instance, you might set a threshold that projects under 40 hours are always expensed. This practical measure saves significant time and effort.

Finally, the policy should specify which costs are included (e.g., fully-loaded salaries for developers, third-party contractor fees) and which are excluded (e.g., general and administrative overhead). A scenario we repeatedly see is startups failing to document these rules, leading to inconsistent treatment and difficult questions during an audit.

Software Capitalization Policy Snippet

1. Amortization Period: All capitalized internal-use software assets will be amortized on a straight-line basis over an estimated useful life of three (3) years, beginning the month the software is placed into service.

2. De Minimis Threshold: Individual software development projects with total estimated development-stage labor under 40 hours will be expensed as incurred and will not be subject to capitalization.

Practical Takeaways

For a startup capitalizing software development costs under US GAAP, the key is to start simple and be consistent. You do not need an expensive system; a well-structured process using Jira and spreadsheets can provide the auditable trail you need. Focus on correctly classifying work into the three core buckets defined by ASC 350-40: planning activities are expensed, core development and testing are capitalized, and post-launch maintenance is expensed unless it adds significant new functionality. Your formal capitalization policy is your guide, ensuring everyone applies the rules consistently.

Remember, capitalizing costs improves short-term burn optics by moving expenses to the balance sheet, but it introduces a long-term amortization expense to your P&L. This isn't just an accounting exercise. It’s a strategic financial decision that directly impacts how investors and auditors view the health and scalability of your business. Getting it right provides a clear, compliant picture of how your engineering investment creates lasting value. This process also sets the stage for other asset management requirements, like performing regular impairment testing. For a broader overview, see our hub on Capex, Depreciation, and Intangibles.