The Financial Accounting Standards Board (FASB) has released ASU 2025-06, “Intangibles—Goodwill and Other— Internal-Use Software (Subtopic 350-40)”, a standard that redefines how organizations assess, recognize, and disclose internal-use software costs. The update reflects how technology is now developed and embedded in everyday operations, moving toward a model that relies more on professional judgment and documented intent than on procedural stages.

For auditors and finance leaders, the update is a timely reminder that governance and accounting must evolve alongside innovation. It challenges preparers to align policy, documentation, and control frameworks with the way software is actually built and deployed within their organizations.

Scope and Applicability

The guidance applies to all entities following U.S. GAAP that create or acquire software for their own use. It encompasses public and private companies, not-for-profits, and other organizations that develop systems supporting internal processes rather than selling or licensing them externally.

The update also eliminates the separate website-development standard (ASC 350-50) and folds those provisions into ASC 350-40, creating one unified framework for all internal-use software. Companies should revisit their accounting policies for web and digital platforms to ensure they now follow the same capitalization principles.

ASU 2025-06 becomes effective for annual periods beginning after December 15, 2027, including interim periods within those years. Early adoption is permitted, and entities may transition prospectively, retrospectively, or under a modified prospective approach.

Although the ASU is a U.S. GAAP standard, its effects may extend to multinational groups that prepare dual reporting financial statements. These entities will need to ensure their capitalization policies under IFRS or local GAAP remain aligned in concept and documentation.

It is equally important to note what the ASU does not change. The accounting for external-use software under ASC 985-20 remains intact. Similarly, costs related to training, data conversion, or ongoing maintenance continue to be expensed when incurred.

The Recognition Principle

Under the new guidance, capitalization begins only when both of the following conditions exist:

1. Management authorization and funding commitment — a formal decision that the project will move forward and resources will be provided; and
2. Probable-to-complete threshold — evidence that completion is reasonably assured and the software will serve its intended function.

These criteria emphasize verifiable intent and technical feasibility. Software costs recorded as assets must represent projects that are both approved and capable of completion, not merely planned or exploratory.

Assessing Development Uncertainty

The ASU introduces the concept of significant development uncertainty, requiring entities to expense costs until that uncertainty is resolved. Such uncertainty arises when major technical challenges remain, performance parameters are still evolving, or the success of an untested function cannot yet be demonstrated.

Indicators that uncertainty has been resolved include successful prototype testing, formal acceptance of performance results, or documentation showing that critical design elements are finalized. Auditors will expect management to maintain clear evidence supporting when these milestones are reached.

Illustrative Example

A company begins developing an internal data-management platform to integrate its global reporting systems.

Under previous guidance, the organization may have started capitalizing costs once the project entered its formal development stage. Coding, testing, and configuration typically qualified because they occurred within that defined phase.

Under ASU 2025-06, the accounting trigger depends on authorization and feasibility rather than project sequence. Capitalization begins only when management has formally approved the investment, committed funding, and confirmed that the platform is probable of completion.

If performance benchmarks—say, real-time data processing—are still unproven, related costs remain expensed until testing demonstrates that the criteria can be achieved. Once those conditions are satisfied, later development costs can be capitalized.

This model anchors recognition in the substance of readiness and capability rather than in procedural timing.

Consolidated Treatment of Website Development

The standard consolidates website development within the broader internal-use software model. All internally hosted platforms and customer-facing systems are now assessed under the same principles, ensuring uniform treatment across technology initiatives and simplifying compliance.

Disclosure and Oversight

The disclosure requirements now mirror ASC 360-10 (Property, Plant, and Equipment). Entities must present roll-forwards of capitalized software costs, disclose additions and amortization, and describe major ongoing projects.

These disclosures reinforce transparency around digital investment and enhance accountability in governance. For auditors, they also create a clearer audit trail linking authorization, testing, and capitalization decisions. Well-maintained approvals, funding documentation, and impairment assessments will be essential to support these disclosures.

Transition and Implementation

Organizations can adopt the guidance through one of three approaches:

• Prospective: apply the new standard only to costs incurred after adoption;
• Modified prospective: apply the guidance to new costs and adjust for in-process projects that no longer qualify; or
• Retrospective: restate prior periods under the new rules.

Each method affects comparability and system readiness differently. Entities planning early adoption should coordinate with auditors to align transition entries, control updates, and disclosure requirements from the first reporting period.

Implications for Auditors

The new guidance deepens the professional judgment required in several areas:

• Authorization evidence: confirming that project approvals and funding are documented and traceable to governance records.
• Probable-to-complete evaluation: assessing whether feasibility assessments, testing, and resource plans justify capitalization.
• Internal-control design: ensuring that capitalization triggers and impairment reviews are integrated into IT and finance processes.
• Global consistency: verifying that subsidiaries apply the same recognition thresholds and maintain comparable documentation.

Audit teams will likely need stronger collaboration with IT specialists to validate technical milestones that underpin accounting judgments.

Preparing for Implementation

To prepare, entities should review existing capitalization policies, project-tracking mechanisms, and ERP configurations. Documentation must clearly show the point at which management authorization, funding, and technical feasibility converge. Processes for tracking costs related to training, maintenance, or data migration should also be updated to prevent misclassification.

Early preparation will allow companies to make controlled adjustments and demonstrate compliance ahead of the 2027 effective date.

KNAV Comments

ASU 2025-06 encourages a disciplined and evidence-based approach to recognizing technology investments. By linking capitalization to commitment and feasibility, the standard seeks to ensure that the software asset reported on the balance sheet genuinely represents a source of future economic benefit.

For assurance leaders, this change strengthens the connection between accounting and operational execution. It reminds organizations that sound judgment, clear governance, and consistent oversight are as important as the technology itself in building investor trust.