ASC 350-40 Internal-Use Software Capitalization: The 2026 Guide, Including ASU 2025-06

Under the old model, the question was which stage your software project was in. Under ASU 2025-06, the question is how much of the project is still unproven.

That shift changes when a company starts capitalizing internal-use software costs, and it lands for annual periods beginning after December 15, 2027. Until then, FASB ASC 350-40 still runs on the three-stage model, so most teams need to work with both.

The short version: capitalize once it's proven. When nothing in the project is novel or unsettled, funding approval is the only gate.

This guide covers ASC 350-40 as it stands today and as ASU 2025-06 changes it. You get the recognition rules, a before and after comparison with the effective dates, and a worked example for a SaaS company, with the journal entries and the point where amortization starts. It's written by Zack Larsen, CPA, Gaapio's cofounder and CEO, with the Gaapio team of CPAs, who build technical accounting software for judgment calls like this one.

Key takeaway: ASC 350-40 tells you which costs of internal-use software to capitalize and which to expense. Today, capitalization starts when the preliminary project stage ends, management commits funding, and completion is probable. ASU 2025-06 removes the stages. Under the update, you start capitalizing when management has authorized and committed to funding the project and it is probable the project will be completed and the software used as intended, which means significant development uncertainty has to be resolved first. The update is effective for annual periods beginning after December 15, 2027, with early adoption permitted.

This guide is general information about US GAAP, not accounting or legal advice. The FASB Accounting Standards Codification is the authoritative text, so check it and your auditor against your own facts.

What is ASC 350-40?

ASC 350-40 is the FASB Codification subtopic on internal-use software, part of Topic 350, Intangibles: Goodwill and Other. It sets the rules for which costs of developing or obtaining software for your own use go on the balance sheet, and which go through the income statement.

The guidance has three jobs. It decides when capitalization starts, which costs qualify, and when amortization begins.

It also covers upgrades and enhancements, and the implementation costs of cloud computing arrangements that are service contracts.

If you search for "capitalized software ASC," this is the subtopic you want, with one exception covered next. Software you plan to sell, lease, or market externally sits in ASC 985-20 instead.

Which software costs does ASC 350-40 cover?

ASC 350-40 covers software acquired or developed solely to meet your own internal needs, with no substantive plan to market it externally. That includes an ERP system, a finance platform, and a custom internal tool.

It also reaches a SaaS company's own hosted platform in the usual case. Customers access that software over the internet and don't have the right to take possession of it, so the vendor does not apply the software-for-sale guidance in ASC 985-20. The scoping question is whether a customer has the contractual right to take possession of the software at any time during the hosting period without significant penalty, and could feasibly run it on its own or a third party's hardware. ASC 985-20-15-5 sets out that test for the vendor, and it mirrors the customer-side test in ASC 350-40-15-4A.

ASC 985-20 follows a different rule. It requires development costs to be expensed until technological feasibility is established, which happens late in development, so little gets capitalized.

ASU 2025-06 leaves ASC 985-20 alone. It does move one other piece into ASC 350-40: the website development guidance in ASC 350-50 is superseded, and its recognition requirements relocate to ASC 350-40 (Deloitte, September 2025).

What is ASU 2025-06, and when does it take effect?

ASU 2025-06, Targeted Improvements to the Accounting for Internal-Use Software, was issued by FASB on September 18, 2025. It removes every reference to project stages from ASC 350-40 and adds guidance on when the existing probable-to-complete threshold is met.

FASB's stated reason is that software isn't always built in a straight line (Deloitte, September 2025). The stage model assumed a waterfall, and agile teams working in sprints had to force their projects into it.

Here are the dates that matter, checked against the ASU as quoted in Deloitte's September 2025 Heads Up:

• Issued: September 18, 2025 (Crowe reports the same date).
• Mandatory: annual reporting periods beginning after December 15, 2027, and interim periods within those annual periods. For a calendar-year company, that means annual periods beginning January 1, 2028, with the first interim period being the first quarter of 2028. RSM states the same effective date.
• Applies to: all entities. The effective date has no separate delay for private companies.
• Early adoption: permitted in an interim or annual period in which the financial statements haven't been issued or made available for issuance. Adopting in an interim period means adopting as of the beginning of the annual period that includes it.
• Transition: prospective, modified prospective, or retrospective, at your election.

