US GAAP UPDATE-Use Software Accounting: A Deep Dive into ASU 2025-06
Have you ever felt like you’re trying to fit a square peg into a round hole? For years, that’s what it felt like for accountants and developers trying to apply decades-old accounting rules to modern, fast-paced software development. The old guidance was built for a rigid, step-by-step world, but today’s tech is all about flexibility, iteration, and speed (hello, Agile!). The result? Confusion, inconsistency, and financial statements that didn’t always reflect reality. But I’ve got great news! The Financial Accounting Standards Board (FASB) has heard the feedback and rolled out a major overhaul with Accounting Standards Update (ASU) 2025-06. Let’s dive into what’s changing and how to get ready. 😊
Why the Change? Out with the Waterfall, In with Agile 🤔
To really appreciate the new rules, we need to understand the old ones. The previous guidance under Subtopic 350-40 was written in 1998. Back then, most software was built using the “waterfall method.” This is a very linear, sequential process. You finish one phase completely before moving to the next, like a waterfall cascading down a series of steps. The accounting rules mirrored this with three distinct project stages:
- Preliminary Project Stage: The brainstorming phase. All costs here were expensed as incurred.
- Application Development Stage: The building phase. Once you passed certain checkpoints, you could start capitalizing eligible costs.
- Post-Implementation Stage: The maintenance phase. Costs here were generally expensed, unless they added significant new functionality.
This worked fine for a while. But then, the tech world evolved. Today, most development teams use the “agile method.” Agile is all about working in short, iterative cycles called “sprints.” It’s flexible, collaborative, and allows teams to adapt to changing requirements on the fly. Trying to map the rigid “stages” of the waterfall method onto a fluid agile process was a constant headache. Stakeholders reported that it was incredibly challenging to pinpoint exactly when the “preliminary stage” ended and the “application development stage” began, leading to a lot of guesswork and inconsistency across companies.
The core problem was a mismatch between accounting theory and modern reality. ASU 2025-06 was issued to modernize the rules, making them neutral to the development method used, whether it’s waterfall, agile, or something that hasn’t even been invented yet.
The New Rules: A Simpler, More Flexible Approach 📊
The biggest and most welcome change in ASU 2025-06 is the complete removal of the prescriptive project stages. That’s right—they’re gone! Instead of trying to force your project into predefined boxes, the new guidance introduces a single, principles-based threshold for when to start capitalizing costs.
Under the new rules, an entity must start capitalizing eligible internal-use software costs when both of the following criteria are met:
- Management Authorization: Management, with the relevant authority, has authorized and committed to funding the software project. This could be through executing a contract, approving a budget for internal development, etc.
- Probable to Complete: It is probable that the project will be completed and the software will be used to perform its intended function. “Probable” here is linked to the standard GAAP definition: “the future event or events are likely to occur.”
This seems simpler, right? It is, but the second criterion—”probable to complete”—has an important gatekeeper, which we’ll explore in the next section. Here’s a quick comparison of the old way versus the new way:
| Aspect | Old Guidance (Pre-ASU 2025-06) | New Guidance (ASU 2025-06) |
|---|---|---|
| Framework | Based on three rigid, sequential “project stages” (Preliminary, Development, etc.). | Development stages are eliminated. A single, principles-based threshold applies. |
| Capitalization Start | Begins after the preliminary project stage is complete and management authorizes the project. | Begins when management authorizes funding AND it’s probable the project will be completed and used. |
| Flexibility | Poorly suited for modern, iterative (Agile) development methods. | Neutral to the development methodology, accommodating both waterfall and agile. |
The Core Concept: “Significant Development Uncertainty” 🧮
Here’s where the real judgment comes in. To determine if a project is “probable” of completion, the new guidance requires you to first assess whether there is “significant development uncertainty.” If this uncertainty exists, the “probable-to-complete” threshold is not met, and you cannot start capitalizing costs. You must continue to expense costs until that uncertainty is resolved.
Significant development uncertainty exists if either of the following two factors is present:
Factor 1: Technological Novelty 📝
The software being developed has technological innovations or novel, unique, or unproven functions or features, AND the uncertainty related to those elements has not been resolved through coding and testing.
Factor 2: Unclear Performance Requirements 📝
The entity has not yet determined what it needs the software to do. Specifically, the significant performance requirements (i.e., the key functions or features) have not been identified, or the identified requirements continue to be substantially revised.
Essentially, FASB is saying that you can’t be “probable” of completing a project if you’re still exploring brand-new technology or you haven’t even locked down what the software is supposed to do. This makes a lot of intuitive sense and aligns the accounting more closely with the R&D-like nature of early-stage, exploratory software work.
This is the most critical judgment area in the new standard. If you determine your project involves novel technology, you must demonstrate that the uncertainty has been resolved via coding and testing before you can flip the switch to capitalization. Likewise, if your product roadmap is still in flux, you’ll need to continue expensing costs.
What This Means for Your Business 👩💼👨💻
The impact of this update will vary depending on the type of software you develop. The FASB anticipates that for many common internal-use projects, the amount of capitalized costs won’t change significantly.
For example, if you’re implementing a well-established ERP system from a major vendor (like in Example 1 of the ASU), there’s likely no significant development uncertainty. The technology isn’t novel, and the performance requirements are clear. In this case, you’d likely start capitalizing costs as soon as you sign the contract and commit the funds, which is similar to the outcome under the old rules.
However, the story is very different for companies that develop software to be provided to customers via a cloud computing arrangement (CCA), often known as Software-as-a-Service (SaaS). Previously, these companies followed the internal-use software guidance, which often led to significant capitalization. Under the new rules, these companies are much more likely to face “significant development uncertainty,” especially if their product is innovative. This means they will likely expense more costs and capitalize less. This is a deliberate change by the FASB to better align the accounting for SaaS products with the accounting for software sold via a traditional license (which falls under the stricter external-use guidance of Subtopic 985-20).
Other notable changes include the supersession of the separate guidance for website development costs (Subtopic 350-50), which is now merged into Subtopic 350-40. Additionally, the update clarifies that the disclosure requirements for Property, Plant, and Equipment (PP&E) apply to all capitalized internal-use software costs.
Effective Date & Transition 🗓️
You have some time to prepare for these changes. The new standard is effective for all entities for annual reporting periods beginning after December 15, 2027. The good news is that early adoption is permitted, so if these rules simplify your process, you can make the switch sooner.
FASB has also provided a lot of flexibility for the transition. You can choose one of three methods:
- Prospective Approach: The simplest way. You apply the new rules to new software costs incurred from the date of adoption onward, even for projects already in progress. You don’t touch any previously capitalized amounts.
- Modified Retrospective Approach: A hybrid method. You apply the new rules prospectively, but for any in-progress projects that were being capitalized under the old rules but do NOT meet the new criteria, you write off the previously capitalized balance as an adjustment to retained earnings.
- Full Retrospective Approach: The most comprehensive way. You go back and restate all prior periods presented in your financial statements as if the new rules had always been in effect. This provides the most comparability for investors but requires the most historical data.
Key Takeaways of the Post 📝
This has been a lot to digest, so let’s quickly recap the most important points from ASU 2025-06:
- Project Stages Are Gone: The old, rigid Preliminary, Development, and Post-Implementation stages have been completely removed, making the guidance development-method neutral.
- New Capitalization Threshold: Capitalization now starts only when management authorizes funding AND it’s “probable” the project will be completed and used as intended.
- Watch for “Significant Development Uncertainty”: You cannot meet the “probable” threshold if your project involves novel/unproven technology or if its key performance requirements are still undefined or in flux. All costs must be expensed until this uncertainty is resolved.
- Impact on SaaS/CCA: Companies developing software as a service will likely expense more and capitalize less, bringing their accounting more in line with traditional software sellers.
- Flexible Transition: The update is effective after Dec 15, 2027, with early adoption permitted. Entities can choose a prospective, modified, or full retrospective transition method.
ASU 2025-06 at a Glance
Frequently Asked Questions ❓
ASU 2025-06 is a much-needed update that brings accounting for software costs into the 21st century. It replaces rigid, outdated rules with a more flexible, judgment-based framework that better reflects how software is actually built today. If you have any more questions or want to share how your team is preparing for the transition, feel free to drop a comment below! 💬
