Feasibility vs Development: When to Capitalize R&D Costs for SaaS and Deeptech Startups

Feasibility Phase vs. Development Phase: Drawing the Line

For an early-stage SaaS or Deeptech startup, your R&D spending is both your biggest investment and a major driver of your burn rate. The decision of when to capitalize R&D costs can feel like a complex accounting challenge, but it directly shapes the financial story you tell investors. Misclassifying these costs distorts key metrics like runway and profitability, creating confusion during fundraising and inviting challenging questions from tax bodies like the IRS or HMRC. The goal is not to become an accounting expert, but to build a simple, defensible process for distinguishing true research from focused development. Getting this right provides a more accurate picture of your company’s financial health without creating an administrative burden. For more, see the R&D Project Accounting & Capitalisation hub.

The Core Concept: Defining Technological Feasibility

The entire decision of when to capitalize R&D costs hinges on a single concept: technological feasibility. This is the specific point in time when you have successfully proven that your core technology, product, or feature can actually be built. Everything before this point is the Feasibility or Research Phase, and its costs are expensed. Everything after this point is the Development Phase, and its costs can be capitalized.

The Feasibility Phase (Research): Expense as Incurred

The feasibility phase includes all activities aimed at discovering new knowledge or exploring technical possibilities. Think brainstorming, evaluating alternative technologies, building proofs-of-concept, and designing initial models. The outcome is fundamentally uncertain. Under both US GAAP (ASC 730) and international standards like IAS 38, these costs must be expensed as they are incurred, hitting your Profit & Loss (P&L) statement immediately and reducing your reported profit for the period.

The Development Phase: Capitalize After Feasibility

The development phase begins once technological feasibility is established. At this stage, you are no longer exploring *if* something can be built; you are actively building the final product according to a plan. Activities include detailed design, coding, integration, and testing. These costs can be capitalized, meaning they are recorded as an intangible asset on your balance sheet instead of being an immediate expense on your P&L. This presents a stronger financial position, at least on paper.

IFRS vs GAAP R&D Treatment: Key Differences

While the principle of technological feasibility is universal, its application differs between US and international accounting standards. For US companies, ASC 730 is very strict, allowing capitalization only after technological feasibility is clearly established and the software is nearly complete. For more on this, see the practical guidance on FASB and software costs guidance from major accounting firms.

Companies in the UK and other regions following IFRS use IAS 38, which provides a more detailed, criteria-based approach. Under IAS 38, development costs can be capitalized when a company can demonstrate all of the following:

• The technical feasibility of completing the intangible asset so that it will be available for use or sale.
• Its intention to complete the intangible asset and use or sell it.
• Its ability to use or sell the intangible asset.
• How the intangible asset will generate probable future economic benefits.
• The availability of adequate technical, financial, and other resources to complete the development and to use or sell the intangible asset.
• Its ability to measure reliably the expenditure attributable to the intangible asset during its development.

This framework gives companies a clearer, albeit still subjective, checklist to justify their project phase accounting decisions.

A Practical Checklist for When to Capitalize R&D Costs

Knowing the theory is one thing, but applying it to a fast-moving sprint cycle is another. To draw a clear line, you must pinpoint the exact moment you cross from research into development. A scenario we repeatedly see is a team struggling to define this crossover for a new software feature, which can lead to inconsistent R&D expense recognition.

Consider a SaaS startup building an AI-powered analytics tool. Here is how the phases break down:

• Example: Feasibility Phase (Expense These Costs)
• The data science team is tasked with researching various machine learning models to predict customer churn. They build several small, isolated proofs-of-concept using sample data to see which algorithm provides the most accurate predictions. They also evaluate third-party APIs versus building a model in-house. Because the outcome is unknown and they are still figuring out the *how* and the *if*, all salaries and cloud computing costs associated with this exploration are expensed in the period they are incurred.
• Example: Development Phase (Capitalize These Costs)
• After two months of research, the team has selected a specific prediction model and proven it works reliably with a high-quality data set. A formal project to integrate this model into the production application begins. Engineers are now writing production-grade code, building the user interface for the new dashboard, integrating the model with the main application database, and conducting quality assurance testing. Technological feasibility is established, so the direct labor costs of these engineers can now be moved to the balance sheet as an asset.

Use this five-point checklist to formalize the decision for any project:

1. Is the project clearly defined? You must move from a general idea (“Let's explore AI”) to a specific, documented project plan (“Build the AI Churn Predictor v1”).
2. Is the research complete? All critical technological uncertainties must be resolved. In our example, the best algorithm has been chosen and validated.
3. Do you have a final design or model? There should be a technical specification, even a lightweight one, that engineers are building against. This proves you are past the exploratory stage.
4. Are resources committed? You must have assigned the necessary engineers, designers, and budget to see the project through to completion and launch.
5. Is there a clear commercial goal? You must intend to use this feature to generate revenue or use it internally to improve operations, satisfying the intangible asset criteria for future economic benefit.

If you can confidently answer 'yes' to these questions, you have likely reached the development phase and can begin capitalizing research costs associated with the build.

The Minimum Viable Paper Trail: How to Prove Your Decision

For a startup with no full-time CFO, the fear of creating bureaucratic overhead is real. However, insufficient documentation is a major risk that can lead to costly audit adjustments or challenges from the IRS or HMRC. The reality for most Series A startups is more pragmatic: you can meet compliance and tech startup financial compliance requirements using the tools you already have.

Your goal is to create contemporaneous evidence, meaning proof that is generated at the same time the decision is made. This does not require a complex new process.

1. The Decision Memo

Create a simple, one-page document in Notion, Confluence, or Google Docs when you decide to start capitalizing a project. It should state the date, the project name, and a clear declaration: “As of [Date], Project X has achieved technological feasibility. Associated direct development costs will be capitalized moving forward, in accordance with our accounting policy.” This memo is the anchor for your decision and the first thing an auditor will ask for.

2. Link to Your Existing Work

Your evidence already exists in your project management and version control tools. The decision memo should simply reference it. This connects your accounting treatment directly to your operational reality.

• In Jira or Asana: Link to the specific epic or project board that marks the shift from “Research” tickets to “Build” tickets.
• In GitHub or GitLab: Link to the final proof-of-concept repository or the technical specification document that was approved.
• In Notion or Confluence: Link to the final project plan or technical design document that outlines the scope of work.

3. Track Direct Labor Costs

Capitalizable costs are primarily the salaries and wages of employees working directly on the project, such as software engineers and QA testers. You do not need a fancy system. Time can be tracked within Jira tickets or estimated based on developer allocation. For example, if two engineers are 100% dedicated to the project for a month, their salary costs for that month are capitalizable. Keep the calculation simple, document it in a spreadsheet, and book the journal entry in your accounting software like QuickBooks or Xero.

How Capitalization Impacts Your Financial Story

Understanding the software development costs accounting rules is crucial because it directly affects your financial statements and key investor metrics. However, one point must be absolutely clear: This doesn’t change your cash burn. The cash has already left your bank account to pay salaries. Capitalization is a non-cash accounting adjustment that changes how that spending is *reported*.

Its main impact is on the P&L statement, which influences metrics like net income and EBITDA (Earnings Before Interest, Taxes, Depreciation, and Amortization). Let’s compare two scenarios for a deeptech startup that spent $150,000 on engineering salaries in one quarter.

In Scenario A, the company expenses everything. The full $150,000 in R&D salaries hits the P&L as an expense. If the company had a net loss of $200,000 before this, its new net loss for the period would be $350,000. No asset is created on the balance sheet.

In Scenario B, the company determines that $90,000 (60%) of that spending occurred after technological feasibility was reached. It capitalizes this portion. Now, only $60,000 hits the P&L as an R&D expense. The new net loss is only $260,000, making the company appear $90,000 more profitable. The capitalized $90,000 is recorded as an intangible asset on the balance sheet, increasing the company's total assets. There is no change to the cash flow from operations, which remains at ($150,000) in both scenarios.

The asset created in Scenario B is then amortized, or expensed gradually, over its estimated useful life, which is typically 3-5 years for software. Instead of a $90,000 hit in one quarter, it becomes a much smaller amortization expense of, for example, $7,500 per quarter for three years. This smooths out your expenses and provides a more stable view of your profitability over time.

Building a Defensible R&D Capitalization Policy

For founders in the UK or USA, navigating software development costs accounting does not have to be a major burden. By focusing on practical steps, you can create a compliant and useful system that strengthens your financial reporting.

• Establish Your Trigger: Use the concept of technological feasibility as the clear, non-negotiable line between an R&D expense and a capitalizable asset. Communicate this definition to your tech lead and product manager so they understand when to flag projects for capitalization.
• Document with Existing Tools: You do not need new software. A simple decision memo in Notion linked to a specific Jira epic and GitHub repository is sufficient proof for auditors and tax authorities like the IRS or HMRC.
• Be Consistent: Once you establish a policy for capitalizing research costs, apply it consistently to all similar projects. Inconsistency is a major red flag during financial due diligence and can undermine the credibility of your financials.
• Know Your Story: Be prepared to explain your capitalization policy to investors. Acknowledge that it improves your P&L and EBITDA but does not change your cash position. This transparency builds trust and shows you have a firm grasp of your company's finances.

Finally, while you can implement these initial steps yourself, plan to have a fractional CFO or accounting advisor review your policy before your first financial audit or a major funding round. This ensures your pragmatic approach holds up to professional scrutiny. Explore the full R&D Project Accounting & Capitalisation hub.

Frequently Asked Questions

Q: What is the main difference between US GAAP and IFRS for R&D capitalization?
A: The main difference is the strictness of the criteria. US GAAP (ASC 730) is generally stricter, allowing capitalization only at a later stage when a project is nearly complete. IFRS (IAS 38) allows for capitalization earlier in the development phase, provided a company can meet six specific criteria demonstrating technical and commercial viability.

Q: Can we capitalize costs for bug fixes or ongoing maintenance?
A: No. Costs related to maintaining an existing software product, including bug fixes, performance tuning, and minor updates, are considered operational expenses. They do not create a new asset or significantly enhance an existing one, so they must be expensed as incurred on the P&L statement.

Q: How does capitalizing R&D costs affect my R&D tax credit claim?
A: The rules for R&D capitalization and R&D tax credits are separate but related. In both the UK and US, you can typically claim tax credits on qualifying R&D expenditures regardless of whether they are expensed or capitalized for accounting purposes. However, the documentation for capitalization can often support your tax credit claim by demonstrating the project's technical uncertainty.

Q: Do I need a full-time accountant to manage this?
A: Not necessarily at the early stages. Founders or a tech lead can establish the trigger point for technological feasibility and create the initial documentation. However, it is highly recommended to have a fractional CFO or an experienced accountant review your policy and calculations quarterly to ensure they are accurate and defensible.