What changes before and after ASU 2025-06?

The cost types, the amortization rules, and the end of capitalization stay largely the same. The recognition trigger changes, along with the website guidance and the disclosures.

Two caveats apply. FASB said in the Basis for Conclusions that it expects more costs to be expensed for software developed to be sold as a service in a cloud computing arrangement, because novel features and unsettled requirements show up more often there. And the ASU does not fully align ASC 350-40 with ASC 985-20, so the two thresholds can still differ (Deloitte, September 2025).

When do you start capitalizing under ASU 2025-06?

You start capitalizing when two conditions are both met. Management, with the relevant authority, authorizes and commits to funding a software project, either explicitly or implicitly. And it is probable the project will be completed and the software will be used to perform the function intended.

FASB calls the second condition the probable-to-complete recognition threshold. Those two conditions were already in ASC 350-40-25-12 before the ASU. What the update adds is a rule for judging the second one.

The threshold isn't met while significant development uncertainty exists (ASC 350-40-25-12A). Uncertainty exists if either of these is present:

• The software has technological innovations or novel, unique, or unproven functions or features, and the uncertainty about them hasn't been resolved through coding and testing.
• The significant performance requirements haven't been identified, or the identified requirements keep being substantially revised.

If either one is present, defer capitalization until it's resolved.

FASB also said some projects clear the bar without much analysis. An ERP implementation that uses a developed solution is the example the Board gave, and for that kind of project you may be able to conclude the threshold is met without evaluating development uncertainty.

What is a "software project," and why does it matter?

The unit of account decides which costs wait. The ASU doesn't define "software project," so you apply judgment and document it.

Deloitte's example runs both ways. A company funds an AI feature that has two parts, one built on proven technology and one on a novel approach. If it treats them as a single project, it capitalizes nothing until the novel part is proven. If it treats them as two projects, because the first part works without the second, it capitalizes the proven part from the funding date.

In that fact pattern Deloitte calls both views acceptable. The separate-project view depends on the first part being usable without the second.

Either way, the choice needs a written rationale.

A project can be a whole application, a major feature, or a set of functions, and the assessment happens at the level where the performance requirements are set.

Deloitte gives a purchased-software version too. An entity licenses a reputable vendor's off-the-shelf, on-premise reporting layer and pays the vendor, on a time-and-materials basis, to build an analytical feature that doesn't exist yet. Management will use the base layer even if the feature can't be built, so the entity treats them as two software projects. It capitalizes the base-layer license and eligible implementation costs, and expenses the feature's development costs until coding and testing resolve the uncertainty.

When is development uncertainty resolved?

It's resolved through coding and testing. A prototype that shows the novel feature working to your design specifications is the kind of evidence a reviewer will expect to see.

A hire, a signed vendor contract, or a funding approval doesn't resolve it. In Deloitte's example, the CEO approved funding in January, and hiring specialists and signing an LLM contract came in February. Capitalization of the novel feature still didn't start until coding and testing demonstrated it in September.

Deloitte's example also capitalizes the model training needed to show the AI feature works to its design specifications, once the uncertainty is resolved. Costs to acquire training data that has an alternative use can be a separate intangible asset under ASC 350-30.

Which software costs do you capitalize, and which do you expense?

Capitalize the direct costs of getting the software built or installed once you pass the recognition test.

Capitalize (ASC 350-40-30-1):

• External direct costs of materials and services used in developing or obtaining the software, such as contractor fees and third-party licenses.
• Payroll and payroll-related costs for employees who are directly associated with the project and spend time on it, to the extent of that time.
• Interest costs incurred while developing the software (ASC 835-20).

Expense as incurred:

• General and administrative costs and overhead.
• Training.
• Data conversion, other than software costs to build or buy conversion tools.
• Maintenance and routine bug fixes after the software is ready for use.
• Preliminary work and anything that fails the recognition test.

Upgrades and enhancements follow their own rule. Capitalize them only when it is probable they will add functionality. The upgrade is then assessed as its own software project under the same recognition test (see ASC 350-40-25-17A through 25-17E, as amended by ASU 2025-06).

When does amortization start, and how do you amortize internal-use software?

Amortization starts when the software is substantially complete and ready for its intended use. That's after all substantial testing is complete, which is usually go-live. ASU 2025-06 doesn't change this.

