ASU 2025-06 Transition Guide: How to Adopt the New Software Rules

ASU 2025-06 is effective for fiscal years beginning after December 15, 2027 (FY2028 for calendar-year companies), with early adoption permitted now. Adopting it is more than flipping a switch: you choose a transition method, possibly write off some in-process software, change your disclosures, and rebuild your capitalization policy around the new threshold. Here’s how.

The three transition methods

FASB gives you three ways to transition:

Method	What you do	Restate past?	Cumulative-effect adjustment
Prospective	Apply the new threshold only to costs incurred on or after adoption, for all projects	No	None
Modified	Prospective, plus derecognize in-process projects that met the old rules but fail the new test	No	One-time hit to opening retained earnings
Retrospective	Apply as if always in effect; re-evaluate every period	Yes — recast comparatives	To opening retained earnings of the earliest period shown

Prospective is simplest, but it leaves a mixed balance sheet — legacy software on the old basis next to new costs under the new rules. Retrospective gives full comparability but is the most work and needs solid historical project records. Modified is the practical middle: clean up the in-process projects that no longer qualify, without restating history.

A worked example: the derecognition

The modified method has a trap worth seeing in numbers. Say you’ve capitalized $2 million on an in-process project under the old stage rules. At adoption, that project fails the new probable-to-complete threshold — its novel technology isn’t yet resolved through coding and testing. Under the modified method, you derecognize it:

Account	Debit	Credit
Retained earnings (opening)	$2,000,000
Capitalized internal-use software		$2,000,000

The $2 million comes off the balance sheet and reduces opening retained earnings — with no prior-year restatement and no hit to the current income statement (it bypasses earnings via the cumulative-effect adjustment). From there, you expense the project until the uncertainty resolves, then resume capitalizing under the new rules. The surprise for many teams is discovering — late — which in-process projects fail the new test. That’s why the project inventory below matters.

Choosing a method

Neither FASB nor the firms name a default — it’s your call, on a few factors:

• Your in-process portfolio — if most active projects still qualify under the new test, prospective has little to clean up. If several pass the old rules but fail the new one, modified gets them off the books cleanly.
• Documentation — retrospective requires reconstructing the threshold analysis for prior periods. Without solid historical records, it’s impractical.
• Comparability — if investors or lenders need a clean trend line, retrospective earns its cost; otherwise it rarely does.
• Materiality and audit effort — the bigger the impact and the more periods involved, the more each method costs.

For most companies, modified is the pragmatic choice: it cleans up the in-process failures with a single retained-earnings adjustment, without the burden of restating history.

Should you adopt early?

You can adopt early, as of the beginning of any annual reporting period (you can decide in an interim period, but it applies from that fiscal year’s first day). Whether you should is strategic:

• For — model your covenants early and renegotiate before the rule is mandatory; set documentation and audit standards before they’re load-bearing; get ahead of the peer scramble.
• Against — if you’re cloud- or SaaS-heavy, the new rule tends to lower capitalized assets and EBITDA, so early adoption is a self-inflicted optics hit ahead of peers who wait. And if your debt agreements don’t contemplate an accounting-principle change, adopting early could trip a covenant before you’ve negotiated relief.

What changes in your disclosures

Adoption changes the footnotes, not just the numbers:

• Capitalized internal-use software now follows ASC 360-10 (property, plant & equipment) disclosures, wherever it sits on the balance sheet. At minimum: the balance and accumulated amortization, the period’s amortization, and a description of the amortization method. (Roll-forwards and in-process amounts follow from applying the PP&E framework.)
• The old ASC 350-30 intangibles disclosures — useful lives, weighted-average amortization period, the five-year schedule — no longer apply to this software.
• You’ll add significant-judgment disclosures explaining how you apply the probable-to-complete threshold and the two uncertainty factors.
• Transition disclosures follow ASC 250, scaled to your method — least for prospective, most for retrospective.

A readiness plan: now through FY2028

1. Fit-gap assessment — map your current stage-based practice against the new probable-to-complete and significant development uncertainty framework. 2. Inventory in-process and planned projects by status and uncertainty. This drives your transition-method choice — it’s how you find the projects that will be derecognized. 3. Model the impact on capitalized balances, EBITDA, and covenant ratios. If a covenant cushion compresses, brief lenders and the audit committee early. 4. Rewrite the capitalization policy around the two-part threshold. 5. Define your “software project” unit of account — the standard leaves it to you. Anchor it on standalone deliverable value (often an epic or initiative), not your team’s org chart, and apply it consistently. 6. Stand up the finance↔engineering evidence process — capture, as they happen, when funding is committed, when scope stabilizes, and when novelty is resolved through coding and testing. You can’t reconstruct these credibly after the fact. 7. Build controls over the probable-to-complete assessment, especially the two uncertainty factors.

Pitfalls to avoid

• The derecognition surprise — under modified or retrospective, in-process projects that fail the new test get written off to retained earnings. Find them through the inventory, not at year-end close.
• Covenants that don’t contemplate accounting changes — a capitalization decrease can mechanically reduce EBITDA and trip a ratio.
• The undefined unit of account — inconsistent or arbitrary “project” boundaries distort what gets capitalized. Agile’s continuous delivery resists discrete projects; you’ll have to impose a defensible, documented framework.
• Misreading “novel or unproven” — it means technical-feasibility risk, not market or scalability risk. Ask engineers whether the technology has been proven in code, not whether the product will succeed.
• Coordinating with auditors too late — the framework is judgment-driven; the evidence trail and controls need auditor buy-in well before close.

The hard part is the evidence

Most of this comes down to one thing: a contemporaneous, defensible record of when each project was funded, when its scope stabilized, and when its technical risk was resolved. That evidence doesn’t live in your accounting system — it lives in your delivery tooling. Applying ASU 2025-06 maps those signals to your backlog, and Quantify captures them automatically — so the transition, and every period after it, rests on data you can show an auditor rather than estimates reconstructed from memory.