ASU 2025-06 is not effective until annual periods beginning after December 15, 2027. For calendar-year public companies, the mandatory adoption date is January 1, 2028. But SEC Staff Accounting Bulletin Topic 11.M, commonly called SAB 74, requires companies to disclose the expected impact of recently issued accounting standards before they are adopted. That disclosure obligation is active now, in the Q2 2026 Form 10-Q, for every company to which ASU 2025-06 will make a material difference.
For most technology companies, SaaS businesses, financial institutions with significant technology development programmes, and any company building AI or LLM-based software products, ASU 2025-06 will make a material difference. The combination of two structural changes, removing the three project stages and introducing the significant development uncertainty concept, is expected by FASB itself to result in more software development costs being expensed rather than capitalised. That expectation from the standard-setter is itself the basis for a SAB 74 disclosure even before a company has completed its own impact assessment.
This post covers what SAB 74 requires, what ASU 2025-06 changes under ASC 350-40, what the significant development uncertainty concept means specifically for AI and LLM-based software, what the three cost categories most affected are, and what the Q2 2026 10-Q SAB 74 disclosure must contain.
This is a different post from a general ASU 2025-06 mechanics guide. The focus here is the SAB 74 disclosure question: what does your Q2 10-Q need to say right now, before adoption, and how do you handle the fact that the impact estimate is genuinely difficult for AI software?
What Is SAB 74 and What Does It Require Before an Accounting Standard Takes Effect?
SEC Staff Accounting Bulletin Topic 11.M, the SAB 74 disclosure requirement, is not a GAAP standard. It is an SEC staff position that requires registrants to disclose the effect that recently issued accounting standards not yet required to be adopted will have on the financial statements when applied in future periods.
The SAB 74 obligation applies when a company has not yet adopted a standard and the standard could have a material effect on future financial statements. The disclosure must be made in the footnotes to the financial statements for each period between the standard's issuance and its mandatory adoption date.
The required elements of a SAB 74 disclosure depend on how far along the company is in its assessment:
If the company has completed its impact assessment, the disclosure must describe the expected financial statement effects, including the estimated dollar impact on balance sheet line items (in this case, capitalised software), the income statement effect (expected increase in R&D or software development expense), and any transition approach selected.
If the company has not yet completed its impact assessment, the disclosure must explain when the standard was issued, its mandatory effective date, and that the company is currently evaluating the expected impact. A statement that the impact cannot yet be quantified is permissible only where the assessment is genuinely incomplete. It is not an indefinite extension of the disclosure obligation.
For ASU 2025-06, the mandatory effective date for public business entities is annual reporting periods beginning after December 15, 2027. For calendar-year companies, this is January 1, 2028. Early adoption is permitted as of the beginning of any annual reporting period.
The Q2 2026 10-Q filing in August 2026 is approximately 16 months after ASU 2025-06 was issued in September 2025. Companies that have not yet produced even a preliminary impact assessment for ASU 2025-06 need to explain why in their SAB 74 disclosure. A boilerplate disclosure that the company "is evaluating the impact" without any further detail, and without any indication of whether the impact is expected to be material, will draw SEC staff scrutiny given the amount of time that has passed.
What Does ASU 2025-06 Change About Software Capitalization Under ASC 350-40?
The existing ASC 350-40 framework divides internal-use software development into three project stages: the preliminary project stage (costs expensed), the application development stage (costs capitalised), and the post-implementation and operation stage (costs expensed). Transitioning from the preliminary to the application development stage triggers capitalisation, and the company's assessment of which stage a project is in determines when to start capitalising costs.
That three-stage model was developed in 1998 when software development followed a largely linear, waterfall methodology. Modern software development, including agile and iterative approaches where features are continuously added, tested, and revised, does not fit neatly into a linear stage model. The application development stage can be entered, exited, and re-entered within a single sprint cycle, making the stage-based capitalisation determination difficult to apply consistently.
ASU 2025-06 eliminates all references to project stages in ASC 350-40. The stage-based model is gone entirely. In its place, the ASU establishes a principles-based, two-condition capitalisation framework:
Condition 1: Management has authorised and committed to funding the software project.
Condition 2: It is probable that the project will be completed and the software will be used to perform the function intended. This is the probable-to-complete recognition threshold.
Both conditions must be met before capitalisation begins. All internal and external costs incurred before both conditions are met must be expensed as incurred.
The ASU also explicitly links the term "probable" to the ASC Master Glossary definition. Under the Master Glossary, probable means the future event or events are likely to occur. This is generally interpreted as a greater-than-70% likelihood threshold, which is more demanding than the informal "reasonably expected" interpretation that had been applied under SOP 98-1.
The key addition: in evaluating whether the probable-to-complete threshold is met, the entity must assess whether there is significant uncertainty associated with the development activities of the software. That assessment is the new, substantive gating concept.
What Is the "Probable-to-Complete" Recognition Threshold?
The probable-to-complete recognition threshold is the second of the two conditions required for capitalisation under ASU 2025-06. It requires management to assess whether it is probable that the software project will be completed and the software used to perform the function intended.
The KPMG analysis confirms that the ASU's amendments explicitly link the term "probable" to the ASC Master Glossary definition, which means the future event is likely to occur, generally interpreted as a threshold higher than mere possibility or reasonable expectation.
Two components of the probable-to-complete assessment are new relative to prior guidance:
First, the assessment must specifically consider whether significant development uncertainty exists. If significant development uncertainty is present, the probable-to-complete threshold is not met, regardless of whether management has authorised the project and has high confidence it will eventually be completed.
Second, the threshold must be assessed at the individual software project level. The Deloitte Heads Up confirms that an entity should use its judgment in determining what represents a software project within the context of ASC 350-40, and the FASB explicitly chose not to define the unit of account to avoid limiting judgment. This means that a large technology product with multiple components may be assessed at the feature level, the module level, or the product level depending on how the entity defines its software projects.
The probable-to-complete threshold can be met before the entire project is complete. Once significant development uncertainty is resolved for a specific software project or component, capitalisation begins for eligible costs incurred after that resolution, even if other portions of the same product are still in early development.
This feature, capitalisation once uncertainty resolves rather than waiting for the entire project to be complete, is the mechanism that makes the new framework workable for iterative development. But it also means that companies must document the specific date on which significant development uncertainty was resolved for each component they are capitalising, which requires more granular tracking than the prior stage-based model.
What Is "Significant Development Uncertainty" and Why Does It Change Everything for AI Software?
Significant development uncertainty is present if either of the following two conditions is met:
The software being developed has technological innovations or novel, unique, or unproven functions or features, and the uncertainty related to those innovations, functions, or features 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 in the ASU as "what the entity needs the software to do (for example, functions or features)."
Both conditions must be absent before capitalisation can begin. Either one, standing alone, is sufficient to establish significant development uncertainty and block capitalisation.
The Deloitte Heads Up illustrative example involving Entity Y building an AI-powered accounting tool is the most useful worked example in the current guidance. The tool has two components: an "extract" functionality using off-the-shelf technology with no development uncertainty, and a "write" functionality using a novel LLM-based approach to generate accounting outputs with significant development uncertainty. Entity Y can capitalise costs for the extract component immediately once the probable-to-complete threshold is met for that component, but cannot capitalise costs for the write component until the significant development uncertainty is resolved through coding and testing of the LLM-based functionality.
The specific phrase "resolved through coding and testing" is the operative standard. Resolution of significant development uncertainty is not established by:
Management's decision to proceed with a project.
The selection of a technology stack or vendor.
The completion of design documents or proof-of-concept work.
Resolution requires that the novel or unproven functionality has been demonstrated to work through actual coding and testing of the software itself. For LLM-based software, this means demonstrating through testing that the model can perform the specific functions the software is intended to perform, to the performance specifications that have been identified, at a level of accuracy and reliability sufficient to confirm the software will be used for its intended purpose.
Why AI and LLM-Based Software Development Will Be Most Affected by the New Standard
The significant development uncertainty concept intersects with AI and LLM-based software in a way that materially delays capitalisation for most current AI software development activities.
Three features of AI and LLM-based development characterise it as a high-significant-development-uncertainty category.
First, novel functionality is inherent to AI software. A company building a new LLM-based product, whether for customer service, code generation, financial analysis, or any other application, is by definition working with novel and unproven functionality. The outcome of LLM-based development is not deterministic in the way that traditional software development is: you cannot be certain that a given prompt strategy, fine-tuning approach, or retrieval-augmented generation architecture will produce the output quality the software requires. That uncertainty is not resolved until coding and testing demonstrate that it can.
Second, performance requirements for AI software are frequently not fully identified at the outset and are substantially revised during development. The specific accuracy thresholds, latency requirements, hallucination rates, and contextual relevance criteria that define whether an LLM-based product performs as intended are often discovered during the development process rather than specified in advance. Under ASU 2025-06, a project whose performance requirements are not fully identified or are substantially revised is in significant development uncertainty until both conditions are resolved.
Third, the iterative nature of model training means that even testing does not always resolve uncertainty immediately. A company may train a model, test it, discover that it fails a performance requirement, revise the training approach, and test again across multiple cycles before confirming resolution. The significant development uncertainty may not be resolved until well into what would previously have been called the application development stage.
The example from ASU 2025-06's Basis for Conclusions confirms this: in FASB's illustrative example of a truly novel AI module, management committed to the project on July 1, Year 1, but significant development uncertainty was not resolved until April 1, Year 3, after nearly two years of development work. All development costs incurred from July 1, Year 1, through March 31, Year 3, would be expensed under the new standard, even though they would likely have been capitalised under the prior stage-based model once the application development stage was entered.
What Are the Three Categories of AI Software Cost Impacted: Training, Fine-Tuning, and Inference
For AI and LLM-based software specifically, the ASU 2025-06 framework applies differently to three distinct cost categories that companies currently treat inconsistently.
Training costs are the costs of training the foundational model on data, whether from scratch or using a pre-trained base model. Under the current stage-based model, some companies capitalise training costs that occur during the application development stage. Under ASU 2025-06, training costs incurred before significant development uncertainty is resolved are expensed. Training costs incurred after resolution, specifically training necessary to establish that the software can perform its intended function at the performance specifications that have been identified, may be capitalised. But training costs that are part of the process of resolving the uncertainty (i.e., training that is performed to determine whether the approach will work) are incurred before resolution and must be expensed.
Fine-tuning costs are the costs of adapting a pre-trained model to a specific task or domain. Fine-tuning is often treated as clearly within the application development stage under current guidance, on the theory that the model architecture has already been proven and fine-tuning simply adjusts it for the specific application. Under ASU 2025-06, the question is not whether the model architecture is proven but whether the specific fine-tuning approach for the specific application is novel and unproven. If the fine-tuning methodology is standard and the company has applied it successfully in comparable prior projects, significant development uncertainty may not exist and capitalisation may begin earlier. If the fine-tuning is novel or the performance requirements for the fine-tuned model have not been identified, significant development uncertainty applies and costs must be expensed.
Inference infrastructure costs are the costs of the compute infrastructure used to serve model outputs to end users. These costs do not involve software development in the traditional sense and are generally not capitalised under current ASC 350-40. Under ASU 2025-06, the treatment of inference infrastructure costs depends on whether they constitute capitalizable internal-use software development costs or operational costs. The KPMG February 2026 software costs handbook is the most current reference for the detailed application of the new framework to AI infrastructure costs.
What Does Your Q2 2026 10-Q SAB 74 Disclosure Need to Quantify or Describe?
The SAB 74 disclosure in the Q2 2026 10-Q must be calibrated to the current state of the company's impact assessment. The SEC staff expects the disclosure to become more specific as the mandatory adoption date approaches and as the company completes its analysis.
For Q2 2026, approximately 16 months after ASU 2025-06 was issued and approximately 18 months before the mandatory adoption date, a company with material capitalised software development costs should have progressed its assessment sufficiently to address at least the following elements.
The identification of the standard. The disclosure must identify ASU 2025-06 by name, describe its key changes (elimination of three-stage model, introduction of probable-to-complete threshold and significant development uncertainty concept), and state its mandatory effective date (annual periods beginning after December 15, 2027, with early adoption permitted).
The assessment status. The disclosure must honestly characterise the current state of the assessment. If the company has completed a preliminary assessment, the disclosure should describe the areas of the software development portfolio most likely to be affected and the direction of the expected impact (more costs expensed, less capitalised). If the assessment is still ongoing, the disclosure should explain why and when the company expects to complete it.
The materiality assessment. Where the preliminary assessment indicates the standard will have a material impact, the disclosure should say so explicitly. FASB's explicit expectation that more costs will be expensed is a basis for a company to state that ASU 2025-06 is expected to have a material impact on its capitalised software balance and its reported R&D or software development expense, pending the completion of the detailed quantitative assessment.
The quantitative estimate. For companies that have been able to identify specific software projects or components likely to be affected by the significant development uncertainty concept, a range estimate of the expected change in capitalised software balance is more useful to investors than a generic statement. Not every company will be able to produce this in Q2 2026, but companies should be working toward it.
The transition approach. If the company has selected or is leaning toward a particular transition approach (prospective, modified prospective, or retrospective), that should be disclosed or at least identified as a decision in progress.
One specific disclosure that is required for AI companies where the significant development uncertainty analysis is genuinely complex: if the company has AI or LLM-based software development where the timing of capitalisation under the new framework cannot yet be determined because the resolution of significant development uncertainty is project-specific and depends on future testing outcomes, that should be described as the specific source of measurement uncertainty. Investors in technology companies with large AI development programmes need to understand that the impact estimate is not simply a calculation of capitalised costs that will now be expensed, but depends on project-by-project determinations of when significant development uncertainty is resolved.
What Did the FASB Explicitly Expect: More Costs Expensed, Not Fewer
This point from the FASB's Basis for Conclusions deserves emphasis because it provides the most direct basis for a SAB 74 disclosure that the standard will have a material impact.
FASB explicitly expected that the ASU would result in more software development costs being expensed rather than capitalised, particularly for AI-driven and agile development projects. The KPMG analysis confirms this directly: the additional considerations around significant development uncertainty may result in entities expensing significant portions of their SaaS software development costs if they conclude that significant development uncertainty exists until relatively late in the development process.
The FASB's rationale for the delayed effective date, addressed in the Basis for Conclusions paragraphs BC108 through BC110, specifically acknowledged that the significant development uncertainty concept would require companies to undertake substantial analysis of their existing software development projects and that the transition from a stage-based model to a principles-based model would require significant changes to internal processes and controls. The delayed effective date was chosen to give companies sufficient time to prepare, not because the expected impact was small.
For SAB 74 disclosure purposes, the FASB's own published expectation that the standard will result in more costs being expensed is a direct basis for a company to describe the expected direction of impact in its disclosure, even before a quantitative estimate is available. A disclosure that characterises the expected impact as "under evaluation and could be significant, particularly for AI and LLM-based software development activities, given the FASB's stated expectation that significant development uncertainty will delay capitalisation for novel software products" is more informative and more defensible than a generic "evaluating the impact" statement.
How Does ASU 2025-06 Interact With ASU 2024-03 Expense Disaggregation Disclosures?
ASU 2024-03, Disaggregation of Income Statement Expenses, requires public business entities to disaggregate certain income statement expense line items, including the components of cost of goods sold and selling, general, and administrative expense, for annual periods beginning after December 15, 2026, and for interim periods within those annual periods beginning after December 15, 2027.
The intersection with ASU 2025-06 matters for companies that capitalise software development costs, because the adoption of ASU 2025-06 will shift certain costs from the balance sheet (as capitalised software) to the income statement (as R&D or software development expense). That shift will show up in the disaggregated expense disclosures required under ASU 2024-03.
For companies adopting ASU 2024-03 before ASU 2025-06, the initial disaggregated expense disclosures will reflect the capitalisation pattern under current ASC 350-40. When ASU 2025-06 is subsequently adopted, the disaggregated expense disclosure will show an increase in software development or R&D expense that represents the shift from capitalisation to expensing under the new probable-to-complete and significant development uncertainty framework. That change will be visible to investors and analysts who track the disaggregated expense disclosure, and it should be anticipated in the SAB 74 disclosure.
The Q2 2026 SAB 74 disclosure can address this interaction by noting that the adoption of ASU 2025-06 is expected to increase certain expense categories included in the disaggregated disclosures required by ASU 2024-03, and that the two standards' combined effect on reported expenses and capitalised assets will be assessed together as the company completes its impact analysis.
Frequently Asked Questions
What is ASU 2025-06?
FASB Accounting Standards Update 2025-06, issued September 18, 2025, modernises the internal-use software capitalisation guidance in ASC 350-40. It eliminates the three-stage project model (preliminary project stage, application development stage, post-implementation/operation stage) and replaces it with a two-condition framework: management authorisation and commitment to funding, and the probable-to-complete recognition threshold. The ASU introduces the significant development uncertainty concept as a blocking condition that prevents capitalisation until development uncertainty is resolved through coding and testing.
What is "significant development uncertainty" under ASU 2025-06?
Significant development uncertainty exists when either of the following conditions is present: the software has technological innovations or novel, unique, or unproven functions or features and the uncertainty has not been resolved through coding and testing, or the significant performance requirements of the software have not been identified or continue to be substantially revised. When significant development uncertainty exists, the probable-to-complete threshold is not met and capitalisation cannot begin, regardless of whether management has authorised the project.
Are AI model training costs capitalizable under ASU 2025-06?
Yes, but only after significant development uncertainty has been resolved. Training costs incurred as part of the process of resolving uncertainty (determining whether the AI approach will work) are expensed as incurred. Training costs incurred after resolution, specifically to establish that the software can perform its intended function at the identified performance specifications, may be capitalised. For LLM-based software where the novel functionality has not been confirmed through testing, training costs are expensed until resolution.
What SAB 74 disclosures are required for ASU 2025-06 in Q2 2026?
The Q2 2026 10-Q should identify ASU 2025-06, describe its key changes, state the mandatory effective date, characterise the current state of the impact assessment, describe the direction of the expected impact (more costs expensed for novel AI software), provide a quantitative estimate where possible, and discuss the transition approach being considered. Given the FASB's explicit expectation that the standard will result in more costs being expensed, particularly for AI and agile development projects, the disclosure should address why the impact is expected to be material for companies with significant software development activities.
When is ASU 2025-06 effective for public companies?
For all entities, including public business entities, ASU 2025-06 is effective for annual reporting periods beginning after December 15, 2027. For calendar-year companies, this is January 1, 2028. Early adoption is permitted as of the beginning of any annual reporting period. Three transition approaches are available: prospective, modified prospective (based on project status at adoption), and retrospective.
Key Takeaways
- ASU 2025-06 is mandatory for calendar-year public companies beginning January 1, 2028, but SAB 74 requires disclosure of its expected impact in Q2 2026 Form 10-Q filings now, for any company where the standard will have a material effect.
- The ASU eliminates the three-stage project model and introduces a two-condition capitalisation framework: management authorisation and the probable-to-complete recognition threshold. Significant development uncertainty, when present, prevents the probable-to-complete threshold from being met and blocks capitalisation entirely until resolved through coding and testing.
- Significant development uncertainty exists when the software has novel, unique, or unproven functions or features whose uncertainty has not been resolved through coding and testing, or when the significant performance requirements have not been identified or continue to be substantially revised.
- AI and LLM-based software development is the highest-impact category. Novel LLM functionality by definition involves technological innovation whose uncertainty may not be resolved until deep in the development cycle, potentially after years of development work that would be expensed rather than capitalised under the new standard.
- FASB explicitly expects more software development costs to be expensed under ASU 2025-06, particularly for SaaS and AI-driven development projects. That expectation is published in the Basis for Conclusions and is a direct basis for characterising the expected impact as material in the SAB 74 disclosure.
- The Q2 2026 SAB 74 disclosure must go beyond "evaluating the impact." It should describe the assessment status, the direction of expected impact, the specific types of software development affected, a quantitative estimate where possible, and the transition approach being considered.
- ASU 2025-06 interacts with ASU 2024-03 expense disaggregation. Costs shifted from capitalised software to the income statement will appear in the disaggregated expense disclosures required by ASU 2024-03, and that interaction should be addressed in the SAB 74 disclosure.
