Internal-Use Software Capitalisation Calculator (ASU 2025-06)

What did ASU 2025-06 actually change?

It removed the project-stage framework and replaced it with a threshold test. That is the whole change, and it is narrower than it sounds — but it moves real money.

Under the old ASC 350-40 model, where a cost sat in the sequence decided its treatment. Preliminary project stage costs were expensed, application development stage costs were capitalised, post-implementation costs were expensed. The model assumed a waterfall sequence, which is why it handled agile development badly.

ASU 2025-06 eliminates the stages. Capitalisation now begins when both of two conditions are met: management has authorised and committed to funding the project, and completion is probable with the software performing its intended function. And capitalisation is blocked entirely while significant development uncertainty exists.

What did not change matters just as much, because it keeps the comparison honest. The criteria for which costs are eligible, the amortisation guidance, impairment, and financial statement presentation and disclosure are all unchanged, as is the separate guidance for software sold to customers. So both models in this calculator draw on one shared cost pool and differ on a single boundary.

On the defaults — a $2,660,000 eligible pool across six quarters — the stage model capitalises $2,260,000 and ASU 2025-06 capitalises $1,360,000. That is 39.8% less, with $900,000 moving from the balance sheet to the income statement.

How do I work out when capitalisation starts?

Take the latest of three dates, then check each period for uncertainty. The calculator does both steps and the two produce separate effects.

Step one is the threshold. Capitalisation cannot begin before management authorised and committed funding, and cannot begin before completion became probable. On the defaults those are quarter 2 and quarter 3, and novel-feature uncertainty was resolved in quarter 3. The latest of the three is quarter 3, and capitalisation stops before quarter 6, the placed-in-service quarter — so the window is quarters 3 to 5, three quarters in all. The stage model began capitalising in quarter 2, when development work started.

That single quarter's slip accounts for $420,000. It is worth isolating because it has nothing to do with agile: run the calculator with completely stable requirements and the two models still differ by that amount. The threshold is simply stricter than the old stage boundary.

Step two is the uncertainty block. Significant development uncertainty exists where the software has technological innovations or novel, unique or unproven features whose uncertainty has not been resolved through coding and testing — or where significant performance requirements are unidentified, or the identified requirements keep being substantially revised.

On the defaults, requirements were substantially revised in quarter 5. That quarter's $480,000 is expensed despite sitting inside the capitalisation window.

Two quarters disagree, and their costs sum to exactly the $900,000 capitalisation gap.

Why does revising requirements block capitalisation?

Because requirement instability is evidence that you do not yet know what you are building, and the standard treats that as significant development uncertainty. The logic is sound. The consequence is awkward.

Agile development revises requirements every sprint by design. That is the method working, not failing. So a standard written to be neutral between waterfall and agile contains a test that agile teams trip routinely — and a team doing genuinely innovative work with unproven features can end up capitalising less than the old stage model allowed, which is the opposite of what "modernised for agile" suggests.

The calculator shows how fast this compounds. Hold everything else constant and spread churn across the window:

Substantial requirement revision in all three quarters of the window capitalises nothing at all.

Two judgements the model makes explicit, because you will have to make them too. The standard says requirements that "keep being substantially revised" — an ongoing condition — and this calculator applies it as a per-quarter flag. And it lets capitalisation resume once churn stops, which is a reading rather than a rule. Both are documentation decisions, and an auditor will ask how you drew the line.

The practical response is not to stop revising requirements. It is to define, in advance and in writing, what "substantially revised" means for your projects — a threshold on scope change, a change-control gate, something auditable — because otherwise the judgement gets made retrospectively by whoever is reviewing the capitalisation schedule.

What does this do to reported earnings and to deferred tax?

It front-loads expense, and it shrinks the book-tax gap — which is the part nobody is modelling.

Earnings first. Less capitalised means more expensed now and less amortised later. On the defaults, year one expense goes from $748,000 under the stage model to $1,603,000 under ASU 2025-06 — a $855,000 pre-tax earnings reduction, or $675,450 after tax at 21%. Annual amortisation falls from $452,000 to $272,000, so the charge reverses over the asset's life, but the first year takes the hit.

Then deferred tax, and this is where it gets interesting. Section 174A lets you expense domestic software development immediately for tax, so the tax deduction is the full $2,660,000 in year one regardless of what you capitalise for book. The temporary difference is whatever book has not yet taken.

So ASU 2025-06 reduces the deferred tax liability by $179,550. Book moves closer to tax. That is a genuine benefit sitting underneath an earnings hit, and the two land in different places on the face of the statements — which is exactly the kind of thing that should be in an adoption memo rather than discovered during the first close.

When should I model this, and what does the calculator not cover?

Model it now. It applies to annual periods beginning after 15 December 2027 with interim periods inside those years, and early adoption is permitted — so the decision about whether to adopt early is live, and it is partly an earnings-timing decision.

Transition offers three choices: prospective, applied to costs incurred from the adoption date; modified, applied prospectively to new costs with a cumulative-effect adjustment for certain in-process projects; or retrospective, recasting comparatives with a cumulative-effect adjustment. Those produce materially different comparatives and this calculator does not model them — it prices a single project under each measurement model, which is the input to that transition decision rather than a substitute for it.

Four other boundaries.

One project, six quarters. A portfolio needs the test applied per project, because the threshold dates and the uncertainty assessment are project-specific. Running it across twenty projects means twenty answers, not one.

The milestone dates are judgements, not data. When completion became probable and when novel-feature uncertainty was resolved are assessments management makes and documents. The calculator takes them as inputs and shows how sensitive the answer is — moving uncertainty resolution from quarter 3 to quarter 4 cuts capitalisation from $1,360,000 to $710,000.

Eligible cost is assumed already filtered. Training and data conversion stay expensed and sit outside the pool as separate inputs, because eligibility criteria did not change. Getting the pool right is a prior exercise.

No impairment test. A project that capitalises heavily and then gets abandoned is an impairment question, not a capitalisation one, and that guidance is unchanged.