For software rolled out in modules, amortize each module when it's ready for its intended use. If one module's function depends on another, start when both are ready.

Amortize on a straight-line basis over the software's estimated useful life, unless another systematic pattern better reflects how you consume the benefit. Support the useful life with facts, such as your release cadence and how quickly the technology changes. Three to five years is common, but your own evidence decides it.

Where you record the amortization is a policy choice. A SaaS company often puts the amortization of its hosted platform in cost of revenue.

Impairment follows ASC 350-40-35, which works through ASC 360-10. If it's no longer probable that a project will be completed and placed in service, report the costs at the lower of carrying amount or fair value less costs to sell. Uncompleted software carries a rebuttable presumption of no fair value.

What does a worked example of ASC 350-40 look like for a SaaS company?

Harbor Analytics, a fictional SaaS company, builds a usage-metering module for its hosted platform. All the figures are illustrative. We'll assume Harbor has adopted ASU 2025-06 and show the old model alongside, with Harbor's old policy capitalizing the prototype.

The project has two parts. The core metering engine runs on a proven cloud stack. A forecasting feature uses a modeling approach nobody at Harbor has built before. Harbor treats the two as separate software projects, because the core module can launch without the forecasting feature.

Here's the timeline:

• January and February: Discovery. Engineers and consultants define requirements and pick a vendor. Cost: $120,000.
• March 1: The CFO and CTO approve a budget and commit funding. The requirements for the core engine are settled, and the technology is proven.
• March through August, core engine: Payroll and payroll-related costs of $540,000, contractor fees of $210,000, and third-party software licenses for components built into the module of $30,000. Total: $780,000.
• March through May, forecasting feature: The team builds a prototype to find out whether the model works. Cost: $150,000.
• June 1: The prototype meets the design specifications in coding and testing. The novel part is no longer unproven.
• June through August, forecasting feature: $90,000 of build costs.
• Around go-live: $20,000 of user training and $35,000 of data conversion.
• September 1: Both parts go live. After go-live, $25,000 of maintenance through December.

How is each cost treated?

Expensed under both models: the $120,000 of discovery work, the $20,000 of training, the $35,000 of data conversion, and the $25,000 of post-launch maintenance.

Capitalized under both models: the $780,000 core engine, from March 1, and the $90,000 forecasting build from June 1.

Where the models split: the $150,000 spent on the forecasting prototype from March through May. Under ASU 2025-06, that's expensed, because significant development uncertainty existed until June 1. Under the old stage model, many would have treated a feasibility prototype as preliminary-stage work, which includes determining whether the needed technology exists, and expensed it. Some companies capitalized similar work once funding was approved. To show the largest possible difference, the comparison below assumes Harbor's old policy capitalized it. If Harbor had expensed it, the two models would produce the same numbers for this project.

What are the journal entries?

Each entry credits cash, accrued payroll, or accounts payable. We combine them into one line to keep the entries readable.

Discovery work, January and February, expensed:

Dr  Research and development expense      120,000
    Cr  Cash / accrued payroll / A/P                120,000

Core engine build, March through August, capitalized:

Dr  Software in development               780,000
    Cr  Cash / accrued payroll / A/P                780,000

Forecasting prototype, March through May, expensed under ASU 2025-06:

Dr  Research and development expense      150,000
    Cr  Cash / accrued payroll / A/P                150,000

Forecasting build, June through August, capitalized:

Dr  Software in development                90,000
    Cr  Cash / accrued payroll / A/P                 90,000

Training and data conversion, expensed:

Dr  Training expense                       20,000
Dr  Data conversion expense                35,000
    Cr  Cash / accrued payroll / A/P                 55,000

September 1, go-live, move the balance into service:

Dr  Internal-use software                 870,000
    Cr  Software in development                     870,000

September through December, amortization over an assumed five-year life ($870,000 / 60 months = $14,500 a month, four months):

Dr  Amortization expense                   58,000
    Cr  Accumulated amortization                     58,000

Post-launch maintenance, September through December, expensed:

Dr  Maintenance expense                    25,000
    Cr  Cash / accrued payroll / A/P                 25,000

Where does amortization start, and what is the year-one difference?

Amortization starts September 1, the day the software is ready for its intended use. Harbor assesses the useful lives of the two projects separately, and both come out at five years. The costs it expensed, including the prototype under ASU 2025-06, have nothing to amortize.

