The Ultimate Guide to Internal-Use Software Accounting (FASB ASU 2025-06)
If you’ve ever tried to apply late-90s accounting rules to a modern tech project, you know the struggle is real. Picture this: your engineering team is running two-week agile sprints, constantly iterating and pivoting, but you’re sitting there trying to figure out which “sequential stage” of development they are in just so you can capitalize some costs. It’s like trying to fit a square peg into a round hole, right? 😊
Well, I have some great news. The Financial Accounting Standards Board (FASB) heard the collective sighs of accountants everywhere and issued ASU 2025-06. This update specifically targets Subtopic 350-40 to modernize the accounting for internal-use software. Today, we’re going to break down exactly what this means for you, how the capitalization rules have changed, and what you need to do to prepare.
Goodbye Waterfall, Hello Agile 🏃♂️
Let’s be honest, the old guidance was painfully outdated. Written back in 1998, it heavily relied on the “waterfall” method of software development. For those who might not be familiar, the waterfall method is a very linear, sequential process. You finish one distinct stage (like preliminary planning) before you move methodically to the next (like application development).
But that’s just not how software is built today. Today, the agile method rules the tech world. Agile is incredibly iterative and flexible. Teams work in short “sprints,” frequently revisiting and reworking earlier tasks based on continuous feedback. Because of this intended flexibility, the idea of having distinct, sequential development stages is practically non-existent in an agile project.
Trying to apply the old staging rules to agile projects created a lot of complexity and inconsistent practices among entities. To fix this, ASU 2025-06 makes a bold but welcome move: it completely eliminates all references to project development stages in Subtopic 350-40. This means you no longer have to shoehorn your agile sprints into arbitrary development phases.
The FASB considered creating a single accounting model for both internal-use and external-use software. However, they couldn’t reach a consensus, so Subtopic 985-20 (for external-use software) remains entirely unchanged by this ASU.
The New “Probable-to-Complete” Threshold 🎯
So, if we aren’t using project stages anymore, how do we know when to start capitalizing our software development costs? The answer lies in the probable-to-complete threshold.
Under the new amendments, an entity must rely solely on specific criteria to begin capitalization. You can start capitalizing costs only when both of the following conditions are met:
- Management has authorized and committed to funding the software project.
- It is probable that the project will be completed and the software will be used to perform its intended functions.
Until both of these criteria are satisfied, all your software development costs must be expensed as they are incurred.
Now, you might be wondering, what exactly does “probable” mean in this context? There was some historical confusion about this because the original guidance referenced an old Concepts Statement that was later superseded. To clear things up, the FASB explicitly linked the term “probable” to the ASC Master Glossary definition. Therefore, “probable” simply means that the future event or events are likely to occur.
Tackling “Significant Development Uncertainty” 🤔
Here is where things get a bit more nuanced. To help apply the probable-to-complete threshold, the FASB added some new guardrails. Specifically, you cannot consider the threshold met if there is significant uncertainty surrounding the software’s development.
You have to assess significant development uncertainty for every single software project. How do you know if it exists? The guidance points to two main factors:
| Factor | Description |
|---|---|
| Novel, unique, or unproven features | This occurs when the software contains novel, unique, or unproven functions, features, or technological innovations that haven’t been proven through coding and testing. |
| Significant performance requirements | You must determine if the software’s significant performance requirements have been established and are no longer subject to substantial revision. |
If you have novel or unproven features, you generally need to resolve that uncertainty through actual coding and testing before you can start capitalizing costs. Practically speaking, creating a “working model” of the software is usually a good way to prove viability, though it’s not strictly required by the rules if it would inappropriately delay capitalization.
The FASB clarified that you don’t need to resolve all performance requirements before capitalizing—only the significant ones. Don’t hold up your capitalization for minor unresolved features or significant features that only need minor tweaks. This requires solid judgment, especially in agile environments where requirements constantly evolve!
Impacts on Websites and SaaS Software 🌐
This ASU doesn’t just affect your backend ERP implementations. It has some ripple effects across other areas of software development.
First, let’s talk about website development. Because modern websites are basically just software applications, the FASB decided that having separate guidance wasn’t useful anymore. Therefore, ASU 2025-06 entirely eliminates Subtopic 350-50 (which covered website development costs). Any relevant, non-stage-specific guidance from that subtopic has been relocated right into Subtopic 350-40. You’ll account for your website development just like your internal-use software.
Second, if you build software to sell to customers solely on a Software-as-a-Service (SaaS) basis, this update might change your numbers. Evaluating “significant development uncertainty” might push back the date you meet the probable-to-complete threshold. As a result, you might end up expensing a larger portion of your SaaS development costs, pushing your accounting outcomes closer to those of traditional external-use software.
Capitalization Eligibility Checker 🔢
Not sure if your current project phase qualifies for cost capitalization under the new ASU 2025-06 rules? Try out this quick interactive checker to see where you stand based on the new guidance!
Project Capitalization Checker
Effective Dates and Transition 🗓️
Alright, you’re probably asking, “When do I actually have to start doing this?”
For all entities, the new guidance is effective for annual and interim periods in fiscal years beginning after December 15, 2027. However, early adoption is absolutely permitted. You can adopt it in any interim or annual period, provided your financial statements haven’t been issued yet for the beginning of that fiscal year.
When you do transition, you have three options to choose from:
- Retrospective: Apply the new rules to prior periods, resulting in a cumulative effect adjustment to retained earnings at the beginning of the first year presented.
- Prospective: Apply the new rules only to software costs incurred after the adoption date (for both new and existing in-process projects).
- Modified Prospective: Apply prospectively, but also record a cumulative effect adjustment through retained earnings for any previously capitalized in-process costs that wouldn’t qualify under the new rules.
ASU 2025-06 Key Takeaways
Frequently Asked Questions ❓
Navigating accounting standard updates is never a walk in the park, but ASU 2025-06 brings much-needed clarity for modern tech teams. By ditching the waterfall stages and focusing on the probable-to-complete threshold, your accounting can finally match the speed of your agile development. What are your thoughts on assessing “significant development uncertainty”? Let me know in the comments below! 😊
