ASC 350-40: Cloud Computing Costs, Section 174A, and ASU 2025-06

ASC 350-40 governs how a company accounts for the costs of a cloud computing arrangement, and the framework turns on one question: is the contract a software license or a service? If it is a service contract, qualifying implementation costs are capitalized as a prepaid asset and amortized over the hosting term, matching the treatment that has long applied to internal-use software developed on-premise. ASU 2018-15 put those two paths on the same footing so the accounting no longer depends on how the software is delivered.¹

License or Service: The Threshold Question

A cloud arrangement contains a software license only if the customer has the contractual right to take possession of the software at any time during the hosting period without significant penalty. Taking possession means the customer could run the software on its own servers or hire an unrelated third party to host it. If both conditions are met, the software element is accounted for as an intangible asset separate from the hosting fees.¹

“Without significant penalty” is broader than a termination fee. It includes any meaningful cost of standing the software up independently, such as buying infrastructure or losing access to updates integral to the software’s functionality. It also captures a significant drop in processing power, features, or computing capability once the software is separated from the vendor’s platform. If pulling the software off the vendor’s servers would leave the customer with a diminished product or require substantial investment to replicate the hosting environment, that is a significant penalty, and the arrangement is a service contract.

Most modern SaaS agreements are service contracts. The vendor keeps control of the code, access happens through a browser or API, and the customer has no right to take possession. Getting this classification wrong creates real problems: capitalizing costs as an intangible when the arrangement is actually a service, or vice versa, can require a restatement.

Which Implementation Costs Are Capitalized

Once the arrangement is confirmed as a service contract, ASC 350-40 sorts implementation costs into three project stages. The stage decides whether a cost is capitalized or expensed as incurred.

Preliminary Project Stage

This is the “should we do this?” phase: evaluating vendors, defining requirements, comparing platforms, and allocating resources. Everything spent here is expensed as incurred, including consultant fees for vendor selection, internal labor for business-case analysis, and travel for on-site demos. No capitalization is permitted in this stage regardless of how likely the project looks.

Application Development Stage

Capitalization begins once management with the relevant authority authorizes and commits funding to the project and it is probable the project will be completed and the software will perform its intended function.¹ Costs tied to configuration, coding, integration with other systems, and testing are capitalized. Internal labor qualifies only for employees directly building or configuring the software. Administrative overhead stays on the income statement even when incurred during this stage.

Data conversion splits into two buckets. Software built or purchased to convert legacy data into a format the new system can read is capitalizable. The manual work of moving, cleaning, and validating data is expensed. When conversion is outsourced, only the portion involving creation of conversion software is capitalized; the rest is expensed.

Post-Implementation Stage

When testing is complete and the software is ready for use, capitalization stops. From that point, end-user training, routine maintenance, ongoing technical support, and subscription renewals are operating expenses. Continued configuration work after go-live is also expensed unless it meets the criteria for an upgrade that adds new functionality.

Contracts With Multiple Elements

Cloud contracts rarely include only a subscription fee. A typical deal bundles implementation services, training, data migration, maintenance, and sometimes rights to future upgrades. ASC 350-40 requires allocation of the total cost among the individual elements based on objective evidence of fair value, not the line-item prices the vendor chose to print in the contract. Each element then follows its own accounting: implementation costs run through the capitalization analysis, training is expensed, maintenance is expensed. A wrong allocation at this step distorts every step that follows.

Amortization Period and Start Date

Capitalized implementation costs are amortized over the term of the hosting arrangement. That term includes the non-cancellable contract period, any renewal periods the customer is reasonably certain to exercise, any periods where the customer is reasonably certain not to exercise a termination option, and any extension periods controlled by the vendor.¹ A three-year base contract with a two-year renewal option often amortizes over five years when the software is deeply embedded and switching costs make non-renewal unlikely.

Factors informing the “reasonably certain” judgment include technology obsolescence, competitive dynamics, the economic significance of the implementation costs themselves, and how rapidly the cloud hosting market is evolving. When significant implementation costs would still carry substantial value at the renewal decision point, that weighs toward including the renewal period in the amortization term.

