ASU 2025-06 Readiness: Build an Auditable Software Capitalization Gate

Agile development has never fit neatly into a waterfall accounting checklist. Product requirements change by sprint, cloud features are released continuously, and technical risk may disappear months after management approves a budget. ASU 2025-06 modernizes the internal-use software model for that reality, but it replaces familiar project-stage labels with a more judgment-heavy capitalization gate.

The amendments apply to all entities using ASC 350-40, including many companies developing software delivered through a cloud computing arrangement, and they fold website-development guidance into the same Subtopic. For calendar-year entities, mandatory adoption begins in 2028.

Why the Software Cost Model Changes

Current ASC 350-40 organizes cost recognition around preliminary, application-development, and postimplementation stages. FASB concluded that those sequential labels can be difficult to apply when development is iterative. ASU 2025-06 removes references to project stages and establishes one recognition model that is neutral to waterfall, agile, and future development methods.

The scope remains important. ASC 350-40 generally addresses software acquired, developed, or modified for internal use. It also can apply to software a company provides to customers through a cloud computing arrangement when the customer cannot take possession of the software. The amendments do not change ASC 985-20 for software to be sold, leased, or otherwise marketed as external-use software. Documenting that boundary is the first control, especially for SaaS companies with multiple delivery models.

Replace Project Stages With a Two-Part Gate

Capitalization starts when both recognition conditions are met:

1. Funding authorization. Management with the relevant authority has implicitly or explicitly authorized and committed to fund the project. Evidence can include an executed development contract, approved internal-development spending, or a commitment to obtain software from a third party.
2. Probable completion and intended use. It is probable that the project will be completed and the software will perform the function intended.

Meeting the gate does not make every cost capitalizable. Eligible costs continue to include direct third-party development costs, payroll and payroll-related costs for employees directly associated with the project to the extent of their project time, qualifying interest, and certain software that enables access to or conversion of old data. Training, most data conversion activities, general and administrative costs, and overhead remain expenses.

Capitalization stops no later than substantial completion and readiness for intended use after substantial testing. If the completion assertion later fails, new capitalization stops and the existing balance enters the impairment analysis.

Significant Development Uncertainty Is the Stop Sign

The probable-to-complete condition is not met while significant development uncertainty exists. ASU 2025-06 identifies two factors, and either one is enough to delay capitalization:

• The software includes technological innovations or novel, unique, or unproven functions or features, and the related uncertainty has not been resolved through coding and testing.
• Significant performance requirements have not been identified or continue to be substantially revised.

This is not a general technological-feasibility test imported from ASC 985-20. It is an ASC 350-40 assessment applied to every project. A standard ERP configuration may clear the assessment quickly; a new AI-enabled underwriting engine may remain blocked until core functions stabilize and technical uncertainty is resolved with evidence.

Turn Agile Evidence Into an Accounting Control

A ticketing system alone is not an accounting position. Build a controlled monthly or sprint-close package that connects product and engineering facts to the general ledger:

1. Define the project. State whether the unit of account is a platform, module, product capability, or other supportable project boundary. ASU 2025-06 does not define the unit of account for you.
2. Capture authorization. Retain the budget owner, approval date, approved amount, vendor contract, and evidence of commitment.
3. Assess requirements. Identify significant performance requirements and flag substantial revisions, not ordinary backlog grooming.
4. Resolve technical uncertainty. Link novel features to testing results, architecture decisions, security validation, or production-readiness evidence.
5. Tag costs. Separate direct coding, configuration, interface, installation, and testing time from training, maintenance, data cleansing, G&A, and overhead.
6. Approve start and stop dates. Finance and the accountable technology leader should sign the capitalization memo and retain the evidence used.

The control should be repeatable and supported by contemporaneous approvals and system-generated time and cost reports.

Map Cloud, Website, Upgrade, and AI Costs Carefully

The Update supersedes ASC 350-50 and brings website-specific recognition requirements into ASC 350-40. Website content input remains expensed; initial graphics are evaluated under the applicable software guidance; hosting fees generally are expensed over the benefit period; and search-engine registration is advertising expense. A website project therefore still needs cost-level classification after it clears the recognition gate.

Upgrades and enhancements qualify for capitalization analysis only when additional functionality is probable. Maintenance is expensed, and an entity that cannot reasonably separate internal maintenance from relatively minor upgrades expenses the combined internal cost. Vendor contracts that bundle hosting, maintenance, implementation, training, and future enhancements need an allocation based on relative standalone prices.

FASB also made clear in its basis for conclusions that ASU 2025-06 does not specifically resolve accounting for AI model-training costs. Companies should not create an automatic “AI capitalization” policy. Identify the activity, determine which guidance applies, document the judgment, and align the policy with the external auditor before material costs accumulate.

Choose a Transition Method Before 2028

The amendments are effective for all entities for annual periods beginning after December 15, 2027, including interim periods within those annual periods. A calendar-year company therefore applies the standard in 2028. Early adoption is permitted in an interim or annual period before the financial statements are issued or available to be issued, but interim adoption is applied from the beginning of that annual period.

Management can choose among three transition approaches:

• Prospective: apply the new guidance to new costs incurred for all projects, including in-process projects, beginning in the adoption period.
• Modified: apply prospectively, but derecognize through opening equity the capitalized balance of an in-process project that fails the new capitalization requirements even though it met the former model.
• Retrospective: recast comparative periods and record the cumulative effect in opening equity for the first period presented.

Build a project inventory and run a dry assessment before choosing. The decision should consider data availability, comparative financial statements, debt covenants, non-GAAP metrics, acquisition models, audit effort, and the volume of in-process projects.

Common Mistakes

• Renaming old project stages. The new model requires evidence for funding and probable completion, not a relabeled application-development stage.
• Treating budget approval as sufficient. Significant development uncertainty can block capitalization after funding is committed.
• Using epics or sprints as the unit of account by default. The project boundary remains a facts-and-circumstances judgment.
• Capitalizing the whole engineering payroll. Only directly associated time is eligible; maintain project-level time and activity evidence.
• Capitalizing training, routine maintenance, G&A, or overhead. The recognition gate does not override cost-eligibility rules.
• Applying ASC 350-40 to external-use software without a scope memo. ASC 985-20 remains in place.
• Assuming the Update settles AI training costs. It does not provide AI-specific recognition guidance.
• Forgetting disclosures. ASC 360-10 property, plant, and equipment disclosures apply to capitalized internal-use software regardless of balance-sheet presentation.
• Letting book treatment drive tax treatment. ASC 350-40 capitalization does not determine federal or state tax treatment; maintain a separate tax basis and temporary-difference analysis.

The Bottom Line

ASU 2025-06 makes internal-use software accounting more compatible with modern development, but it also moves more judgment into the close. Start with a complete project inventory, draw the ASC 350-40 versus ASC 985-20 scope boundary, define the unit of account, and require contemporaneous evidence for funding authorization, stable requirements, resolved technical uncertainty, eligible costs, and readiness for use. Then test transition choices with the audit team before 2028 comparative and covenant consequences become expensive to unwind.