Ask a software engineering manager when a project "started" and you'll get a sprint number. Ask their controller the same question, and under the accounting rules that have governed internal-use software since 1998, the answer was supposed to come from a rigid three-stage checklist that assumes nobody writes code until the requirements are locked. Anyone who has shipped software in the last decade knows that's not how it works anymore — and in September 2025, FASB finally admitted it too.
Accounting Standards Update (ASU) 2025-06, Intangibles—Goodwill and Other—Internal-Use Software (Subtopic 350-40): Targeted Improvements to the Accounting for Internal-Use Software, throws out the old stage-based test entirely and replaces it with a single, judgment-based question: is it probable this software will actually get finished and do what it's supposed to do? For any company that develops software in-house — and especially for the agile shops the old rule was never built for — this changes when development costs move from the income statement to the balance sheet, and by how much.
The Problem: A 1998 Rulebook for Waterfall Development
The guidance ASU 2025-06 replaces, ASC 350-40 (originally SOP 98-1), was written when "software development" meant a linear waterfall process. It split every internal-use software project into three sequential stages:
- Preliminary project stage — conceptual formulation, evaluating alternatives, vendor selection. Everything here gets expensed as incurred.
- Application development stage — actual coding, configuration, and testing. Costs here get capitalized.
- Post-implementation stage — training and maintenance. Expensed again.
That framework works fine if a team spends three months writing a requirements document, gets sign-off, and then starts building. It falls apart the moment a team is running two-week sprints, shipping incremental releases, and revising scope every retro. In an agile environment, "preliminary" and "application development" aren't sequential phases — they're interleaved, sometimes within the same sprint. Companies and their auditors have spent years arguing over which stage a given two-week sprint actually belongs to, and the honest answer was often "some of both, we're guessing." FASB's own outreach found stakeholders consistently flagging this as one of the most operationally painful parts of GAAP to apply consistently.
The Fix: One Test, Not Three Stages
ASU 2025-06 removes every reference to the old project stages. In their place, it sets a single "probable-to-complete" recognition threshold. Under the new guidance, a company capitalizes internal-use software costs once both of the following are true at the same time:
- Management has authorized and committed to funding the project. This isn't a new concept — it existed in the old guidance too — but it now does more work as one of only two gating conditions instead of being buried inside stage analysis.
- It is probable that the project will be completed and the software will be used to perform its intended function. This is the genuinely new piece, and it's where the judgment lives.
That second criterion requires assessing whether significant development uncertainty still exists. FASB points to two main sources of that uncertainty:
- Unproven technology or novel functionality whose feasibility hasn't yet been demonstrated through actual coding and testing — not a design doc, not a spec, but working proof.
- Undefined or still-shifting performance requirements — the standard defines these as "what an entity needs the software to do, e.g., functions or features." If the team is still meaningfully debating what the product needs to do, that uncertainty hasn't been resolved.
In practice, this means capitalization timing now tracks evidence of feasibility, not calendar phase. A team that spikes a technically novel feature for two sprints before committing to build it in earnest would expense those spike sprints — the uncertainty about whether it can even be built hasn't been resolved yet. Once the spike proves it out and management commits budget to the full build, the "probable-to-complete" threshold is met and subsequent development costs get capitalized, agile ceremonies notwithstanding.
Why FASB Says Capitalization Won't Change Much — Except for SaaS
FASB's own expectation is that, for most on-premises or license-based internal-use software, the amendments won't shift capitalization outcomes dramatically — companies were already capitalizing once real coding began, and the new test lands in roughly the same place, just without the stage-labeling exercise.
Software developed for delivery through a SaaS or cloud arrangement is a different story. FASB explicitly expects capitalization to decrease for these projects. The reasoning: SaaS products are, by their nature, built and rebuilt continuously, with significant technical and product uncertainty persisting deep into the development timeline — sometimes right up until a feature nears release. Under the probable-to-complete test, that persistent uncertainty means many SaaS development costs won't clear the capitalization bar until much later in the build than the old stage model would have implied. The net effect: more of the engineering payroll for a SaaS product lands as current-period R&D expense rather than a multi-year amortizing asset. That's a meaningful shift for any SaaS company's reported EBITDA and asset base, even before a single line of the actual code changes.
A Concrete Example: Two Teams, Two Outcomes
Say a 40-person SaaS company decides to build an AI-powered forecasting module for its product. Here's how the old and new rules would treat the same eight-month build differently.
Under the old stage model, the finance team would try to draw a line: the first six weeks of requirements-gathering and vendor evaluation were "preliminary" (expensed), and everything after the kickoff meeting was "application development" (capitalized) — even though the engineering team spent the next two months running exploratory spikes to figure out whether their chosen forecasting approach could hit acceptable accuracy at production data volumes. Under the letter of the old rule, once the "stage" flipped, those spike sprints often got capitalized too, because they technically happened after the kickoff meeting.
Under ASU 2025-06, the finance team instead asks: when did it become probable this feature would be completed and work as intended? If the accuracy approach was still unproven for the first two months — the team was testing three different modeling approaches and didn't know if any would clear the bar — that entire exploration period gets expensed, regardless of which "stage" it fell into on a calendar. Capitalization starts only once the team picks a validated approach and management commits budget to build it out, which in this example might be month three, not month two. The result: a smaller capitalized asset, a larger current-period R&D expense, and — importantly — a number the CFO can actually defend in an audit, because it's tied to a specific, documented decision point rather than a stage label applied after the fact.
This is exactly the shift FASB expects across the SaaS sector: less "we called it application development because that's what came after the kickoff call" and more "we can point to the sprint where the technical risk was retired."
Effective Dates and Transition
ASU 2025-06 is effective for all entities — public and private — for annual reporting periods beginning after December 15, 2027, and interim periods within those years. Early adoption is permitted for any entity, in any interim or annual period, once the standard is issued.
Entities can apply the amendments using one of three transition approaches: prospectively to only new software costs incurred after the effective date, prospectively to costs incurred on or after the beginning of the year of adoption, or retrospectively to all periods presented. That flexibility matters — a company mid-build on a major platform rewrite when the rule kicks in doesn't have to unwind years of capitalized cost history unless it chooses the retrospective option.
What Small and Mid-Size Software Companies Should Do Now
December 2027 sounds distant, but the practical prep work is not a last-quarter task, particularly for companies running lean finance teams without a dedicated technical accounting function.
Start documenting the "probable-to-complete" judgment call in real time, not in hindsight. The old stage model was mechanical — you could reconstruct which stage a project was in months later from sprint dates. The new test asks when did we stop being technically uncertain, which is a judgment call that gets much harder to reconstruct after the fact. Build a lightweight habit now: when engineering leadership and finance agree a feature has cleared its technical spike and is committed for build, log that date. That log becomes your capitalization start date and your audit support.
Separate "exploration" work from "committed build" work in your time tracking or project codes, if you don't already. Whether that's a Jira epic flag, a separate cost-center code, or just a tagged label in your time-tracking tool, having a clean data trail for when a feature moved from spike/prototype to committed development will make applying the new standard dramatically less painful than trying to reconstruct it from memory during an audit.
Model both transition options before you pick one. If your company has been aggressively capitalizing SaaS development costs under the old stage framework, retrospective application could produce a one-time write-down of previously capitalized assets as those costs get reclassified as if they'd been expensed all along. A prospective approach avoids that restatement but means your income statement won't reflect the new methodology until new projects start after adoption. Run the numbers under both before your audit committee has to.
Talk to your auditor early, especially if you're SaaS. Given FASB's own expectation of a capitalization decrease for SaaS development, auditors are likely to scrutinize probable-to-complete judgments more closely than they scrutinized stage classifications under the old rule — precisely because it's more subjective. A company that walks into its 2028 audit with a documented, contemporaneous framework for making that call will have a much easier conversation than one reconstructing it after the fact.
Clean Books Make Judgment Calls Easier to Defend
Every accounting judgment — and "probable-to-complete" is squarely a judgment call — is only as defensible as the records behind it. If your chart of accounts already separates R&D spend by project, and your ledger entries are versioned and auditable rather than living in disconnected spreadsheets, applying a standard like ASU 2025-06 becomes a matter of tagging existing data rather than reconstructing history from Slack threads. Beancount.io's plain-text accounting gives you that kind of transparent, git-versioned ledger by default — every entry traceable, every change reviewable, with no vendor lock-in. Get started for free and build books that hold up whether the question comes from an auditor, an acquirer, or the next FASB update.