Amortization can begin before the entire project goes live. If an implementation has independent modules, each module starts amortizing when it is ready for its intended use. A module that depends on other unfinished components waits until those dependencies are also complete. That rule prevents front-loading amortization on a partially functional system while avoiding delay for genuinely independent pieces already in production.

Impairment and Abandonment

Capitalized implementation costs are tested for impairment as long-lived assets whenever indicators suggest the carrying amount may not be recoverable.¹ The two most common triggers are the hosting arrangement no longer providing substantive service potential and a significant change in how the software is used or expected to be used.

If the software is abandoned, the remaining unamortized balance is written off as a loss in the current period. The unit of account for impairment testing is the asset group level, meaning the lowest level for which cash flows are identifiable and largely independent. Ghost assets left on the balance sheet after a platform migration or business-model shift are the kind of misstatement that draws auditor attention.

Upgrades and Enhancements

Post-implementation modifications that add genuinely new functionality can restart the capitalization analysis. Under ASC 350-40-25-17A, an upgrade or enhancement is a modification that enables the software to perform tasks it was previously incapable of performing.² Routine updates, patches, and maintenance do not qualify.

Two conditions must be satisfied to capitalize upgrade costs. It must be probable that the upgrade will result in additional functionality, and the upgrade must be evaluated as a new software project subject to the same capitalization thresholds: management authorization, funding commitment, and a probable-to-complete conclusion. If the upgrade involves technological innovations or unproven features and significant development uncertainty remains unresolved through coding and testing, capitalization cannot begin until that uncertainty is cleared.

Presentation and Disclosure

ASU 2018-15 prescribes line-item alignment across all three primary financial statements. On the balance sheet, capitalized implementation costs sit in the same line as any prepayment for the hosting arrangement, typically classified as a prepaid expense or other current/noncurrent asset depending on timing. They are not classified as intangible assets.¹

On the income statement, amortization of capitalized implementation costs appears in the same line as the hosting service fees. If subscription expense is reported under general and administrative expenses, the amortization goes there too. The cash flow statement follows the same logic: payments for capitalized implementation costs are classified in operating activities, matching the treatment of the subscription fees themselves.¹

Disclosure requirements include a description of the cloud arrangements, the remaining unamortized balance, total amortization expense recognized during the period, and the judgments applied in determining the contract term and the likelihood of exercising renewal options.

Book-Tax Differences Under Section 174A

GAAP and the tax code do not treat cloud implementation costs the same way. For tax years beginning after December 31, 2024, Section 174A of the Internal Revenue Code allows an immediate deduction for domestic research and experimental expenditures, including software development costs.³ Custom code and integrations built during a cloud implementation may be fully deductible in the year incurred for tax purposes even though they are capitalized and amortized over the hosting term for GAAP.

Taxpayers may also elect to capitalize and amortize domestic R&E expenditures over a period of not less than 60 months, beginning with the month the taxpayer first realizes benefits from the expenditures.³ Foreign research activities remain subject to mandatory capitalization and amortization under Section 174 and do not get the immediate deduction.

Not every implementation cost qualifies as R&E. Installing vendor-provided templates, configuring pre-built modules, and modifying off-the-shelf software to fit the business are generally treated as part of the purchased software cost and amortized over 36 months for tax purposes. The line between “developing software” and “implementing purchased software” drives the tax outcome and does not line up neatly with the GAAP project-stage analysis, so cloud implementations of any real size produce temporary differences that require deferred tax accounting.

What Changes Under ASU 2025-06

The FASB issued ASU 2025-06 in 2025, which reshapes software cost accounting for fiscal years beginning after December 15, 2027, with early adoption permitted.⁴ The three-stage project framework is replaced with a principles-based capitalization threshold built on management authorization, funding commitment, and probability of completion. Entities will evaluate capitalization eligibility against a single set of recognition criteria rather than mapping costs into preliminary, development, and post-implementation buckets.

ASU 2025-06 also introduces “significant development uncertainty” as a gating factor. If the software involves technological innovations or unproven features and those uncertainties have not been resolved through coding and testing, capitalization cannot begin. If significant performance requirements have not been identified or are still being substantially revised, the probable-to-complete threshold is not met.² For calendar-year companies, the current three-stage model remains in effect through 2027 reporting, leaving time to assess how capitalization processes and internal controls will need to adapt.