ASC 350-40 Internal-Use Software: A Complete Guide to Capitalization and Compliance
Companies that build or buy technology for their own operations need clear rules for how to record those costs, and that’s exactly what ASC 350-40 internal-use software guidance provides. (1) Understanding this standard matters whether you’re an early-stage startup building your first product, a finance team preparing for an audit, or a controller trying to decide whether a development cost belongs on the balance sheet or the income statement.
What the Standard Covers
ASC 350-40 internal-use software is part of the Accounting Standards Codification issued by the Financial Accounting Standards Board, and it specifically governs how companies account for software that is developed or obtained for their own internal use rather than software intended to be sold, leased, or marketed externally. That distinction is critical, because software built for internal operations follows very different accounting treatment than software a company plans to sell to customers, which instead falls under ASC 985-20.
The standard determines which software-related costs can be capitalized as an intangible asset on the balance sheet and which must be expensed immediately in the period they’re incurred. This distinction has a direct impact on a company’s reported net income, since capitalized costs are spread out over the useful life of the asset through amortization, while expensed costs reduce profit right away.
Why This Accounting Standard Matters
Getting ASC 350-40 internal-use software treatment right isn’t just a technical accounting exercise — it has real financial reporting consequences. Companies that misapply the guidance risk restating financials, drawing scrutiny during audits, or presenting a distorted picture of profitability to investors and lenders.
- Accurate capitalization smooths out the financial impact of large software investments over time.
- Clean, well-documented accounting is often a prerequisite before fundraising rounds or an IPO.
- Auditors specifically test software capitalization policies, since it’s an area where errors are common.
- Investors and lenders use capitalized asset balances to assess a company’s technology investments and balance sheet strength.
- Consistent application supports comparability between reporting periods and against industry peers.
The Traditional Three-Stage Framework
Historically, applying ASC 350-40 internal-use software guidance meant walking through three distinct stages of a software project, each with different accounting treatment. While recent updates have reshaped this framework, understanding the traditional stages still helps clarify how the standard evolved and how many companies continue to think about their projects.
| Stage | Description | Cost Treatment |
|---|---|---|
| Preliminary Project Stage | Conceptual planning, evaluating alternatives, and determining whether the required technology exists | Expensed as incurred |
| Application Development Stage | Coding, design, installation, and testing after management has authorized and committed to funding | Capitalized |
| Post-Implementation/Operation Stage | Software is functional and in use; training and maintenance activities occur | Expensed as incurred |
During the preliminary stage, companies are still researching and evaluating options, so costs are treated as period expenses rather than assets. Once management formally commits to funding a specific project and it becomes probable the software will be completed and used as intended, the company moves into the application development stage, where salaries, materials, and qualifying direct costs become eligible for capitalization. After the software goes live, costs shift back to being expensed, with the exception of upgrades and enhancements that add new functionality. what software do companies use for time tracking
What Costs Can Be Capitalized
Within the application development stage, not every dollar spent qualifies for capitalization under ASC 350-40 internal-use software rules. The standard is specific about which costs are eligible.
- Salaries and payroll-related costs for employees directly involved in coding, designing, and testing the software.
- Fees paid to external consultants or contractors for development work.
- Costs of software licenses and hosting arrangements tied to implementation.
- Costs to develop or acquire software that allows access to or conversion of data from old systems to new systems.
- Interest costs incurred while developing internal-use software, in certain circumstances.
Costs that generally must be expensed include data conversion activities unrelated to making the software operational, training costs for employees, general and administrative overhead, and costs incurred during the preliminary planning phase before a project is formally authorized.
Upgrades, Enhancements, and Maintenance
A recurring question companies face involves costs incurred after software is already up and running. Under ASC 350-40 internal-use software guidance, upgrades and enhancements are defined as modifications that result in additional functionality — meaning the software can now do something it previously could not do. These costs follow the same capitalization logic as the original development stage.
By contrast, routine maintenance and minor bug fixes that don’t add new functionality are considered ordinary operating costs and must be expensed as incurred. Companies that cannot reasonably separate maintenance costs from minor upgrades on a cost-effective basis are permitted to expense the combined costs entirely, avoiding the need for overly granular cost tracking.
Cloud Computing Arrangements and SaaS
One of the most significant clarifications tied to ASC 350-40 internal-use software accounting relates to cloud computing and hosting arrangements. Before updated guidance was issued, companies faced real ambiguity about whether implementation costs for cloud-based service contracts could be capitalized the same way as costs for on-premise software.
The clarification established that if a hosting arrangement includes a software license, the licensing costs are accounted for under general internal-use software rules. If the arrangement is a service contract without a distinct license — as is common with many SaaS platforms — companies must still evaluate whether implementation costs meet capitalization criteria, separate from the ongoing hosting fees themselves.
Two criteria typically determine whether a cloud arrangement should be treated as internal-use software rather than a service contract:
- The customer has the contractual right to take possession of the software at any time during the hosting period without incurring significant penalty.
- It is feasible for the customer to run the software on its own hardware or contract with an unrelated third party to host it.
If either condition fails, the arrangement is generally treated as a service contract, and implementation costs are evaluated under the same recognition principles applied to other internal-use software projects.
Recent Changes to the Standard
The FASB has continued refining ASC 350-40 internal-use software guidance to keep pace with how software is actually built today. Modern development rarely follows the neat, sequential stages the original standard was written around. Most technology teams now use agile methodologies, working in short sprints rather than linear phases, which made the traditional three-stage model increasingly difficult to apply consistently.
In response, the FASB issued an update that removes the prescriptive references to “project stages” altogether and replaces them with a principles-based recognition threshold. Under the revised approach, capitalization begins once two criteria are met:
- Management, with the relevant authority, has authorized and committed to funding a specific software project.
- It is probable that the project will be completed and the software will be used to perform its intended function — sometimes referred to as the “probable-to-complete” threshold.
This shift moves the standard closer to the framework already used for externally marketed software, improving consistency across different types of software investments while giving companies flexibility to apply the guidance regardless of whether they use waterfall, agile, or hybrid development approaches.
Website Development Costs
Another notable change folds guidance that previously lived in a separate section on website development directly into the broader internal-use software framework. Rather than maintaining two overlapping sets of rules, website development costs are now evaluated using the same recognition principles as any other internal-use software project, simplifying the accounting for companies that build and maintain their own digital platforms.
New Disclosure Requirements
Alongside the recognition changes, updated guidance introduces expanded disclosure requirements for capitalized software costs. Companies are now required to disclose:
| Disclosure Item | Purpose |
|---|---|
| Capitalized internal-use software balance | Shows the asset’s carrying value at the reporting date |
| Accumulated amortization | Reflects how much of the asset’s cost has been recognized as expense |
| Amortization expense for the period | Provides visibility into the current period’s impact on earnings |
| Description of amortization method | Explains how the asset’s cost is being allocated over its useful life |
These disclosures apply regardless of whether the capitalized costs appear on the balance sheet as intangible assets or within property, plant, and equipment, giving investors more consistent visibility into how much companies are investing in internally developed technology.
Practical Steps for Applying the Standard
Companies working to apply ASC 350-40 internal-use software guidance correctly should build a consistent internal process rather than making capitalization decisions on a case-by-case basis. A few practical steps help:
- Establish a clear point at which a project is considered formally authorized and funded, since this typically triggers the start of capitalization eligibility.
- Maintain time-tracking systems that allow employees to record hours spent specifically on qualifying development activities.
- Document the probable-to-complete assessment for each project, including any significant technical uncertainties that could delay or derail development.
- Separate maintenance activities from upgrades and enhancements wherever cost-effective to do so.
- Review cloud computing and SaaS contracts carefully to determine whether they represent a software license or a service arrangement.
- Coordinate with auditors early, particularly for large or unusual software investments, to confirm the capitalization approach aligns with current guidance.
Common Mistakes Companies Make
Even well-intentioned finance teams run into recurring issues when applying this standard:
- Capitalizing costs incurred before a project has been formally authorized and funded.
- Failing to reassess capitalized costs when a project’s completion becomes doubtful.
- Treating all cloud computing fees the same, without evaluating whether implementation costs are separately capitalizable.
- Continuing to capitalize costs during the post-implementation stage that no longer qualify.
- Overlooking the expanded disclosure requirements tied to capitalized software balances.
Frequently Asked Questions
What is the difference between ASC 350-40 and ASC 985-20?
ASC 350-40 applies to software developed or acquired for a company’s own internal use, while ASC 985-20 applies to software a company intends to sell, lease, or market externally to customers.
Can salaries be capitalized under this standard?
Yes. Salaries and payroll-related costs for employees directly involved in coding, designing, and testing qualifying software projects can be capitalized once the applicable recognition criteria are met.
How are cloud computing implementation costs treated?
Implementation costs may be capitalized if the arrangement meets specific criteria distinguishing it from a pure service contract, even when the underlying hosting fees themselves are expensed as incurred.
What happens to costs if a software project is abandoned?
If it’s no longer probable that a project will be completed, previously capitalized costs generally must be written off, since the recognition threshold supporting capitalization is no longer met.
Are upgrades to existing software capitalized the same way as new development?
Yes, provided the upgrade or enhancement adds new functionality. Costs that don’t add functionality, such as routine maintenance, are expensed as incurred.
When do the newest FASB changes take effect?
The most recent amendments apply to annual reporting periods beginning after December 15, 2027, with corresponding interim periods, giving companies time to adjust internal processes and documentation.