Amendment, US GAAP

ASU 2025-06 targeted improvements to software cost accounting

Amendment

ASU 2025-06 amends ASC 350-40 to remove the project-stage bright lines and begin capitalising internal-use software costs once management has authorised the project and it is probable it will be completed and used as intended ASU 2025-06. The FASB introduced it because iterative development did not fit the old stage model.

What changed

The amendment removes the sequence of preliminary, application-development and post-implementation stages that previously determined when internal-use software costs could be capitalised, and replaces it with a single probable-to-complete threshold ASU 2025-06. Capitalisation begins when the project is authorised and completion is probable, not when a stage label is reached.

Why the FASB introduced it

The stage model assumed a broadly linear, waterfall development process. Modern software, and AI development in particular, is iterative and overlapping, so costs did not fall neatly into stages and practice diverged ASC 350-40. The threshold refocuses the test on the substance, whether the project will actually be completed and used, which is easier to apply consistently to iterative builds.

What it means for token spend

For a US GAAP reporter, development-phase token spend on an authorised, probable-to-complete project is capitalisable from the point the threshold is met. The phase marker in the token ledger evidences that the spend was incurred after that point. Spend before authorisation, or on projects not probable to complete, remains expensed. The measurement mechanics are unchanged; only the start point moves.

Effective date

The effective date and transition provisions are set out by the FASB in the update itself. A preparer should confirm the applicable effective date, and whether early adoption is permitted, for its own reporting entity against the standard rather than rely on a date stated here ASU 2025-06.