Harbor's $90,000 includes no model training or data acquisition.

Here is the year-one comparison between the two models:

The cash is the same under both models: $1,220,000.

The difference is timing. Under ASU 2025-06, Harbor capitalizes $150,000 less. Year-one expense is $140,000 higher ($150,000 expensed, less $10,000 of amortization avoided), and the net carrying amount at December 31 is $140,000 lower.

On the old model, the expensed line is the $120,000 of discovery plus $20,000 of training, $35,000 of data conversion, and $25,000 of maintenance, which is $200,000. Under ASU 2025-06, add the $150,000 prototype to get $350,000.

If Harbor had funded both parts as one software project, the core engine costs would also wait until June 1. That's why the unit-of-account call needs a memo.

How do cloud computing implementation costs fit in?

ASC 350-40 also governs the implementation costs of a cloud computing arrangement that is a service contract, such as the setup costs for a SaaS tool you subscribe to (ASU 2018-15). You capitalize eligible implementation costs and amortize them over the term of the hosting arrangement, including renewal periods you're reasonably certain to exercise, and you present the amortization in the same line as the hosting fees.

ASU 2025-06 removes the stage references from that model too. The recognition test is the same two conditions as above. For a configured off-the-shelf product, the conclusion is usually the same as before, because the technology is developed and proven.

Which transition method should you choose?

You choose one of three methods when you adopt ASU 2025-06. Each handles projects already in process differently.

• Prospective: Apply the new rules to costs incurred after adoption, including costs on projects already in process. Costs you capitalized earlier stay on the balance sheet, and you evaluate them for impairment. It's the least work, and you carry two models for a while.
• Modified prospective: Apply the new rules going forward. For an in-process project that met the old criteria but wouldn't meet the new ones, derecognize the capitalized costs through a cumulative-effect adjustment to opening retained earnings (or the relevant equity balance) at adoption.
• Retrospective: Recast the comparative periods, with a cumulative-effect adjustment at the start of the earliest period presented. It gives the most comparable statements and the most work.

Deloitte's Heads Up illustrates all three with a company that capitalized $2 million on a project with novel features that remain unproven at adoption. Prospective stops capitalizing and leaves the $2 million on the balance sheet. Modified prospective takes a $2 million cumulative-effect adjustment to opening retained earnings. Retrospective derecognizes the project as of the beginning of the earliest period presented and recasts the comparative periods, so costs capitalized in those periods move to expense.

The right choice depends on how much capitalized software is in process at adoption and which of those projects have unresolved uncertainty. Inventory the in-process projects before you pick.

Transition disclosures differ by method.

Prospective requires the nature of and reason for the change. Modified prospective adds the cumulative effect on retained earnings. Retrospective adds most of the ASC 250-10-50-1 change-in-principle disclosures, including the effects on prior periods presented (BDO).

What do you disclose for capitalized internal-use software?

Apply the ASC 360-10 property, plant, and equipment disclosures to capitalized internal-use software costs and the related amortization, regardless of how you present them on the balance sheet. ASC 350-30 intangible disclosures aren't required for these costs.

In practice, that means disclosing the balances by major class, the related accumulated amortization (by major class or in total), the amortization expense for the period, and a general description of the amortization methods. Many companies also disclose useful lives. Your auditor will look for that, along with a footnote that says what you capitalize and when amortization starts.

If you want the broader disclosure picture, see our footnote disclosures page.

How does Gaapio handle ASC 350-40 questions?

Gaapio is an AI-powered technical accounting platform built by CPAs. When a team brings a software capitalization question to Gaapio, it asks follow-up questions about the project facts before drafting. Those facts include what was funded, which parts are new, and whether the requirements are stable.

The draft is grounded in the licensed FASB Codification and Big 4 guidance, with citations you can click. Your reviewer approves it in Gaapio's review workflow, and it ends up as an accounting memo your auditor can follow. Your team still owns the judgment.

That documentation matters more under ASU 2025-06, because "significant development uncertainty" and the unit of account are judgment calls. They have to be written down when you make them. For the memo habits behind this, see why technical accounting memos matter, and our guide to a documentation process that stands up to audit.

Software capitalization also lives next to revenue. SaaS companies that capitalize their platform costs are usually applying ASC 606 to the contracts they sell on it. See what is revenue recognition for that side.

