ASC 350-40 Guide: A Practitioner's How-To Walkthrough (2026)

This is the how-to companion piece for controllers, technical accounting leads, and SOX owners who have to actually operate ASC 350-40 after ASU 2025-06, not just understand it. If you want the conceptual before-and-after comparison, start with our ASC 350-40 software capitalization guide covering ASU 2025-06. This one walks you through the work.

Key takeaway: The mechanics changed, not the audit scrutiny. Under the new ASC 350-40, you still have to defend a specific date, a specific project scope, and a specific set of costs. Build the evidence file as you go, not at year-end.

Who this ASC 350-40 guide is for

This walkthrough is written for the person who has to write the capitalization policy, train the engineering PMO, and sign the SOX narrative. If you are a controller at a mid-to-large filer with an internal software function, an agile roadmap, or an AI/ML initiative, and you are staring at ASU 2025-06 wondering what changes on Monday morning, this is for you. Everyone else, including auditors reviewing your file, will still find the sequencing useful.

The guide assumes you already know the basics: ASC 350-40 governs internal-use software and, since ASU 2018-15, the implementation costs of cloud computing arrangements (CCAs) that are service contracts. What is new is that in September 2025 the FASB issued ASU 2025-06, Targeted Improvements to the Accounting for Internal-Use Software, the first major update to this guidance in more than two decades.

The 8-step ASC 350-40 practitioner walkthrough

Use this as your operating checklist for any internal-use software or CCA project. Steps 1 through 3 are policy work you do once. Steps 4 through 8 you repeat for every project.

1. Confirm scope: internal-use software vs. external-use vs. CCA implementation.
2. Pick a transition method for ASU 2025-06 and set the adoption date.
3. Rewrite the capitalization policy around the two new triggers plus the novel-tech carve-out.
4. Define the unit of account for each project (single project vs. separable functionalities).
5. Document the capitalization start date with evidence for each trigger.
6. Track costs at the sprint or work-item level, split into capitalizable vs. expense buckets.
7. Set useful life, start amortization, and monitor for impairment or abandonment.
8. Draft the disclosures under ASC 360-10, plus the ASU 2025-06 transition disclosures.

Step 1: Confirm you are actually in ASC 350-40

Before capitalizing a dollar, pin down which codification subtopic governs the arrangement. Getting this wrong is the most common scoping error and the easiest to prevent.

Use this quick decision matrix:

The CCA-vs-license question turns on two tests from ASC 350-40: can the customer take possession of the software without significant penalty, and can the customer run it themselves or via a third party? Two yeses point to a software license; otherwise it is a service contract with implementation costs. Crowe walks through the same test.

ASU 2025-06 also formally superseded ASC 350-50 and folded website development into ASC 350-40, so websites now run through the same triggers as any other internal-use build, per Grant Thornton's summary.

Step 2: Pick your ASU 2025-06 transition method

All entities must adopt ASU 2025-06 for annual periods beginning after December 15, 2027, with early adoption permitted. You have three transition methods, and the choice moves real P&L.

A practical read: if you have material capitalized balances tied to AI or agile projects that would fail the new probable-to-complete threshold, prospective can leave you carrying an asset your successor policy would not have created, while modified prospective forces the write-down but resets the base. Model both before you decide. See the Deloitte Heads Up on ASU 2025-06 for the mechanics.

Step 3: Rewrite your capitalization policy around the new triggers

Under ASU 2025-06, capitalization begins when both of the new triggers in ASC 350-40-25-12 are met, subject to the novel-tech carve-out in ASC 350-40-25-12A. Your old policy, written around the preliminary project / application development / post-implementation stages, will not survive an audit review.

The two triggers, quoted from the amended standard:

1. "Management, with the relevant authority, implicitly or explicitly authorizes and commits to funding a computer software project."
2. "It is probable that the project will be completed and the software will be used to perform the function intended (referred to as the 'probable-to-complete recognition threshold')."

And the carve-out that catches most AI/ML work:

"The software being developed has technological innovations or novel, unique, or unproven functions or features, and the uncertainty related to those technological innovations, functions, or features, if identified, has not been resolved through coding and testing."

Your rewritten policy needs to spell out, in operational terms:

• Who has "relevant authority" to authorize a project (name the role, e.g., VP Engineering plus CFO sign-off above $X).
• What form the authorization takes (approved business case, funded Jira epic, signed statement of work).
• What evidence proves the probable-to-complete threshold is met (architectural design signed off, dependencies resolved, no unresolved technical spikes).
• What constitutes "novel, unique, or unproven" for your business, and what proof you require that development uncertainty is resolved (working prototype, successful integration test, model accuracy above a defined benchmark).
• What derails capitalization (major re-scoping, cancellation, indefinite pause), and the process to stop capitalizing and test the balance for impairment.

BDO notes the standard "introduces new areas of judgment," and the FASB itself expects more costs to be expensed than under the legacy model, per the BDO ASU 2025-06 alert. Bake that expectation into your policy so finance is not surprised when engineering pushes back.

Step 4: Define the unit of account before you start tracking costs

