Why FASB’s New Software Cost Guidance Requires More Collaboration with Engineering Teams

"Is the goal to make as much software development as R&D as possible?"

That was Numeric Engineer Nelson Crespo's response when I asked our engineering team about the new software capitalization guidance. And honestly? He's spot on. 

The FASB's ASU 2025-06 does expect more costs to be expensed, particularly for software developed for cloud computing arrangements. The Board acknowledged that development risks for SaaS products often resemble those for software sold externally, where most development costs are expensed under ASC 985-20. By requiring entities to evaluate "significant development uncertainty" before capitalizing costs, the guidance naturally pushes more expenses into the income statement.

But here's what often gets lost: while the guidance is better aligned with modern development practices, it doesn't eliminate professional judgment. It refocuses where that judgment is applied. And applying it effectively requires genuine collaboration between finance and engineering teams.

As someone who spent years in technical accounting advisory before joining Numeric, I've navigated these conversations countless times. To illustrate where judgment still matters, I walked through the new guidance with our engineering team. What emerged is instructive for any organization preparing to adopt the standard.

The Fundamental Change: From Stages to Criteria

The ASU removes all references to "development stages" from ASC 350-40. Instead of determining which stage a project is in, entities now evaluate two key criteria:

1. Management authorizes and commits to funding a computer software project
2. It is probable that the project will be completed and the software will perform its intended function (the "probable-to-complete recognition threshold")

The second criterion is where judgment enters. The guidance introduces "significant development uncertainty" and specifies two factors that indicate such uncertainty exists:

• The software has technological innovations or novel, unique, or unproven functions or features, and the uncertainty hasn't been resolved through coding and testing
• The significant performance requirements haven't been identified, or they continue to be substantially revised

While more intuitive than the old stage-based model, applying these criteria to real projects requires technical understanding that finance teams typically don't possess without engineering input.

Three Areas Where Judgment and Collaboration Are Essential

1. Distinguishing Between "Novel/Unproven" and "Technically Challenging"

One of the most significant judgment areas is determining what constitutes "technological innovations or novel, unique, or unproven functions or features." Not every difficult technical problem meets this threshold.

The Accounting Question:

The guidance requires us to expense costs until any "novel, unique, or unproven functions or features" have been proven through coding and testing. This differs from features that are just technically difficult but use established approaches.

When you're planning projects, which features do you view as truly "unproven," meaning you're not confident they'll work until you've actually coded and tested them, versus features that are challenging but use technology and approaches you know will work?

Engineering Perspective:

Justin Chang, another one of Numeric’s engineers, responded: "Almost all of our work here is unproven from a market, scope, or scale standpoint, but not technically or scientifically unproven. I'm not quite sure what that would even look like for most SaaS web app companies."

Implications for Capitalization:

This response reveals a critical disconnect between accounting terminology and engineering reality. Engineers at modern SaaS companies face uncertainty about product-market fit or whether features will scale, but they rarely face fundamental uncertainty about whether something can be built at all.

The accounting question isn't about market risk. It's about technical feasibility: can we build this functionality using known technical approaches? For most SaaS companies building with established frameworks and technologies, the answer is often yes, even if implementation is complex.

This means many projects may meet the probable-to-complete threshold earlier than finance teams expect. However, the guidance still requires that significant performance requirements be identified and stable. If you're building features where you expect substantial iteration or where specifications are still evolving significantly, you may not meet the capitalization criteria even if you're confident the features can be built.

2. Defining the "Software Project"

The term "software project" is notably undefined in the ASU. This creates significant judgment: what constitutes a single software project for evaluating the probable-to-complete threshold?

The Accounting Question:

For accounting purposes, we need to determine what constitutes a single "software project" since we evaluate capitalization at the project level. A project could be an entire application, a major feature, or a set of related functions. There's no strict definition.

I asked our engineering team to think about our development work. Is it one integrated project where all pieces must work together, or could you deliver and deploy certain components independently even if other parts aren't finished?

Engineering Perspective:

Justin's response: "We normally think in terms of continuous delivery of small, independently deliverable chunks. Any discussion of where to draw the lines of what a software project is, is wholly dependent on what this definition will be used for."

Implications for Capitalization:

This captures why unit of account determination is so challenging. Modern engineering teams often don't think in terms of discrete "projects" at all. They think in terms of continuous delivery and iterative development.

From an accounting perspective, you need to impose a framework that may feel artificial. Define software projects based on functional capability and business intent rather than engineering's organizational structure.

For example, if you're building a new analytics dashboard, that might be one software project even though engineering delivers it incrementally over months. The question is: does each increment provide standalone value you'd deploy independently, or are you building toward a complete dashboard you'll launch as a package?

This determination has direct accounting implications. If the entire dashboard is one project and some features involve novel technical approaches, you may need to expense costs until all uncertain elements are resolved. If you can treat each visualization as a separate project because they'd be deployed independently, you might capitalize costs for proven features while expensing costs for uncertain ones.

3. Determining When Development Uncertainty Is "Resolved"

The guidance states that if novel or unproven features are identified, uncertainty must be "resolved through coding and testing" before capitalization can begin. But what level of coding and testing is sufficient?

The Accounting Question:

When you have uncertain or unproven features, accounting rules say we can't capitalize costs until uncertainty is "resolved through coding and testing." But there are different levels of confidence as development progresses: proof-of-concept, prototype, production-ready code.

At what point do you typically have confidence that an uncertain feature will actually work as intended? When you've validated the technical approach with a proof-of-concept, when you've tested with real data, or at some other milestone?

Engineering Perspective:

Justin's response echoed his earlier point: "Same as before. We rarely have features that we are uncertain we can get working from a technical standpoint. Instead, it's about 'will it sell,' 'do users like it,' etc."

Implications for Capitalization:

For many SaaS companies, "resolving technical uncertainty through coding and testing" may not be the primary gate for capitalization. If your engineering team is rarely uncertain about technical feasibility, the more relevant question becomes whether you've identified and stabilized your significant performance requirements.

This view actually supports capitalization. Once management commits to a project and scope is sufficiently defined, you may be able to begin capitalizing without waiting for extensive proof-of-concept work.

However, there are exceptions. If you're incorporating emerging technologies like AI/ML capabilities or other areas where your team lacks prior experience, you may genuinely face technical uncertainty. In those cases, work with engineering to identify the milestone at which they're confident the approach will work. That's your capitalization trigger.