Executive Summary
A seven-figure line item labeled product enablement can mean almost anything. That decision, income statement or balance sheet, is where a software capitalization strategy earns its keep. ASC 350 governs internal-use software. ASC 985 governs software built to sell or license. Choosing between them is not a footnote exercise. ASC 350 covers internal-use software. ASC 985 covers software built to sell or license. Choosing between them is not a footnote exercise. It shapes earnings quality. It shapes the credibility of the growth story told to a board. And it shapes the confidence investors place in the numbers underneath a raise.
This article walks through four things. The three development stages that govern timing. The practical differences between internal-use and external-use treatment. The complications SaaS and cloud delivery introduce. And the policy discipline that keeps a capitalization position defensible when diligence teams start asking questions.
Why Software Capitalization Decisions Signal Strategic Maturity
Capitalizing a cost is a statement about the future. A company only capitalizes what it expects to deliver value beyond the current period, and product teams rarely speak in those terms. They talk about launch sprints and infrastructure refactors, leaving finance to translate engineering language into accounting substance.
ASC 350-40 governs internal-use software, and ASC 985-20 governs software built for sale, lease, or license. The dividing line is not what the software does but who it serves. Systems that support internal operations, such as ERP platforms, data warehouses, and cloud integrations, fall under ASC 350. Products that customers pay to access, including SaaS platforms and mobile applications, fall under ASC 985.
The Three Development Stages That Govern Capitalization Timing
Both standards define the same three stages, and capitalization is permitted only during the middle one.
Getting the timing right depends on governance as much as accounting judgment. At a high-growth cybersecurity and identity access management company generating roughly $30M in annual recurring revenue, an end-to-end NetSuite rollout across 5 country entities only produced a defensible capitalization trail once the project carried real documentation behind it, including timelines, resource allocation, and stage-gated milestones. Without that structure, the audit trail collapses the moment anyone asks for it.
What Qualifies Under ASC 350
For internal-use software, a few rules of thumb hold up across most environments.
- Planning, vendor evaluation, and feasibility studies are expensed
- Coding, configuration, and testing during active development are capitalized
- Training, data conversion, and ongoing support are expensed
Cloud Hosting and ASU 2018-15
Hosting arrangements complicate the picture further, since under ASU 2018-15 a company must determine whether a cloud computing arrangement includes a software license. When it does, the license portion may be capitalized, though the hosting service itself is typically expensed as it is consumed.
External-Use Software Rules Under ASC 985
ASC 985-20 sets a considerably higher bar, since capitalization begins only once technological feasibility is established and ends when the product ships, leaving a narrow window for organizations running continuous delivery.
Audit scrutiny has tightened around this window as companies approach a public listing. Leading a Euronext Paris-listed gaming and digital entertainment company through an S-1 and IPO-readiness process, working alongside underwriters and a Big Four audit firm, made plain how closely regulators examine selective capitalization once a company sits under public-market disclosure requirements. Companies with defined release cycles, such as annual app launches or versioned platforms, can still carve out a credible capitalization window, provided the documentation is thorough and consistent across releases.
How SaaS Blurs the Line Between ASC 350 and ASC 985
The growth of SaaS and cloud-native development complicates a distinction that used to be straightforward. A platform built for internal teams that later becomes customer-facing forces a real accounting decision, not a cosmetic one.
FASB guidance resolves this by asking whether the software carries substantive customer-facing functionality. If the primary function remains internal, even when hosted externally, ASC 350 applies. Misclassifying that distinction can lead to earnings misstatements that eventually require restatement.
The stakes compound for organizations with multiple legal entities. A consolidated set of financial statements prepared under ASC 810 requires a single, consistent capitalization policy applied across every subsidiary rolled into the parent, not five different interpretations of the same standard. Building a consolidated US and Polish reporting framework for a marketplace SaaS company during its Series B raise made that requirement concrete, since a cohort and unit economics model only holds up in diligence when the underlying capitalization treatment is uniform across every entity feeding into it. The same discipline applied at scale during a global Oracle Financials rollout across 5 countries, where a single definition of revenue and a single capitalization standard had to survive both IFRS and US GAAP reporting simultaneously.
Building a Software Capitalization Policy That Holds Up in Diligence
A written software capitalization policy functions as a shield during financial due diligence, especially ahead of Series C or D rounds where investors want visibility into product burn against capitalized value, and it should address the following points.
- Criteria for identifying which development stage a project has reached
- Timing rules for when capitalization starts and stops
- Treatment of upgrades and enhancements to existing systems
- Allocation methods for engineering resources shared across projects
Serving as Chief Financial Officer of a mission-driven education and research institution while staffing the finance and audit committee made clear how much weight a board places on precision here. Undercapitalization means missing legitimate asset creation, and overcapitalization inflates the balance sheet in ways that eventually distort EBITDA, cash burn metrics, and the revenue multiples investors apply.
Tax Treatment and the Book-Tax Gap
Capitalizing software costs often trades short-term expense relief for a longer amortization horizon. Under Section 174, capitalized development costs generally amortize over 3 years for tax purposes, and the Tax Cuts and Jobs Act amendments now require amortization of R&D costs as well, widening the book-tax gap many startups now carry on their balance sheets.
The GAAP-side benefit is real enough to matter, since capitalized costs lower current-period expense and improve reported EBITDA, which can help the optics of a raise or an IPO process, provided the underlying capitalization position is defensible under audit.
Common Pitfalls That Undermine Software Capitalization Credibility
A handful of patterns should prompt closer review whenever they appear in a capitalization file.
- Soft launches used to justify continued capitalization after the product is genuinely market-ready
- No segregation of costs by development stage, which removes the audit trail entirely
- Quarter-end reclassification of engineering spends into capex to manage reported earnings
These practices erode trust with investors and distort the internal dashboards that product and finance teams rely on to judge return on investment and payback periods.
Operationalizing Software Capitalization Across Finance and Product
A software capitalization strategy only works when finance and engineering share a common vocabulary for describing the work itself. Embedding finance liaisons into product meetings, tagging development work by stage inside tools like Jira, and training engineering leads on the financial consequences of their documentation choices all move the needle.
At a venture-backed performance marketing and digital services company that scaled revenue from $9M to $180M in 24 months, improving how Jira epics were tagged by development stage lifted capitalized cost accuracy by roughly 22 percent, which translated directly into more credible gross margin projections and a stronger R&D runway narrative for investors. Similar discipline inside an AI governance and assurance platform, where finance workflows were rebuilt around AI-first tooling from the earliest pre-Series A stage, showed how much faster this alignment can happen when the finance function is designed for it from day one rather than retrofitted later.
Three Key Takeaways
- Capitalization decisions under ASC 350 and ASC 985 depend on who the software serves and which development stage the spend occurred in, and getting that classification wrong tends to surface only when diligence or audit scrutiny finally arrives.
- SaaS and cloud delivery have made the line between internal-use and external-use software genuinely difficult to draw, and organizations with multiple entities need a single capitalization standard applied consistently under ASC 810 rather than a patchwork of local interpretations.
- A written capitalization policy, paired with stage-level documentation and a shared vocabulary between finance and engineering, is what turns a defensible accounting position into one that survives an actual audit or investor diligence process.
Disclaimer: This article is intended for informational purposes only and does not constitute legal, tax, or accounting advice. You should consult your own tax advisor or counsel for advice tailored to your specific situation.
Hindol Datta is a four-time CFO and senior finance executive with over 25 years of leadership experience across cybersecurity, SaaS, gaming, logistics, digital marketing, medical devices, consumer products, and nonprofit organizations. He has led more than $120M in fundraising and over $150M in M&A transactions while building the financial and operational systems that let complex businesses scale with confidence. He is the author of seven books in the Systems CFO Series and holds active CPA, CMA, and CIA credentials.
AI-assisted insights, supplemented by 25 years of finance leadership experience.
