Capitalizing Software Costs

Capitalizing Software Costs: Internal-Use vs. External Use (ASC 350 & 985)
Differentiating costs for SaaS development, app launches, and cloud integrations

Why the Line Between Expense and Asset Is Where Strategy Begins

Every CFO knows the moment well. A product roadmap lands on your desk, and tucked inside are seven figures in engineering spend earmarked for what sounds like “product enablement” — a phrase broad enough to be either a euphemism for burning cash or a strategic moat in the making. The challenge is not just classifying whether a cost is an expense or a capitalizable asset. It is in recognizing that how we apply ASC 350 and ASC 985 becomes a quiet but powerful lever for earnings quality, investor confidence, and long-term value creation.

This blog will examine the two key accounting standards that govern the capitalization of software development costs: ASC 350 for internal-use software and ASC 985 for software to be sold or licensed. We will go beyond compliance to explore the real implications of these choices — in tax treatment, metrics distortions, and the temptation to window-dress. Whether your company is building a SaaS platform, launching a consumer app, or architecting enterprise cloud integrations, understanding these standards is vital for steering the business with clarity.

Capitalization as a Strategic Act, Not a Tactical Move

Let us begin with a simple but overlooked principle: capitalization is not just a technical election. It is a reflection of confidence in the future. You only capitalize what you expect to deliver recurring value — an asset whose utility extends beyond the current year. Yet this line of demarcation often runs through murky waters in the startup and scale-up world. Product managers refer to “launch sprints” and “infrastructure refactors,” but the finance team must translate those terms into accounting substance.

To do this, we lean on ASC 350-40 for internal-use software and ASC 985-20 for external-facing software. The decision point between the two is not what the software does, but who it is for. Internal-use means systems that support internal processes — think ERP implementations, data warehouses, cloud integrations, or internal analytics tools. ASC 985 applies to software intended for sale, lease, or marketing — think mobile apps, SaaS platforms, or features customers pay to access.

Three Stages: The Key to Capitalization Timing

Both ASC 350 and ASC 985 define three critical development stages:

1. Preliminary Project Stage – where conceptual design and evaluations occur.
2. Application Development Stage – where coding, testing, and configuration happens.
3. Post-Implementation Stage – where training, maintenance, and bug fixes take place.

Capitalization is permitted only during the Application Development Stage. Expenses in the preliminary and post-implementation stages are expensed as incurred. In practice, this requires not just engineering milestones but a project governance structure that documents timelines, resource allocations, and decisions — the absence of which often leaves smaller companies vulnerable during audits or due diligence.

Internal-Use Software: Under ASC 350

ASC 350-40 allows for capitalization of certain costs incurred in developing or acquiring internal-use software. Examples include:

• Configuration of ERP systems like NetSuite or SAP
• Custom integrations between internal data systems
• Backend infrastructure development for business intelligence

A few rules of thumb:

• Costs like planning, evaluating vendors, or feasibility studies are expensed.
• Costs for coding, testing, and installing during active development are capitalized.
• Costs for training, data conversion, and support are expensed.

Crucially, hosting arrangements — such as cloud-based software — introduce a wrinkle. Under ASU 2018-15, companies must determine whether a cloud computing arrangement includes a software license. If so, the license portion may be capitalized, but the hosting services themselves are typically expensed.

External-Use Software: Under ASC 985

ASC 985-20 governs software to be sold, leased, or otherwise marketed. Here, the bar is higher: capitalization begins only after technological feasibility is established, and ends when the product is released. This creates a narrow window where costs qualify for capitalization. For many agile organizations using continuous delivery, this window may be so small as to be negligible.

In my experience, firms often overstate this window in an attempt to capitalize broader development spend. Audit scrutiny has only grown tighter post-IPO, where the SEC has taken an interest in “earnings management through selective capitalization.”

That said, companies that develop defined release-based products — like annual app launches or versioned platforms — can still carve out this window credibly, provided documentation is thorough and consistent.

The Rise of SaaS: Blurring the Line

The explosion of SaaS and cloud-native development has fundamentally complicated the application of these standards. For instance, if you are building a SaaS platform that your internal teams also use, which guidance governs?

The FASB clarifies that ASC 985 applies only when there is substantive customer-facing functionality. If the primary function is internal — even if hosted externally — ASC 350 applies.

This is not a trivial distinction. ASC 350 allows for broader capitalization earlier in the lifecycle. Misclassification can lead to earnings misstatements and even restatements if left uncorrected.

Capitalization Policy: Your First Line of Defense

A well-articulated software capitalization policy is not just a best practice. It is your shield during financial due diligence, particularly in Series C or D rounds where investors demand visibility into product burn vs. capitalized value. The policy should address:

• Criteria for project stage identification
• Timing of capitalization start and end
• Treatment of upgrades and enhancements
• Allocation methods for shared engineering resources

Many companies fail to allocate engineer hours with sufficient precision, leading to either undercapitalization (missing out on justified asset creation) or overcapitalization (inflating the balance sheet). The difference can swing EBITDA, cash burn metrics, and even revenue multiples used by VCs.

Tax Implications: Deferred Gratification or Strategic Play?

Capitalizing software costs often leads to short-term pain for long-term gain. Capitalized assets typically must be amortized over three years for tax purposes under Section 174, and with the Tax Cuts and Jobs Act amendments now requiring amortization even for R&D costs, many startups face a growing book-tax difference.

However, capitalized development costs can lower current-period expenses, improving GAAP EBITDA. For companies raising capital or targeting an IPO, the optics can be favorable — provided the capitalization is defensible.

Common Pitfalls: When Accounting Meets Optimism

Several red flags should prompt closer review:

• “Soft launches” used to justify continued capitalization: Once the product is market-ready, the capitalization period should cease, even if further development continues.
• No segregation of tasks or costs by stage: Without time tracking, cost segmentation, and project documentation, the audit trail collapses quickly.
• Retrofitting expenses into capex to manage earnings: Auditors are increasingly wary of quarter-end adjustments where large portions of engineering spend are suddenly reclassified.

These practices not only erode trust with investors but also distort internal dashboards that inform product ROI and payback periods.

Operationalizing the Standard: Finance and Product Need a Common Language

To truly operationalize software capitalization, finance and engineering must speak in aligned frameworks. This means embedding finance liaisons into product meetings, using tools like Jira to map development stages, and training engineering leads on the financial impact of documentation.

In one Series B company I advised, merely improving the tagging of Jira epics by development stage led to a 22 percent improvement in capitalized cost accuracy. That translated into better gross margin projections and a more credible R&D runway narrative to investors.

Conclusion: A Lens Into Your Strategic Maturity

Ultimately, how you handle software capitalization reveals far more than your accounting acumen. It reflects whether the company is building infrastructure or chasing product-market fit. It signals whether management has the discipline to document, the courage to expense where appropriate, and the strategic clarity to know what investments deserve to be called assets.

This is not merely a compliance exercise. It is an opportunity to refine your understanding of capital formation in a digital economy — where the most valuable assets do not show up on the balance sheet unless we make them.

Call to Action

Finance leaders should revisit their software capitalization policies, establish clear collaboration protocols with engineering, and evaluate whether current practices align with the business model’s long-term capital formation strategy. Do not treat this as a quarterly close checklist item. Treat it as a lens into your strategic maturity.

Disclaimer
This blog is for informational purposes only and should not be construed as accounting or legal advice. Please consult your CPA or audit partner when applying ASC 350 or ASC 985 to your specific organizational context.