Why the New Software Accounting Standard Is Really About Judgment
Most finance leaders are familiar with the traditional stages of software accounting: preliminary project stage, application development stage, and post-implementation stage. The new guidance issued by the Financial Accounting Standards Board removes those stages entirely. In their place, the standard introduces a framework centered on a single question: Is the software project probable of completion, and has significant development uncertainty been resolved?
For many organizations, answering that question consistently will require more than accounting analysis—it will require stronger processes and better operational data. Accounting standards do not usually generate much excitement outside of finance teams. But every so often, a change arrives that reflects a broader shift in how companies actually operate. The Financial Accounting Standards Board’s update to the accounting guidance for internal-use software development is one of those moments.
Accounting Meets Modern Software Development
The previous internal-use software guidance was originally developed in the late 1990s, when software projects generally followed a sequential “waterfall” development model. Under that approach, accounting treatment depended on whether costs were incurred in one of three stages: the preliminary project stage, the application development stage, or the post-implementation stage. That framework worked reasonably well when software projects progressed through clearly defined phases.
Today, however, most development environments look very different. Many organizations rely on agile or iterative development, where design, testing, and refinement occur continuously rather than in discrete stages. Over time, this created tension between how software is actually built and how accounting guidance required projects to be evaluated.
In response, the Financial Accounting Standards Board issued Accounting Standards Update (ASU) 2025-06, which modernizes the accounting framework for internal-use software under ASC 350-40. The update replaces the stage-based model with a simpler but more judgment-oriented approach.
The Shift Away from Project Stages
One of the first things finance leaders notice about the updated guidance is that the familiar stage-based framework disappears entirely. Instead of asking which stage a project is in, finance teams now focus on two conditions. Software development costs may be capitalized when:
- Management has authorized and committed to funding the software project, and
- It is probable that the project will be completed and the software will perform its intended function.
At first glance, that framework appears straightforward. However, the standard adds an important consideration: the “probable-to-complete” threshold is not met if significant development uncertainty exists.
Examples of development uncertainty may include situations where the software includes novel, unique, or unproven functionality, or where significant performance requirements are still evolving or undergoing substantial revision.
In other words, finance teams must now evaluate not just whether a project has been approved, but also whether the underlying technology and requirements are sufficiently stable.
Where Judgment Enters the Process
As organizations begin working through the new guidance, several practical questions tend to emerge. These questions do not always have mechanical answers, which is why the updated framework places greater emphasis on professional judgment—particularly around development uncertainty, project authorization, and supporting disclosures.
1. What exactly is the software project?
Large initiatives often include multiple modules, platforms, or enhancements. Determining whether those components represent a single project or multiple independent projects can influence when capitalization begins.
2. Does significant development uncertainty still exist?
If the software includes features that are novel or unproven—or if key performance requirements continue to change—the project may still be considered uncertain from an accounting perspective.
3. When has that uncertainty been resolved?
In practice, development uncertainty is often considered resolved once coding and testing demonstrate that the functionality can be successfully implemented.
4. What evidence supports the conclusion?
Auditors will typically expect documentation supporting capitalization decisions, such as approved project budgets, design specifications, testing results, and confirmation that performance requirements have stabilized.
How the Standard Plays Out in Practice
The practical implications of the new framework become clearer when applied to real software initiatives.
Example: ERP Implementation with Custom Integrations
A company begins implementing a new ERP system that includes several custom integrations with existing operational platforms. Management approves the project and commits funding early in the process. However, several integrations involve complex functionality that has not yet been technically validated.
At this stage, finance may determine that significant development uncertainty still exists, meaning the capitalization threshold has not yet been met. Once coding and testing demonstrate that the integrations function as intended—and the project is considered probable of completion—eligible development costs incurred after that point may be capitalized. This example illustrates how capitalization decisions are tied to the resolution of development uncertainty rather than predefined project stages.
Implementation: What Finance Leaders Should Expect
Despite the increased emphasis on judgment, implementing the new guidance is generally manageable for most organizations. In many cases, the work primarily involves clarifying accounting policies, documenting decision frameworks, and ensuring the necessary information can be gathered from development teams.
In practice, implementation often focuses on updating accounting policies, refining project approval controls, and strengthening capitalization documentation and memos.
Typical implementation efforts often fall within the following ranges:
- Small companies: ~1–2 months
- Mid-size companies: ~2–3 months
- Large companies: ~3–4 months
The complexity of implementation typically increases with the number of software development initiatives, the level of custom development, the degree to which engineering teams are decentralized, and the strength of existing cost-tracking systems.
A Few Practical Implications to Keep in Mind
For many organizations, the overall amount of capitalized costs may not change significantly. However, the timing of capitalization—and the documentation supporting those decisions—becomes more dependent on management’s assessment of development uncertainty. In addition:
- For software developed in connection with cloud computing arrangements, capitalization may decrease as development uncertainty persists longer.
- Website development guidance is now incorporated into ASC 350-40, aligning it with internal-use software accounting.
These changes reinforce the need for clear policies and consistent application across projects.
Where Implementations Often Become Challenging
For many finance organizations, interpreting the accounting guidance itself is not the most difficult part. The greater challenge is operational. Questions that rarely existed under the previous stage-based model suddenly become important:
- How are software projects defined across engineering teams?
- How does finance know when development uncertainty has been resolved?
- Where is the documentation supporting those judgments?
- How are development costs tracked across payroll, vendors, and project management systems?
Without clear processes and reliable data, finance teams may find themselves relying on spreadsheets or informal communication with development teams. Over time, this can lead to inconsistent decisions and limited audit support.
PCG Point of View
Modern accounting standards increasingly rely on judgment supported by documentation and evidence. The updated software accounting guidance is a clear example of this shift. Under the previous model, many capitalization decisions could be tied to predefined project stages. The updated framework requires finance teams to evaluate development uncertainty, technical feasibility, and the probability of completion—often in coordination with engineering and product teams.
In practice, implementing the new guidance often requires two capabilities working together. First, organizations need accounting expertise to interpret the guidance, define policies, and support audit-ready documentation. Second, they need reliable data and operational processes that allow those policies to be applied consistently across software development initiatives. When those capabilities are aligned, finance teams can move beyond manual tracking and toward a repeatable and transparent financial process.
Final Perspective
ASU 2025-06 reflects a broader shift in accounting standards toward principles-based frameworks that rely more heavily on management judgment. For finance leaders, the challenge is not only understanding the accounting guidance but also establishing the processes and data infrastructure needed to apply those judgments consistently as software development continues to evolve.
Sources Consulted: Financial Accounting Standards Board (ASU 2025-06, Internal-Use Software Accounting Improvements), Deloitte (Heads Up: Software Cost Guidance), EY (Technical Line), KPMG (Financial Reporting View), PwC (Viewpoint).