Software Capitalization Under ASC 350-40: A Practical Guide to the Capitalize-vs-Expense Decision

A 2024 Gartner survey found that 63% of early-stage SaaS founders misclassify software development costs. The mistake costs them on two fronts: investors discount their financials when classifications look sloppy, and auditors flag the issue during diligence, which can delay funding rounds or sale processes by months.

Software capitalization isn't just an accounting technicality. It directly affects EBITDA, the balance sheet, and how your business looks to lenders, investors, and buyers. The rules under ASC 350-40 — and a major 2025 update — determine which costs hit the income statement immediately and which get spread over years.

This guide walks through what the standard requires, the recent overhaul from ASU 2025-06, the costs you can capitalize, the costs you can't, and the financial-statement consequences of getting it right.

What ASC 350-40 Covers

ASC 350-40 is the FASB standard for internal-use software — software your company builds or buys for its own operations rather than to sell to customers as the primary product. Examples include:

• Internal CRM, ERP, HR, or accounting systems
• Cloud infrastructure tooling and DevOps platforms
• A SaaS platform you operate for customers (the customer accesses it as a service, not as licensed software they install)
• Internal data pipelines, dashboards, and analytics tools
• Custom workflow or back-office automation

If you're selling licensed software that customers install on their own machines, that falls under ASC 985-20 (software for external sale), which has different rules. Most modern SaaS companies fall under ASC 350-40 because customers consume the software as a hosted service.

The core question the standard answers: when you spend money building software, should that cost be expensed immediately or capitalized as an intangible asset and amortized over future periods?

The Old Three-Stage Model (Pre-ASU 2025-06)

For decades, ASC 350-40 used a stage-based framework. Under the legacy guidance still in effect for most filers through 2027, software development falls into three discrete phases.

Stage 1: Preliminary Project Stage

This is the exploratory phase — defining requirements, evaluating technologies, getting demos from vendors, and deciding whether to build, buy, or pass. All costs in this stage are expensed as incurred, similar to research expenses. The reasoning: until management commits, you don't yet have a probable asset.

Activities here include:

• Conceptual formulation and design alternatives
• Vendor demos and technology evaluations
• Cost-benefit analyses and feasibility studies
• Final selection of an approach or vendor

Stage 2: Application Development Stage

Capitalization begins when management authorizes the project, commits funding, and completion is probable. This stage covers actual building — coding, testing, configuring, integrating, and installing.

Capitalizable costs in this stage typically include:

• Salaries and benefits for developers, QA engineers, and project managers (only the time directly attributable to coding, testing, and configuring the software)
• External consulting fees for development work
• Software licenses and tools used to build the application
• Direct costs of materials and services consumed in development
• Interest costs (in limited cases)

Capitalization stops when the software is substantially complete and ready for its intended use — generally when testing is finished and the system is deployed to production, even if rollout is gradual.

Stage 3: Post-Implementation Stage

After go-live, ongoing costs flip back to expense treatment. Training, maintenance, bug fixes, and routine support are all expensed. The exception: enhancements that add new functionality (not just fix or maintain existing functionality) can be capitalized using the same criteria as Stage 2.

The Major 2025 Update: ASU 2025-06

On September 18, 2025, the FASB issued ASU 2025-06, which significantly modernizes ASC 350-40. The update is mandatory for annual periods beginning after December 15, 2027, with early adoption permitted.

The change is structural: the three-stage model is gone. The FASB explicitly removed all references to project stages because the legacy framework didn't fit modern agile and iterative development practices, where requirements evolve and "stages" overlap or run in parallel.

The New Principles-Based Threshold

Under the revised standard, you capitalize software costs only when both of these conditions are met:

1. Management authorization: Management has authorized and committed to funding the project.
2. Probable-to-complete threshold: It is probable that the project will be completed and the software will perform its intended function.

That second test is doing real work. The FASB introduced a concept called significant development uncertainty to evaluate whether completion is probable. You must assess:

• Whether the software includes novel or unproven features that haven't been validated through coding or testing
• Whether performance requirements are still undetermined or subject to substantial revision

If significant uncertainty exists, capitalization must be deferred until the uncertainty is resolved. The FASB has signaled it expects the new rule to result in more software costs being expensed, particularly at SaaS companies where requirements iterate continuously.

What This Means in Practice

For a startup building something genuinely new — an AI agent platform, a novel automation engine — the new rule may push more spending into operating expenses earlier. For mature companies enhancing well-defined systems, the practical impact will be smaller. Either way, the move from a mechanical stage check to a judgment-based threshold means companies need clearer documentation of management decisions, technical feasibility, and project status.

What You Can and Can't Capitalize: A Practical Checklist

Whether you're applying the legacy stage model or the new principles-based test, the line between capitalizable and expensable spending is similar in spirit. Here's a working checklist.

Generally Capitalizable

• Direct labor costs for developers, designers, and QA during the build phase
• Allocated payroll taxes and benefits for those employees
• External consulting and contractor fees for development work
• Software, tools, and cloud infrastructure costs directly consumed in development
• Costs to develop new functionality post-launch (enhancements that materially expand capabilities)
• Costs to develop conversion software (the software that migrates old data to new), as opposed to the data conversion activity itself

Generally Expensed

• Preliminary research, vendor selection, and feasibility analysis
• Training employees on the new system
• Data cleansing, reconciliation, and migration of records
• Routine maintenance, bug fixes, and minor refactoring
• Software costs incurred during periods of significant development uncertainty
• General administrative overhead not directly tied to development
• Marketing, support, and post-launch customer success activities

