The probable-to-complete threshold
ASU 2025-06 replaces the ASC 350-40 stage trigger with a probable-to-complete recognition threshold. Capitalisation begins only when management has authorised and committed to funding the project and it is probable the project will be completed and the software used to perform its intended function S5. Both conditions must hold.
What it replaced
The prior model tied capitalisation to entering the application-development stage. ASU 2025-06 removes that stage reference and instead applies a single recognition threshold based on whether completion and use are probable, making it neutral to waterfall or agile development ASU 2025-06S5.
The two conditions
Capitalisation begins when, and only when, both of these are true: management with the relevant authority has authorised and committed to funding the project; and it is probable the project will be completed and the software used to perform its intended function S5. Funding without probable completion, or a probable outcome without committed funding, does not start capitalisation.
How it interacts with the uncertainty condition
Even where funding is committed, the significant-development-uncertainty condition can hold completion below probable, deferring capitalisation. For AI this is the common case: a committed budget does not make a novel model probable to complete until the technical uncertainty is resolvedASC 350-40350-40-25.
- S5ASU 2025-06 on internal-use software costs, BDO (US GAAP). https://arch.bdo.com/new-asu-on-internal-use-software-costs-guidance
- S4FASB Accounting Standards Codification, PwC Viewpoint (US GAAP). https://viewpoint.pwc.com/dt/us/en/fasb/GAAP/Codification/Codification/228073.html