ASU 2025-06 is the FASB update, issued in September 2025, that rewrites when companies start capitalizing internal-use software costs under ASC 350-40. It removes the three project stages. Capitalization begins once management has authorized and committed to funding the project and it is probable the project will be completed and the software used as intended. That test is not met while "significant development uncertainty" remains. The update is effective for all entities for annual periods beginning after December 15, 2027, and early adoption is allowed.
This matters more to SaaS companies than to most. The code behind a SaaS product is accounted for as internal-use software, and the FASB itself expects the change "could result in a decrease in software capitalization" for software delivered through the cloud. Less capitalization means lower reported EBITDA for the same engineering spend, while cash stays exactly the same. This guide covers the new test, what it means for an agile team, a worked example, the transition choices and your financial model. For the basics of which software costs are capex and which are opex, see our guide to capex in software development; this page is only about the ASU 2025-06 change.
This is not accounting advice. The rules below are quoted from the ASU text and large-firm guidance as of October 2026. How they apply depends on your facts, your auditor and your reporting framework. Confirm policy decisions with your accountant.
Quick answer
- What changes: the preliminary, application development and post-implementation stages are gone. One threshold decides when capitalization starts.
- The threshold: funding authorized and committed, plus "probable" completion. "Probable" means "the future event or events are likely to occur."
- What blocks it: unproven or novel features not yet resolved through coding and testing, or significant performance requirements that are not identified or are still being substantially revised.
- What does not change: which costs qualify, when capitalization stops, maintenance being expensed, amortization and impairment. ASC 985-20 (software sold or licensed) is untouched.
- When: annual periods beginning after December 15, 2027, so calendar 2028 for most companies, public and private alike.
Why SaaS code sits under ASC 350-40
US GAAP has two models for software costs. ASC 985-20 covers software to be sold, leased or otherwise marketed, such as an on-premises license. ASC 350-40 covers internal-use software. SaaS customers buy access to a service, not a copy of the code, so the code counts as internal-use.
The ASU's basis for conclusions states this directly: Subtopic 350-40 "also applies when an entity develops software that will be used to provide services (rather than to license the software) to external parties," arrangements "often referred to as CCAs" (cloud computing arrangements). The exception is when "(1) the customer has a contractual right to take possession of the software at any time during the hosting period without significant penalty and (2) it is feasible for the customer to either run the software on its own hardware or contract with another party unrelated to the vendor to host the software" (ASU 2025-06, BC13). KPMG's February 2026 handbook says the same: 350-40 "includes software an entity sells access to customers on a SaaS basis" (KPMG, Software and website costs). Deloitte agrees.
ASU 2025-06 does not move that line: it "do[es] not change the area of GAAP that applies to costs incurred to develop software that will be provided via a CCA" (BC68). What it changes is when costs start being capitalized inside 350-40.
Old three-stage model vs the new threshold
| Before ASU 2025-06 | After ASU 2025-06 | |
|---|---|---|
| Structure | Preliminary project stage, application development stage, post-implementation/operation stage | No stages; "neutral to different software development methods" |
| Start capitalizing | Preliminary stage complete, plus authorization and probable completion | Authorized and committed to funding, plus probable-to-complete threshold met |
| Uncertainty test | Not spelled out | Threshold not met while significant development uncertainty exists (two factors) |
| Stop capitalizing | Substantially complete and ready for intended use | Unchanged: "after all substantial testing is completed" |
| Maintenance, training, data conversion | Expensed | Expensed |
| Disclosures | Pointer to other GAAP | ASC 360-10 PP&E disclosures required for all capitalized internal-use software |
The capitalization test in the new 350-40-25-12 has two parts. First, "Management, with the relevant authority, implicitly or explicitly authorizes and commits to funding a computer software project." An example is "approval of expenditures related to internal development." Second, "it is probable that the project will be completed and the software will be used to perform the function intended (referred to as the probable-to-complete recognition threshold)."
The two significant development uncertainty factors
Paragraph 350-40-25-12A says that if significant development uncertainty exists, the threshold "is not met until that significant development uncertainty has been resolved." It exists if either factor is present:
- "The software being developed has technological innovations or novel, unique, or unproven functions or features, and the uncertainty related to those technological innovations, functions, or features, if identified, has not been resolved through coding and testing."
- "The significant performance requirements of the software have not been identified, or the identified significant performance requirements continue to be substantially revised."
Performance requirements are defined as "what an entity needs the software to do (for example, functions or features)." The Board said these are the only two factors (BC56), and it declined to define "significant" beyond its ordinary use in GAAP (BC53).
What it means for an agile SaaS team
The old stages assumed waterfall development: plan, then build, then run. Agile teams plan, build and test in every sprint, so finance teams had to decide which sprint time counted as "application development." The FASB's response was to drop the stages instead of defining sprint-level rules. It also chose not to define the unit of account, even though comment letters raised "a single sprint" as one candidate. Companies "should continue to apply judgment in determining what constitutes a software project" (BC62 to BC63).
In practice the question for each project or epic becomes: is the team still finding out what to build, or whether it can be built? Some illustrative SaaS cases (our examples, not from the ASU):
- A billing integration with a mature payment API. Requirements are fixed and nothing is novel, so the threshold is likely met once the epic is funded, as in the ASU's ERP and website examples.
- A new reporting module still in discovery. Scope is rewritten after each round of design-partner feedback, so factor 2 is present until it settles. This mirrors the ASU's mobile-app example, where funding was approved February 1 but capitalization started only on December 1, when requirements stopped changing.
- An AI feature whose accuracy is unproven. If the team does not yet know whether the model can meet the needed quality, factor 1 applies until coding and testing resolve it. In the ASU's novel-technology example, funding came in February 20X1 and the uncertainty was resolved in March 20X3, one month before testing finished, so only one month of cost was capitalized. The ASU gives no specific guidance on AI model training costs (BC67).
- Bug fixes, on-call, refactoring without new functionality. Maintenance, expensed as before. If you cannot cheaply separate maintenance from "relatively minor upgrades and enhancements," those costs are expensed too (350-40-25-17D).
Evidence that requirements settled (an approved spec, a decision log) and that an unproven feature works (test results) now sets the start date, so keep it.
Worked example: same engineering spend, different EBITDA
Take an illustrative SaaS company. These are our assumptions, not benchmarks:
- Revenue $10.0M; all costs other than engineering $8.0M.
- Engineering $2.4M a year of directly attributable payroll and contractors.
- Split: 40% maintenance, bugs and on-call ($960,000); 15% discovery and prototyping ($360,000); 45% building new features ($1,080,000).
- Old view: the company treated all new-feature build work as application development and capitalized $1,080,000.
- New view: half of the new-feature spend happens while requirements are still being substantially revised or a key feature is unproven, so only $540,000 meets the threshold.
- Straight-line amortization over 3 years; features go live evenly through the year, so year one carries half a year of amortization. Taxes and working capital ignored.
| Year one | All expensed | Old view | New view |
|---|---|---|---|
| Capitalized software | $0 | $1,080,000 | $540,000 |
| Engineering in operating expense | $2,400,000 | $1,320,000 | $1,860,000 |
| EBITDA | -$400,000 | $680,000 | $140,000 |
| EBITDA margin | -4.0% | 6.8% | 1.4% |
| Amortization | $0 | $180,000 | $90,000 |
| Operating income | -$400,000 | $500,000 | $50,000 |
| Operating cash flow | -$400,000 | $680,000 | $140,000 |
| Capitalized software (investing outflow) | $0 | -$1,080,000 | -$540,000 |
| Net change in cash | -$400,000 | -$400,000 | -$400,000 |
Three things stand out. Moving to the new view takes $540,000 off EBITDA, a swing from 6.8% to 1.4% margin, with no change in what the company spent. Cash is identical in every column: capitalization only moves the outflow from operating to investing activities. And if spending stays flat for three or more years, annual amortization catches up with the annual amount capitalized, so operating income converges to -$400,000 under every policy. EBITDA and operating cash flow stay apart permanently, because amortization sits below EBITDA and capitalized spend sits in investing.
How investors read it
Many investors already undo capitalization. In the ASU's basis for conclusions, investors said they "consider software and technology spending to be a current-period cost of doing business" and "would use the information about capitalized costs and amortization to recognize capitalized software costs in current-period earnings, EBITDA, or both" (BC98). So lower EBITDA under the new rules changes the report more than a careful reader's view. The numbers that do not move, such as free cash flow after capitalized software, net burn and burn multiple, matter more in diligence. Expect questions if your EBITDA drops at adoption, and have the bridge ready.
Book vs tax: separate rules
GAAP capitalization and tax deductions are decided independently. For US federal tax, Section 174A lets companies deduct domestic research and experimental expenditures, including software development, in the year paid for tax years beginning after 2024, while foreign research still amortizes over 15 years. None of that depends on whether your books capitalize the same costs under ASC 350-40. Where they differ, the gap is a temporary difference in your tax provision; ask your CPA about the deferred-tax effect.
Transition and early adoption
The effective date is the same for every entity: "annual reporting periods beginning after December 15, 2027, and interim reporting periods within those annual reporting periods." Early adoption is permitted for statements not yet issued, but if you adopt in an interim period you must apply it "as of the beginning of the annual reporting period that includes that interim reporting period" (350-40-65-4). The ASU offers three transition methods:
| Method | What happens | Fits when |
|---|---|---|
| Prospective | New rules apply to new costs incurred from the start of the adoption period, for all projects including in-process ones. Existing balances stay. | You want the least work and have no in-process project that would fail the new test |
| Modified | Prospective, except in-process projects that meet the old rules but fail the new ones: their capitalized costs are derecognized "through a cumulative-effect adjustment to the opening balance of retained earnings" | You have an in-process project, for example an unproven feature, already partly capitalized |
| Retrospective | Recast comparative periods, with a cumulative-effect adjustment at the start of the first period presented | You want comparable history for investors or a future audit, and have the cost detail to rebuild it |
The modified method was added because prospective adoption could leave an in-process project with two capitalization models or an impairment right after adoption (BC114 to BC116). Under it, the write-off goes to retained earnings, not the income statement.
Two other changes may affect your notes. Subtopic 350-50 on website development costs is superseded and its rules move into 350-40. And the ASC 360-10 PP&E disclosures apply to all capitalized internal-use software "regardless of how those costs are presented in the financial statements." The exposure draft would also have required capitalized software cash to be shown as a separate investing outflow, but the final ASU dropped that requirement (BC96, BC100).
What has not changed
- The 350-40 vs 985-20 scope line (BC68), and ASC 985-20 itself.
- Eligible costs: external direct costs, payroll for time spent directly on the project, and interest. G&A and overhead "shall not be capitalized" (350-40-30-3).
- When capitalization stops: "no later than the point at which a computer software project is substantially complete and ready for its intended use" (350-40-25-14).
- Upgrades and enhancements: capitalized only when probable to add functionality (BC64).
- Amortization: straight-line unless another systematic and rational basis better reflects use, over a useful life that considers obsolescence, technology and competition (ASC 350-40-35-4 and 35-5, as excerpted in KPMG's handbook).
- Impairment of abandoned projects: "the rebuttable presumption is that such uncompleted software has a fair value of zero" (350-40-35-3).
- Your own cloud implementation costs as a customer: the hosting-arrangement subsection still tells you to apply the general guidance "as though the hosting arrangement that is a service contract were an internal-use computer software project" (350-40-25-18). The framework from ASU 2018-15 stays, but because it points to the general guidance, the new start test governs when those costs begin to be capitalized.
What to put in your financial model
- Split engineering cost by activity (maintenance, discovery, new-feature build), from time tracking or epic-level estimates.
- Add a capitalization rate on new-feature build only, and lower it for projects with open requirements or unproven technology. Run a scenario at zero to show investors the fully expensed view.
- Build a capitalized-software roll-forward: opening balance, additions, amortization by vintage (3-year straight-line is a common assumption; use your policy), impairments, closing balance.
- Keep cash outside the policy: burn and runway should use total engineering cash, whatever the capitalization split.
- Show EBITDA both ways in board materials for the adoption year, and model the transition method you expect to use if any in-process project would fail the new test.
The SaaS financial model guide shows where these lines sit in a 3-statement model. Adlega's driver-based model lets you set engineering headcount and cost assumptions once and see the P&L and cash effect of each scenario.
FAQ
When is ASU 2025-06 effective?
For all entities, public and private, for annual reporting periods beginning after December 15, 2027, and interim periods within them. For a calendar-year company that is January 1, 2028. Early adoption is permitted as of the beginning of an annual reporting period.
Does ASU 2025-06 apply to SaaS companies?
Yes. Software a SaaS company develops to provide its service is internal-use software under ASC 350-40, unless customers can take possession of it without significant penalty and run or host it elsewhere. The FASB expects the change could reduce capitalization for this kind of software.
What is the probable-to-complete recognition threshold?
It is the second condition for starting capitalization: it is probable that the project will be completed and the software will be used to perform the function intended. It is not met while significant development uncertainty exists.
What is significant development uncertainty?
It exists if the software has novel, unique or unproven functions or features whose uncertainty has not been resolved through coding and testing, or if the significant performance requirements are not identified or are still being substantially revised. Either factor is enough.
Can you capitalize agile sprint costs?
Yes, once the threshold is met for the project, and only for eligible costs such as coding and testing time spent directly on it. The ASU does not define whether the unit of account is a project, a phase or a sprint, so that remains a judgment.
Does ASU 2025-06 change how capitalized software is amortized?
No. Amortization and impairment guidance are unchanged. The update changes when capitalization begins, not which costs qualify, when capitalization stops or how the asset is amortized.