For each project, decide up front whether it is one project or several separable projects, because that decision drives when capitalization starts for each piece. This is Deloitte's "View A vs View B" question in its Entity Y illustration.

Apply this test:

• One unit of account (View A): The functionalities were funded together and one cannot be delivered without the other, so you assess the probable-to-complete threshold across the whole project. Nothing capitalizes until the entire scope clears the bar.
• Separate units of account (View B): Each functionality could be delivered independently and provides standalone value. You assess and capitalize each separately, so a lower-risk module can start capitalizing while an AI-heavy module is still in the uncertainty zone.

In the Deloitte Entity Y example, an AI tool with "extract" and "write" functionalities came out differently under each view: under View A no costs capitalized until the AI uncertainty resolved on September 30, 20X0, but under View B the extract functionality began capitalizing on January 15, 20X0 while the write functionality waited until September 30. The Deloitte Heads Up is worth reading in full for the fact pattern.

Document your unit-of-account conclusion in the project charter. Auditors will ask.

Step 5: Document the capitalization start date

For every project, the file needs a dated memo that names the day capitalization started and points to the evidence for each trigger. No memo, no capitalization. That is the practical audit standard.

A workable template:

• Project name and unit of account.
• Trigger 1: Authorization and funding. Approver, date, funding amount, artifact (e.g., "CFO approved $2.4M funding on 2026-03-15 via Steerco minutes").
• Trigger 2: Probable-to-complete. Evidence the project will be completed and used as intended (technical design sign-off, dependency review, resource commitments).
• ASC 350-40-25-12A assessment. Does the project involve novel, unique, or unproven functionality? If yes, describe the specific uncertainty, how it will be resolved through coding and testing, and the milestone that will demonstrate resolution.
• Performance requirements. Confirm significant performance requirements have been identified and are not being substantially revised.
• Capitalization start date. The later of the dates that all applicable criteria are met.

For AI/ML projects, be especially explicit about what counts as "resolved through coding and testing." A model that hits a defined accuracy threshold on a held-out test set is defensible; a hopeful launch date is not.

Step 6: Track costs at the sprint level, in two buckets

Your time-tracking and PMO tooling has to split effort into capitalizable vs. expense at a granularity fine enough that an auditor can tie any dollar back to a work item. For agile shops, that usually means at the sprint or story level, not the quarter.

What goes in each bucket:

Capitalize (once triggers are met):

• Direct payroll and benefits for developers, designers, and QA on capitalizable work items
• External contractor costs for coding, configuration, and testing
• Software licenses and cloud infrastructure consumed to build the software
• For CCA implementations: configuration, coding, integration, and data conversion essential to functionality
• For AI projects post-threshold: model training data costs necessary to establish the model can perform to design specifications, per the Deloitte Entity Y illustration

Expense as incurred:

• Research, exploration, and proof-of-concept work before triggers are met
• Training end users
• Data conversion that is not essential to functionality
• Ongoing maintenance, bug fixes, and minor enhancements post go-live
• Ongoing SaaS subscription fees (only implementation costs capitalize)
• General overhead and administration

What this means in practice: engineering leads tag each Jira story with a project code and a cap/expense flag when it enters a sprint. Finance reconciles time-tracking hours against the flags monthly. If you are not doing this today, it is the single biggest operational change ASU 2025-06 forces.

Step 7: Set useful life, amortize, and watch for impairment

Once the software is ready for its intended use, start straight-line amortization over the estimated useful life, and monitor for impairment or abandonment under ASC 360. ASU 2025-06 confirms that capitalized internal-use software follows the property, plant, and equipment disclosure model in ASC 360-10, not the general intangible model in ASC 350-30.

Operating rules:

• Useful life: Base it on how long the software will produce cash flows. Consider rate of obsolescence, planned upgrades, and the underlying technology's shelf life. For enterprise systems, 3 to 7 years is common; document the basis.
• Amortization start: When the software (or the discrete module, if separable) is ready for its intended use, not when the whole program goes live.
• Impairment triggers: Significant scope changes, a decision to shelve or replace the software, a shift in strategy that reduces expected use, or cost overruns that make continued development uneconomic.
• Abandonment: Write off the remaining net book value immediately when the project is cancelled or the software is retired.

For CCA implementation costs, amortize over the term of the hosting arrangement, including reasonably certain renewals.

Step 8: Get the disclosures right

Under ASU 2025-06, apply the ASC 360-10 PP&E disclosure requirements to all capitalized internal-use software and related amortization, regardless of where it sits on the balance sheet. You do not need the ASC 350-30 general intangibles disclosures for internal-use software.

For the ASU 2025-06 change in accounting principle, disclose per ASC 250-10-50-1(a):

• Nature of and reason for the change (both interim and annual, in the period of adoption)
• Method of applying the change (prospective, modified prospective, or retrospective)
• If modified prospective or retrospective: the cumulative effect on opening retained earnings
• If retrospective: the effect on prior-period line items

Read the specifics in the Grant Thornton snapshot on ASU 2025-06.

Common pitfalls and how to avoid them