What should you do before ASU 2025-06 takes effect?

1. List every in-process and planned software project and the amount capitalized to date.
2. For each, document the unit of account and whether it has novel, unproven features or unsettled requirements.
3. Pick the earliest date you could adopt, and decide whether early adoption makes sense for your fiscal year.
4. Choose a transition method once you know how many projects would change.
5. Write the memo before the quarter closes, not after the auditor asks.

Want a second set of eyes on the memo? Request a demo and bring a real project.

Frequently asked questions

What is ASC 350-40?

ASC 350-40 is the FASB Codification subtopic that tells you which costs of internal-use software to capitalize and which to expense. It covers when capitalization starts, which costs qualify, how to amortize them, and how to treat upgrades and the implementation costs of cloud computing arrangements. Software to be sold, leased, or marketed externally falls under ASC 985-20 instead.

What is ASU 2025-06?

ASU 2025-06 is the FASB update that removes the project stages from ASC 350-40 and adds guidance on when the existing probable-to-complete threshold is met. FASB issued it on September 18, 2025. You start capitalizing when management has authorized and committed to funding the project and it is probable the project will be completed and the software used as intended, and the threshold isn't met while significant development uncertainty exists.

When is ASU 2025-06 effective?

ASU 2025-06 is effective for all entities for annual reporting periods beginning after December 15, 2027, and interim periods within those annual periods. For a calendar-year company, that's annual periods beginning January 1, 2028. Early adoption is permitted in an interim or annual period in which the financial statements haven't been issued or made available for issuance. An entity that adopts in an interim period adopts as of the beginning of that annual period.

What costs can you capitalize under ASC 350-40?

You can capitalize the external direct costs of materials and services used to develop or obtain the software, payroll and payroll-related costs of employees directly associated with the project, and interest costs. You expense general and administrative costs, overhead, training, data conversion (other than conversion software), and maintenance.

What are the three stages in ASC 350-40?

The current guidance has three stages: preliminary project, application development, and post-implementation. You expense preliminary-stage and post-implementation costs, and you capitalize application development costs once the recognition criteria are met. ASU 2025-06 removes the references to these stages for annual periods beginning after December 15, 2027, and earlier if you adopt early.

What is "significant development uncertainty"?

Significant development uncertainty is the condition that blocks capitalization under ASU 2025-06 (ASC 350-40-25-12A). It exists when the software has novel, unique, or unproven functions or features that coding and testing haven't resolved, or when the significant performance requirements haven't been identified or keep being substantially revised. You defer capitalization until it's resolved.

When does amortization start for internal-use software?

Amortization starts when the software is substantially complete and ready for its intended use, which is typically go-live. ASU 2025-06 doesn't change this. You amortize on a straight-line basis over the estimated useful life unless another systematic pattern better reflects use.

Can you capitalize SaaS implementation costs?

Yes, when the costs are implementation costs of a cloud computing arrangement that is a service contract and the recognition conditions are met. You amortize them over the hosting arrangement's term and present the amortization in the same line item as the hosting fees. This guidance came from ASU 2018-15, and ASU 2025-06 removes the stage references from it.

Do I need to restate prior periods when I adopt ASU 2025-06?

Only if you choose the retrospective method. Prospective and modified prospective adoption don't recast comparative periods. Modified prospective derecognizes in-process costs that no longer qualify through a cumulative-effect adjustment to opening retained earnings.

Where can I read the guidance?

The authoritative source is the FASB Accounting Standards Codification at ASC 350-40, plus ASU 2025-06 itself on fasb.org. Our citations to Deloitte, BDO, Crowe, and RSM are in the sources below. FASB's Basis for Conclusions is not authoritative guidance.

Related reading

• Why technical accounting memos matter
• Building an audit-ready documentation process
• FASB guidance library

Sources

• Deloitte, FASB Amends Guidance on the Accounting for and Disclosure of Software Costs (Heads Up, September 18, 2025)
• BDO, New ASU on Internal-Use Software Costs Guidance
• Crowe, FASB Revises Internal-Use Software Cost Guidance
• RSM, FASB modernizes the accounting for internal-use software costs
• FASB, ASU 2025-06, Targeted Improvements to the Accounting for Internal-Use Software (fasb.org)