The Time-Tracking Problem

The biggest practical challenge is allocating engineering time. A senior engineer spending 40 hours per week is unlikely to be doing 100% capitalizable work — they're also debugging production, mentoring teammates, attending standups, and reviewing pull requests for legacy systems. Without a defensible time-tracking method (engineering tickets tagged by project, time-tracking software, or formal allocation surveys), capitalization estimates will fail audit scrutiny.

The Financial Statement Impact

Capitalizing versus expensing the same dollar produces dramatically different financial statements.

Income Statement Effect

A capitalized cost doesn't hit the income statement in the period spent. Instead, it's amortized — typically straight-line over three to five years for internal-use software. So $1M of capitalized engineering spend in Year 1 might create only $200K to $333K of amortization expense each year, leaving Year 1 operating income materially higher.

This is why EBITDA gets a boost from capitalization. Amortization is, by definition, excluded from EBITDA — so capitalizing more development cost shifts dollars from operating expense (which reduces EBITDA) to amortization (which doesn't). Investors who scrutinize SaaS metrics often look at "EBITDA before capitalized R&D" or rule-of-40 calculations using cash R&D to see through this dynamic.

Balance Sheet Effect

Capitalized software shows up as a long-term intangible asset, often labeled "Capitalized Software Development Costs" or similar. This:

• Increases total assets and equity
• Improves return on assets (ROA) only if earnings rise faster than the asset base
• Creates an asset that must be tested for impairment if the project is abandoned or its value declines

If a project is abandoned mid-development, the previously capitalized costs must be written off — which produces a sudden, often material loss. This is one reason the new ASU 2025-06 emphasizes the probable-to-complete threshold so heavily.

Cash Flow Statement Effect

Capitalized development costs are typically classified as investing activities (not operating), which makes operating cash flow look stronger. Sophisticated investors adjust for this when comparing companies — but the headline number still benefits.

Common Mistakes That Get Companies in Trouble

Auditors and acquirers see the same errors over and over.

Capitalizing Pre-Authorization Costs

The classic mistake is capitalizing engineering time spent before management formally approved the project. Without a documented authorization and funding commitment, those costs should have been expensed. Make sure you have meeting minutes, board approvals, or written sign-offs that establish when management committed.

No Project-Level Documentation

If a regulator or auditor asks "show me the projects you capitalized," and you can only point at general engineering spend, you'll lose. You need project-by-project records: scope, authorization date, budget, status, and time charged.

Treating All Engineering Time as Capitalizable

Senior engineers fix bugs, review code, attend meetings, and respond to incidents. None of that is capitalizable. Companies that simply multiply the engineering team's payroll by some percentage rarely survive audit.

Continuing to Capitalize After Launch

The moment the software is ready for its intended use, capitalization stops. Bug fixes, performance tuning, and minor improvements after that point are operating expenses. New, separately scoped features can start a new capitalization period — but routine post-launch work cannot.

Forgetting Impairment Testing

Capitalized software is an asset, and assets must be impaired if their value drops. If you mothball a product, sunset a feature, or fundamentally rewrite the system, you must reassess and likely write off the prior balance.

How to Set Up a Defensible Process

If you decide capitalization is right for your company, the process matters as much as the policy.

1. Write a software capitalization policy. Define which projects qualify, your authorization process, your useful-life estimate, and how you'll allocate time. Get sign-off from your CFO or audit committee.

2. Track engineering time at the project level. This is the foundational input. Whether you use Jira labels, custom tags in a project tracker, or formal timesheets, you need to defend "engineer X spent Y% of their time on capitalizable work on project Z."

3. Document management approval. Each capitalizable project needs evidence of authorization — dated written approval, board minutes, or a project charter signed by leadership.

4. Reassess significant uncertainty regularly. Under the new rule, you need to monitor whether features are still novel or unproven and whether requirements are stabilizing. Quarterly reviews with engineering leadership are reasonable.

5. Build amortization schedules per project. Each capitalized project starts amortizing when ready for use, and you need to track that asset's cost basis, accumulated amortization, and remaining life.

6. Test for impairment when projects change. Anytime you abandon, materially rewrite, or sunset capitalized work, run an impairment analysis and book write-downs as needed.

Why This Matters for Bookkeeping

Software capitalization is one of those areas where day-one bookkeeping discipline pays off years later. Investors during a Series B raise will pull your trial balance; acquirers in a sale process will trace transactions back to journal entries; the IRS may compare your GAAP treatment to your Section 174 R&D tax treatment, which has its own rules. If your books don't separate capitalized projects from operating expenses, can't tie engineering time charges to specific projects, or don't maintain clean amortization schedules, every audit and diligence cycle becomes painful.

The fix is simple in concept: maintain clean account structure, track time at the project level, and document the decisions behind every capitalization entry. Doing this from the start avoids costly cleanups later.

Keep Your Software Accounting Audit-Ready

Whether you're capitalizing your first internal platform or running amortization schedules across dozens of projects, clean financial records are the foundation. Beancount.io provides plain-text accounting that gives you transparent, version-controlled books — every entry traceable, every account auditable, every report reproducible. For software companies tracking capitalized development across multiple projects, having books that read like code is a serious advantage. Get started for free and see why developers and finance professionals are switching to plain-text accounting.