A short list of the mistakes that show up in audit findings and SEC comment letters on software costs. Design your process to head them off.

• Treating "CEO approved the project" as sufficient by itself. Authorization is trigger 1 of 2. You still need probable-to-complete, and for AI projects you still need the ASC 350-40-25-12A hurdle. In the Deloitte Entity Y fact pattern, CEO approval on January 15, 20X0 did not start the clock; September 30, 20X0 did.
• Capitalizing AI model training costs before the technology uncertainty is resolved. Under ASC 350-40-25-12A, training costs before the coding-and-testing hurdle is cleared are expensed. After, training costs needed to prove the model meets design specifications capitalize.
• Bundling separable functionalities into one unit of account (or vice versa) to get a preferred answer. The unit-of-account call has to reflect how the work was actually funded and how the pieces deliver value, not the accounting outcome you want.
• Continuing to capitalize on a paused or re-scoped project. If significant performance requirements are being substantially revised, the probable-to-complete threshold is no longer met. Stop capitalizing and reassess.
• Missing the ASC 985-20 vs ASC 350-40 line for hybrid products. Deloitte itself notes the ASU "does not fully align the framework for accounting for internally developed software costs" with ASC 985-20. If the software will be sold or licensed externally, you are in ASC 985-20 and "technological feasibility" is still the trigger.
• Forgetting the SOX implications. New triggers mean new controls. Your control over software capitalization needs to test that authorization exists, that the probable-to-complete assessment was performed and documented, and that cost tracking reconciles to sprint-level evidence. If your SOX narrative still references the three project stages, it is stale.
• Under-disclosing the transition. ASC 250 disclosures are the first place a reviewer will look for evidence you actually adopted the standard.

Cloud computing arrangements: how ASC 350-40-15 fits in

For a CCA that is a service contract, ASC 350-40-15 (the ASU 2018-15 guidance) still governs implementation cost capitalization, and it interacts with the new triggers rather than replacing them. The general principle: capitalizable implementation costs on a service-contract CCA follow the same recognition logic as internal-use software.

Practical steps for a CCA:

1. Classify: Is this a software license (asset on your books) or a service contract (subscription expensed, implementation costs potentially capitalized)?
2. If a service contract: Identify implementation costs that would be capitalizable if you were building the software internally: configuration, integration, coding, essential data conversion, testing.
3. Apply the new triggers to those implementation costs: authorization, probable-to-complete, and the novel-tech carve-out if you are, say, custom-configuring an AI SaaS product.
4. Amortize capitalized implementation costs over the hosting term, including reasonably certain renewals.
5. Expense subscription fees, training, non-essential data conversion, and ongoing support.

Zenskar summarizes the practical treatment in its CCA accounting explainer, but the recognition thresholds now trace back to the amended ASC 350-40-25-12.

ASC 350-40 vs ASC 985-20: quick differentiator

Post-ASU 2025-06, KPMG notes the two models are "more closely aligned" but not identical, per the KPMG Handbook: Software and website costs. You still need to place each project in the right subtopic.

FAQ

When is ASU 2025-06 effective for ASC 350-40?

All entities are required to adopt for annual reporting periods beginning after December 15, 2027, and interim periods within those annual periods. Early adoption is permitted in an interim or annual period if the financial statements have not yet been issued.

Does ASC 350-40 still have a "preliminary project stage"?

No. ASU 2025-06 removed all references to project stages. Recognition is now driven by the two new triggers in ASC 350-40-25-12 plus the novel-tech carve-out in ASC 350-40-25-12A. If your capitalization policy still cites the three stages, it is out of date.

Can we capitalize AI model training data costs under ASC 350-40?

Once the probable-to-complete threshold is met (which for novel AI features requires that development uncertainty be resolved through coding and testing per ASC 350-40-25-12A), training data costs necessary to establish that the model can perform to design specifications are capitalizable. Costs incurred before that point are expensed.

Do we have to restate prior periods when we adopt ASU 2025-06?

Only if you elect the full retrospective transition method. The prospective and modified prospective methods do not restate comparative periods; the modified prospective method uses a cumulative-effect adjustment to opening retained earnings at adoption.

Does ASC 350-40 apply to SaaS subscription fees we pay?

Ongoing SaaS subscription fees are expensed. Implementation costs for a service-contract CCA (configuration, integration, essential data conversion) fall under ASC 350-40-15 and can be capitalized if they meet the recognition criteria, then amortized over the hosting term.

How is capitalized internal-use software disclosed under ASU 2025-06?

Apply the ASC 360-10 property, plant, and equipment disclosure requirements to all capitalized internal-use software and related amortization, regardless of financial statement presentation. The ASC 350-30 general intangibles disclosures are not required for internal-use software.

What is the difference between ASC 350-40 and ASC 985-20?

ASC 350-40 governs software for internal use, including SaaS you host for customers. ASC 985-20 governs software you sell, lease, or market as a product. The trigger for capitalization differs: ASC 350-40 uses authorization plus probable-to-complete (post-ASU 2025-06), while ASC 985-20 still uses technological feasibility. ASU 2025-06 did not change ASC 985-20.