Internal-Use Software Accounting Training: Build ASC 350-40 Competence for Agile, SaaS, and AI Development Costs

By Vincent Howard, CPA | Managing Partner, Howard, Howard and Hodges | SkillAbility for Accounting Firms

Last updated: September 8, 2026  |  41-minute read

What Is Internal-Use Software Accounting Training?

Internal-use software accounting training develops an accountant’s ability to determine the right software-cost model, establish when capitalization begins and ends, identify which costs are direct and eligible, and build an audit-ready bridge from engineering activity to the financial statements.

That definition matters because software accounting is no longer just developer payroll, a three-year useful life, and a spreadsheet labeled “capitalized software.” Modern projects can include continuous agile sprints, hosted SaaS products, customer-side cloud implementation, microservices and APIs, third-party coding platforms, AI coding agents, token-based model usage, fine-tuning and retraining data, cloud compute, continuous deployment, feature flags, and production experimentation.

This guide connects to AI Accounting Training, Fixed Asset Accounting Training, Workpaper Review Checklist, Scenario-Based Training for Accountants, and Accountants Shifting From Preparers to Reviewers.

Why ASC 350-40 Is Now a Workforce-Development Topic

I have practiced public accounting since 1990, founded my accounting firm in 1993, and helped grow Howard, Howard and Hodges from three people to approximately 50 staff. Since 2020, I have built SkillAbility around a recurring development problem: accountants are often asked to review software capitalization schedules without being trained to understand how product and engineering teams actually work.

Accounting hears: “The developers worked on Product X for 1,600 hours.”

But those hours may include feature ideation, architecture research, coding, testing, bug fixes, maintenance, production incidents, training, documentation, meetings, and AI experimentation. Under both the current and amended ASC 350-40 models, not all of those activities receive the same accounting.

What Changed in 2026? ASU 2025-06 and AI-Cost Guidance

Software-cost accounting has a genuinely important 2026 transition story.

In September 2025, the FASB issued ASU 2025-06, Targeted Improvements to the Accounting for Internal-Use Software—the first major update to ASC 350-40 in more than two decades.

KPMG’s February 2026 Software and Website Costs Handbook is a current implementation resource covering accounting both before and after adoption of ASU 2025-06, including AI software and data-cost issues.

Chart: Where Software-Cost Judgment Concentrates

SkillAbility training heat map—not a FASB ranking. Actual risk depends on product purpose, adoption date, development methodology, architecture, project granularity, hosted vs licensed delivery, AI usage, cloud arrangements, enhancement frequency, and quality of engineering/accounting controls.

The SOFTWARE READY Framework

S — Scope First: ASC 350-40 vs. ASC 985-20 vs. Other Topics

Software capitalization begins with scope, not with the cost ledger.

True internal-use software

ASC 350-40 applies to software used to meet the entity’s own internal needs, such as:

• ERP systems,
• accounting and financial-reporting platforms,
• inventory systems,
• workflow and approval applications,
• internal data platforms,
• internal AI assistants,
• operations or logistics software.

Hosted-only SaaS software can also be ASC 350-40 software for the provider

Software does not automatically become “external-use software” merely because customers benefit from it.

KPMG’s current software handbook explains that software can remain within ASC 350-40 when customers obtain access solely through a hosted arrangement and do not receive a substantive software license. Many cloud-native and generative-AI applications can fall into this model.

That means a SaaS provider developing its hosted platform may be applying ASC 350-40 to development costs.

Software sold or licensed to customers

ASC 985-20 generally applies when software is sold, leased, or otherwise marketed as software to third parties, including licensed software.

The capitalization threshold differs materially:

That is not the same timing model as ASC 350-40.

Other software can fall outside both models

Examples include:

• software created solely for a research-and-development activity → potentially ASC 730,
• software developed for a customer under a revenue contract → potentially ASC 340-40 contract-fulfillment guidance,
• embedded software whose accounting follows another asset model, depending on facts.

Scope questions staff should ask

• Who uses the software?
• Does the entity use it itself?
• Do customers receive a software license?
• Can customers take possession of the software?
• Is the software meaningful without continuous hosted functionality?
• Is the entity developing the software under a specific customer contract?
• Is the software itself used in R&D?
• Will the entity market or license the software externally?

F + T — Current Pre-Adoption ASC 350-40 Project-Stage Model

Unless an entity early adopts ASU 2025-06, the existing project-stage model continues to apply.

Stage 1: preliminary project stage

Costs are generally expensed as incurred.

Activities can include:

• conceptual formulation of alternatives,
• evaluation of alternatives,
• determining technology requirements,
• vendor or consultant demonstrations,
• final selection of alternatives before application development begins.

Stage 2: application development stage

Eligible direct costs are capitalized once all capitalization-start criteria have been met.

Qualifying activities commonly include:

• coding,
• configuration,
• installation,
• development of interfaces,
• development testing,
• direct employee time,
• direct third-party development services.

Stage 3: post-implementation-operation stage

Training and routine application maintenance are generally expensed as incurred.

Capitalization does not start merely because coding starts

Under the current model, capitalization generally begins only after:

1. the preliminary project stage is complete,
2. management with authority authorizes and commits to funding the project, and
3. it is probable the project will be completed and the software used to perform its intended function.

Capitalization stops at ready for intended use

Eligible development costs stop being capitalized when the software is substantially complete and ready for its intended use after substantial testing is complete.

Production support, maintenance, routine bug correction, training, and operating costs after that point generally belong in expense unless a later project qualifies as an upgrade or enhancement.

Post-ASU 2025-06: The New Probable-to-Complete Model

ASU 2025-06 eliminates the preliminary/application/post-implementation stage references from ASC 350-40’s recognition model.

After adoption, capitalization begins when both:

1. management has authorized and committed to funding the software project, and
2. it is probable the project will be completed and the software used to perform its intended function.

“Probable” means likely

The amended guidance explicitly links probable to the ASC Master Glossary concept.

The most important new operational question is:

If significant development uncertainty exists, the probable-to-complete threshold is not met until that uncertainty is resolved.

Factor 1: novel, unique, or unproven functions or technological innovations

Examples:

• an AI agent intended to autonomously execute a workflow the entity has never previously automated,
• a new real-time optimization engine using an unproven architecture,
• a software function dependent on unresolved technological innovation.

The uncertainty associated with novel or unproven features generally must be resolved through coding and testing that establishes the software can meet its performance requirements.

Factor 2: significant performance requirements are not determined or remain subject to substantial revision

Performance requirements describe what the software is expected to do.

If the product team still does not know what significant functionality must be delivered—or expects to substantially rewrite those requirements—the project may not yet meet the capitalization threshold under the amended model.

Why this matters for agile development

Agile methods often avoid one long upfront design phase.

Requirements may emerge sprint by sprint.

The amended guidance is designed to better align the accounting with that reality while still requiring management to determine when significant development uncertainty has actually been resolved.

Current vs. Post-ASU 2025-06: Side-by-Side

Adoption is an accounting-policy and controls project

Entities should not wait until 2028 to think about this.

Systems may need changes to capture:

• authorization dates,
• funding approval,
• significant performance requirements,
• novel/unproven functionality assessments,
• coding/testing milestones that resolve uncertainty,
• project-specific cost evidence.

The new model changes when capitalization can begin for some projects. It does not eliminate the need to prove what costs qualify.

W — Which Internal-Use Software Costs Capitalize vs. Expense?

Direct cost is not the same as allocated cost

A cost does not become capitalizable merely because management assigns it to a project code.

Examples of weak attribution:

• allocating enterprise AI subscriptions by engineering headcount,
• allocating shared cloud infrastructure by broad department percentages,
• capitalizing all CTO payroll because the CTO sponsors the project,
• allocating rent for the engineering floor.

Agile Development: Account for the Activity Inside the Sprint

Agile methods can create accounting complexity because one two-week sprint may contain both qualifying and nonqualifying work.

Example sprint

Sprint 18 includes:

• requirements refinement,
• technical spike to evaluate two architectures,
• production incident debugging,
• coding a new invoice-approval feature,
• automated development testing,
• user training materials.

Do not capitalize all Sprint 18 payroll simply because the sprint is assigned to a capital project.

Better accounting evidence

Use:

• epics,
• stories,
• tickets,
• repository / branch identifiers,
• pull requests,
• development environment tags,
• sprint objectives,
• employee time or allocation evidence,
• AI usage logs.

The control objective is to identify what work was actually performed.

Technical spikes

A technical spike used to research architecture alternatives may be preliminary/research activity rather than capitalizable development.

Under the amended model, a spike used to resolve whether a novel or unproven feature can satisfy its performance requirement may also be evidence that significant development uncertainty remains unresolved until testing demonstrates feasibility of the intended function.

Continuous deployment does not eliminate a ready-for-use date

A software team may deploy daily.

Accounting still needs to identify:

• the project or module being capitalized,
• when substantial development/testing is complete,
• when that module is ready for its intended use,
• when amortization begins.

A — Payroll, Contractors, Cloud Compute, and Direct Attribution

Internal payroll

Payroll and payroll-related costs can be capitalized for employees who are directly associated with and devote time to the qualifying internal-use software project—to the extent of qualifying time.

Examples:

• developer coding new functionality,
• engineer performing development testing,
• technical employee configuring a qualifying system.

Do not automatically capitalize:

• executive oversight,
• general project administration,
• routine status meetings,
• production support,
• training,
• general R&D or experimentation.

Third-party contracts

A vendor invoice may contain:

• configuration,
• custom coding,
• data conversion,
• training,
• project management,
• post-go-live support.

Accounting should allocate the contract to the underlying activities when necessary rather than capitalizing the contractual total.

Cloud compute

Shared infrastructure or IaaS capacity can behave like overhead when it supports multiple projects and activities.

Dedicated infrastructure obtained specifically and exclusively for a qualifying project can support a different conclusion.

The key is not that compute is measurable.

The key is whether the cost represents a direct resource consumed by the qualifying software project.

AI Coding Agents, Tokens, Subscriptions, and Usage Costs

Deloitte’s August 3, 2026 Technology Spotlight addresses a question accounting teams are now seeing in real software capitalization files:

AI can perform work historically performed by developers:

• planning,
• code generation,
• code review,
• testing,
• debugging,
• documentation,
• repository analysis,
• development-tool interaction.

The accounting follows the activity, project attribution, and capitalization period.

Token-based charges

A per-token or per-API charge is not automatically capitalizable simply because it is measurable.

Token usage can support capitalization when:

• the cost represents an external service consumed in developing the software,
• the service is directly attributable to an identified qualifying project,
• the activity is a qualifying development activity,
• the cost is incurred during an eligible capitalization period.

Fixed project-specific AI subscription

Assume a company purchases a six-month AI coding-agent subscription solely for Project Alpha.

Access is limited to the Alpha development team.

The tool is used only for:

• generating code,
• reviewing code,
• developing interfaces,
• development testing.

If the project is within its capitalization period, a fixed subscription can be a direct capitalizable development cost even though the billing does not vary with usage.

Enterprise-wide AI subscription

Now assume the same AI platform is available to:

• engineering,
• finance,
• marketing,
• operations.

Developers use it for coding, production support, research, documentation, meeting summaries, and general productivity.

Allocating the subscription fee to projects by developer headcount does not transform a broad stand-ready cost into a direct project cost.

That type of cost is generally more consistent with shared overhead and expense.

Mixed AI-agent session

An AI agent may in one session:

1. research a new architecture,
2. generate qualifying project code,
3. test the code,
4. investigate a production outage,
5. draft training material.

If reliable logs and project records let the entity distinguish the qualifying usage, that portion may be capitalized.

If there is no supportable basis to separate qualifying from nonqualifying usage, capitalization of the combined cost may not be appropriate.

Committed-consumption arrangements

A minimum commitment is not the same as a prepaid pool of discrete units merely because the contract refers to tokens or credits.

Ask:

• Will the company pay the same amount regardless of actual consumption?
• Is the capacity shared?
• Is the contract project-specific?
• Are the units expected to be substantially consumed?
• Can cost be measured as actual direct service consumption rather than a broad allocation?

AI Training and Retraining Data Costs

KPMG’s February 2026 Hot Topic on software data costs highlights why AI data cannot be handled with one blanket rule.

First ask: what software model applies?

AI software can be:

• internal-use software under ASC 350-40,
• external-use software under ASC 985-20,
• software used in R&D,
• software developed under a customer contract.

The data-cost conclusion changes with that scope.

Licensed data with no other use for a specific internal-use AI project

Under KPMG’s current interpretation, timing matters:

• cost incurred before ASC 350-40 capitalization criteria are met → expense,
• cost incurred after capitalization criteria are met and before software is ready for use → potentially capitalize as part of the internal-use AI software asset,
• cost incurred after ready for use → generally expense unless it qualifies as an upgrade/enhancement that adds functionality.

Licensed data with other uses

If licensed data has broader uses beyond one internal-use AI project, a separate intangible-asset analysis under ASC 350-30 may apply.

KPMG notes that amortization of a broadly usable data asset allocated to an internal-use software project generally does not become a direct ASC 350-40 project cost merely because finance allocates it to the project.

Retraining: enhancement or maintenance?

AI creates a particularly important post-go-live judgment.

Ask:

If retraining enables the software to perform an additional task it could not previously perform, it may be an upgrade or enhancement.

If retraining merely keeps the model relevant, current, accurate, or capable of performing the same task, the work is more consistent with maintenance and expense.

Example

An internal AI invoice-coding tool already:

• reads invoices,
• suggests GL accounts,
• flags duplicates.

Monthly retraining with new invoices to maintain coding accuracy is generally maintenance.

A separate project that trains the model to:

• identify contract renewal clauses,
• forecast cash-payment timing,
• automatically initiate an approval workflow,

may introduce additional functionality and should be evaluated as an upgrade/enhancement.

R — SaaS, Hosted Software, and Cloud Computing Arrangements

The word “SaaS” can describe two very different accounting perspectives.

Perspective 1: the SaaS provider develops hosted software

If customers access software only through the provider’s hosted environment and do not receive a substantive software license, the provider’s development costs can be within ASC 350-40.

That means a revenue-generating cloud platform can still be “internal-use software” for software-cost accounting purposes.

Perspective 2: the customer implements a SaaS product

The customer may have:

• a software license, or
• a hosting arrangement that is a service contract.

Those conclusions matter because the resulting assets, amortization presentation, and cash-flow classification differ.

Hosting arrangement as a service contract

If the customer does not obtain a software license under the applicable hosting guidance, the hosted software remains a service contract.

The customer does not record the hosted software itself as an intangible software asset.

However, ASC 350-40 applies to determine which implementation costs are deferred.

Customer Implementation Costs in a SaaS Service Contract

Implementation projects often contain a mixture of:

• configuration,
• customization,
• interface coding,
• data migration,
• training,
• business-process redesign,
• project management,
• hosting fees.

ASC 350-40 requires the entity to analyze the underlying implementation activities rather than capitalize every amount billed by the SaaS provider.

Typical treatment

The deferred implementation asset is not the same as owned software

Capitalized implementation costs of a hosting arrangement that is a service contract are generally characterized as a prepaid/service-contract-related asset rather than an internal-use software intangible asset.

That affects:

• balance-sheet classification,
• income-statement presentation,
• cash-flow classification,
• amortization period.

Amortization over the hosting arrangement term

Qualifying deferred implementation costs are generally amortized over the term of the hosting arrangement, including certain renewal or termination-option periods when the applicable criteria are met.

Amortization generally begins when the module or component is ready for its intended use.

Presentation

For a service-contract CCA, the amortization of deferred implementation costs is generally presented in the same income-statement line as the hosting service fees, and related cash flows follow the classification of the hosting arrangement fees.

E — Upgrades, Enhancements, Maintenance, and Model Retraining

After go-live, software development does not stop.

The accounting question becomes:

Upgrade or enhancement

ASC 350-40 defines an upgrade or enhancement around additional functionality: the software can perform a task it was previously incapable of performing.

Eligible development costs for a qualifying enhancement follow the same capitalization principles as new internal-use software.

Maintenance

Maintenance keeps existing functionality operating or current.

Examples:

• routine bug fixes,
• security patching,
• production support,
• routine compatibility updates,
• AI retraining that only maintains existing output quality.

Maintenance is expensed.

Efficiency improvement is not automatically new functionality

A change that makes software faster, cheaper, or more efficient does not necessarily add a new task.

The team should document:

• what the software could do before,
• what it can do after,
• whether a genuinely new capability exists.

Mixed maintenance and minor enhancements

If internal costs for maintenance and relatively minor upgrades/enhancements cannot be separated on a reasonably cost-effective basis, ASC 350-40 requires expense treatment.

That is another reason project-ticket discipline matters.

Website Development After ASU 2025-06

ASU 2025-06 eliminates ASC 350-50 as a separate Subtopic and moves relevant website-development guidance into ASC 350-40.

The update does not turn all website costs into software assets.

Entities still need to distinguish activities such as:

• software development,
• graphics/content,
• hosting,
• advertising/search-engine registration,
• operating-stage maintenance.

The new structure is designed to reduce artificial distinctions between website development and other modern software projects.

A simple website using proven templates may resolve development uncertainty earlier than a website containing novel real-time functionality or unproven AI features.

R — Ready for Intended Use, Amortization, and Useful Life

ASU 2025-06 did not change when capitalization ends.

Substantial testing

The accounting team should understand when substantial testing has been completed.

Evidence can include:

• user acceptance testing,
• production deployment approval,
• quality assurance signoff,
• security review,
• business owner acceptance,
• go-live documentation.

Modules and components

Large projects often roll out in phases.

One module can become ready for use while another remains under development.

The ready-for-use and amortization date should follow the economic functionality of the module/component rather than the final completion date of the entire transformation program.

Useful life

The useful life of internal-use software requires judgment based on factors such as:

• expected period of use,
• technology changes,
• planned replacement cycle,
• architecture dependencies,
• vendor support,
• competitive or operational obsolescence,
• expected enhancement cadence.

Amortization generally follows a systematic and rational pattern, commonly straight-line when no better pattern is evident.

SaaS implementation is different

Deferred implementation costs for a CCA service contract are amortized over the hosting arrangement term—not over the same useful-life analysis used for owned software.

E — Abandonment, Impairment, and Replacement

Software accounting controls should not stop after capitalization.

Warning signals

• project canceled before completion,
• module abandoned,
• technology replaced earlier than expected,
• vendor platform changed,
• business strategy shifted,
• AI model or architecture became obsolete,
• capitalized project will not provide expected service potential.

Abandoned in-process development

If a project or component will not be completed, capitalized costs may need to be written off depending on the facts and applicable guidance.

Existing software replaced by a new platform

The replacement plan can affect:

• remaining useful life,
• amortization period,
• impairment analysis,
• retirement date.

A clean project register should therefore identify both:

• new assets being developed, and
• existing software being retired.

Worked Example 1: Agile Internal-Use Software Project

Assume a company is building an internal financial-close platform.

It has not early adopted ASU 2025-06.

Management approved and funded the project on April 1, after the preliminary project stage was completed.

The software is expected to be completed and used as intended.

Costs incurred after April 1

Total identified cost = $1,200,000.

Total expense = $400,000.

What changes after early adoption of ASU 2025-06?

The activity treatment does not change.

But the start date can change.

Suppose on March 1 management had already approved funding, but the product team was still substantially revising the platform’s significant performance requirements and testing a novel AI close-orchestration feature.

Under the amended model, capitalization may not begin until that significant development uncertainty is resolved—even though funding was approved.

Worked Example 2: AI Credits Used Across Development and Maintenance

A company prepays $500,000 for 1,000,000 AI credits and expects to consume all of the credits.

During the month:

• 300,000 credits support qualifying code generation/testing for Project A,
• 150,000 credits support maintenance of existing software,
• 50,000 credits support general technical research,
• 500,000 credits remain unused.

Cost per credit = $0.50.

The key evidence is not the token count alone.

The company needs records linking credits to:

• Project A,
• qualifying development activities,
• the capitalization period.

Worked Example 3: SaaS Customer Implementation

A company signs a five-year hosted ERP service contract.

The arrangement is a cloud computing service contract; the customer does not obtain a software license.

Implementation costs

• Configuration/customization coding: $250,000
• Data migration: $70,000
• Training: $30,000
• Business process reengineering: $50,000

The remaining $150,000 is expensed under the applicable guidance.

Amortization

Assume the five-year hosting term is the appropriate amortization period and no other option-period adjustment is required.

The deferred implementation asset is presented as a service-contract-related asset, and the amortization is generally presented in the same income-statement line as the hosting service fee.

That presentation differs from an owned internal-use software intangible asset.

A Quarter-End Software Capitalization Workflow

Build one controlled software-cost register

Suggested fields:

• Project ID
• Project / module name
• Business owner
• Technical owner
• Software scope conclusion
• ASC 350-40 adoption model
• Management authorization date
• Funding commitment date
• Current-model preliminary-stage completion date
• Probable-to-complete date
• Significant performance requirements identified?
• Novel/unproven features?
• Development uncertainty resolution date
• Capitalization start date
• Capitalization end / ready-for-use date
• Module/component go-live date
• Payroll capitalized
• Third-party costs capitalized
• AI/token/compute costs capitalized
• Costs expensed
• SaaS / CCA classification
• Useful life / hosting term
• Amortization start
• Upgrade / enhancement status
• Abandonment / impairment status
• Reviewer

ASC 350-40 Self-Review Checklist Before Manager Review

• Did I determine whether the software is within ASC 350-40?
• Did I determine whether customers receive a software license?
• Did I determine whether hosted-only SaaS software is within ASC 350-40?
• Did I evaluate whether ASC 985-20 applies?
• Did I evaluate whether ASC 730 applies?
• Did I evaluate whether ASC 340-40 applies to customer-contract development?
• Did I document the intended use of the software?
• Did I identify the project, module, component, or enhancement unit being accounted for?
• Did I document whether the entity has adopted ASU 2025-06?
• If not adopted, did I apply the existing project-stage model?
• If adopted, did I avoid using project-stage labels as the recognition threshold?
• Did I document management authorization?
• Did I document commitment to fund the project?
• Under the current model, did I determine when the preliminary project stage ended?
• Under the current model, did I determine whether project completion/use was probable?
• Under the amended model, did I determine whether completion and intended use are probable?
• Did I assess significant development uncertainty under the amended model?
• Did I identify novel, unique, or unproven functions or technological innovations?
• Did I determine whether those novel/unproven features were resolved through coding and testing?
• Did I identify the software’s significant performance requirements?
• Did I determine whether those requirements remain subject to substantial revision?
• Did I document the date significant development uncertainty was resolved?
• Did I use the correct capitalization start date?
• Did I separate planning/research from qualifying development?
• Did I identify technical spikes and architecture evaluation work?
• Did I identify direct coding activity?
• Did I identify development testing?
• Did I identify configuration/customization work?
• Did I identify interface development?
• Did I identify installation activities?
• Did I identify data conversion and migration?
• Did I expense manual or outsourced data migration costs when required?
• Did I identify any separate software obtained for data conversion?
• Did I identify training activities?
• Did I expense employee training?
• Did I identify business-process reengineering?
• Did I expense business-process reengineering when applicable?
• Did I identify general administrative activities?
• Did I exclude general overhead from capitalization?
• Did I identify production-support activities?
• Did I identify routine maintenance?
• Did I identify post-go-live bug fixes?
• Did I distinguish post-go-live maintenance from new functionality?
• Did I identify direct employee payroll and payroll-related costs?
• Did I capitalize only qualifying employee time?
• Did I avoid capitalizing executive sponsorship or general management time without direct qualifying activity?
• Did I identify third-party development services?
• Did I split mixed vendor invoices by underlying activity?
• Did I identify training/data conversion/support included in fixed-fee contracts?
• Did I document the allocation basis when a contract contains multiple activities?
• Did I identify shared cloud infrastructure costs?
• Did I distinguish dedicated project compute from broad shared capacity?
• Did I avoid capitalizing shared IaaS merely because it was internally allocated?
• Did I identify AI coding-agent costs?
• Did I determine what activity the AI service performed?
• Did I identify whether AI usage related to a specific qualifying project?
• Did I identify whether AI usage occurred within the capitalization period?
• Did I identify project IDs, repositories, environments, or tickets supporting AI usage?
• Did I avoid capitalizing token/API charges merely because they were measurable?
• Did I evaluate fixed AI subscriptions based on project-specific use rather than billing form?
• Did I identify broad enterprise AI subscriptions?
• Did I avoid allocating general AI subscriptions to projects solely by headcount or labor hours?
• Did I identify committed-consumption AI arrangements?
• Did I distinguish a fixed minimum commitment from a prepaid pool of discrete expected-to-be-consumed units?
• Did I identify mixed AI-agent sessions?
• If AI sessions included qualifying and nonqualifying work, did I have a supportable split?
• If no supportable split exists, did I avoid capitalizing the combined cost?
• Did I identify licensed data used to train an AI model?
• Did I determine whether the licensed data has other uses to the entity?
• Did I apply the appropriate separate intangible-asset analysis when data has other uses?
• For data dedicated to a specific internal-use AI project, did I consider where the project was in its capitalization lifecycle?
• Did I distinguish AI retraining that adds functionality from retraining that merely maintains performance?
• Did I identify whether retraining enables a new task?
• Did I expense routine model-maintenance retraining when appropriate?
• Did I determine whether a customer cloud arrangement includes a software license?
• Did I determine whether the CCA is a service contract?
• For a service-contract CCA, did I identify qualifying implementation costs?
• Did I distinguish the CCA implementation asset from an owned software asset?
• Did I expense CCA training costs?
• Did I expense CCA data migration costs when required?
• Did I expense business-process reengineering associated with the CCA?
• Did I identify the hosting arrangement term?
• Did I evaluate renewal and termination periods when determining the hosting term?
• Did I begin CCA implementation-cost amortization when the module/component was ready for intended use?
• Did I present CCA implementation amortization in the same income-statement line as hosting service expense?
• Did I classify CCA implementation cash flows consistently with the hosting arrangement fees?
• Did I identify software upgrades and enhancements?
• Did I document the functionality before the change?
• Did I document the functionality after the change?
• Did I confirm that a capitalized enhancement enables an additional task?
• Did I avoid treating faster performance alone as new functionality?
• Did I expense maintenance?
• If internal maintenance and minor enhancement costs cannot be separated cost-effectively, did I expense them?
• Did I identify website-development activities?
• If ASU 2025-06 is adopted, did I apply the relocated ASC 350-40 website guidance?
• Did I identify when each module was substantially complete?
• Did I identify when substantial testing was complete?
• Did I identify when each module was ready for intended use?
• Did I stop capitalization at the correct date?
• Did I begin amortization at the correct date?
• Did I determine a supportable useful life for owned internal-use software?
• Did I distinguish owned-software useful life from CCA hosting-term amortization?
• Did I identify abandoned projects or modules?
• Did I evaluate existing software being replaced?
• Did I assess whether useful lives should be shortened?
• Did I evaluate impairment/abandonment accounting when service potential changed?
• Did I reconcile the software rollforward to the general ledger?
• Did I reconcile payroll capitalization to time/activity records?
• Did I reconcile third-party capitalization to invoices and statements of work?
• Did I reconcile AI costs to vendor usage records and project evidence?
• Did I reconcile placed-in-service dates to product/engineering evidence?
• Did I reconcile amortization to the fixed-asset or intangible-asset subledger?
• Did I verify balance-sheet classification?
• Did I verify income-statement presentation?
• Did I verify cash-flow classification?
• Did I evaluate required disclosures?
• Can another accountant trace every capitalized dollar from the GL to a qualifying project, activity, cost source, capitalization period, and ready-for-use conclusion?

100-Point ASC 350-40 Readiness Scorecard

Suggested readiness bands

• 90–100: Ready to own a defined internal-use software capitalization workstream with normal manager/technical review.
• 82–89: Generally review-ready; targeted coaching remains in AI, CCA, scope, or development-uncertainty judgments.
• 72–81: Controlled ownership with manager checkpoints at scope, capitalization start, and go-live.
• Below 72: Continue structured ASC 350-40 practice.

Override the numerical score for intentionally moving capitalization start dates to manage earnings, capitalizing overhead through unsupported allocations, treating maintenance as enhancement without new functionality, capitalizing shared AI costs without direct attribution, or delaying ready-for-use dates to keep capitalizing operating costs.

A 30/60/90-Day Internal-Use Software Training Plan

15 Realistic ASC 350-40 Training Scenarios

1. Finance automation app built for employees

Staff scopes it to ASC 350-40, identifies the applicable capitalization model, and separates preliminary evaluation from qualifying development.

2. SaaS provider builds a hosted-only customer platform

Staff does not automatically send it to ASC 985-20 merely because customers use it; hosted-only delivery is evaluated under the internal-use software scope model.

3. Vendor plans to license an on-premise version

Staff recognizes the potential ASC 985-20 external-use software scope and escalates before applying ASC 350-40.

4. Agile sprint contains coding and production support

Staff capitalizes qualifying coding and expenses production support rather than capitalizing the whole sprint.

5. Product requirements are still substantially changing

Under post-ASU 2025-06, staff identifies significant development uncertainty and delays capitalization until the threshold is met.

6. AI agent generates and tests approved project code

Project-specific, directly attributable usage during the capitalization period may qualify for capitalization.

7. Company buys enterprise AI seats for every department

Staff does not allocate the broad subscription to development projects merely because engineers use it.

8. Token logs show code generation plus production outage troubleshooting

Staff separates qualifying usage only when reliable project/activity evidence supports the split.

9. AI training data is licensed solely for a specific internal AI model

Staff evaluates whether the cost was incurred before, during, or after the capitalization period and whether it supports development, enhancement, or maintenance.

10. AI model is retrained monthly with current transactions

If retraining merely keeps existing performance current, staff treats the activity as maintenance rather than a new software asset.

11. AI model gains a new fraud-detection capability

Staff evaluates the project as an upgrade/enhancement because the software can perform an additional task.

12. Customer implements a hosted ERP service contract

Staff defers qualifying implementation coding but expenses training, data migration, and business-process reengineering.

13. Cloud migration only rehosts existing code

Staff does not capitalize migration/refactoring costs merely because the infrastructure changed when no additional software functionality is created.

14. New cloud migration adds a major new workflow

Staff evaluates qualifying development costs for capitalization because the change adds functionality.

15. Product team marks the entire transformation “in development” for two years

Accounting identifies module-level ready-for-use dates and begins amortization rather than delaying go-live until the final program release.

What CPA Firms and Accounting Teams Should Measure

Connect these measures to your Staff Accountant Competency Checklist, Accounting Employee Development Plan, and Workpaper Review Checklist.

Common Internal-Use Software Accounting Training Mistakes

Mistake 1: “The project is approved, so capitalize everything.”

Authorization is only one part of the recognition analysis, and nonqualifying activities remain expense items.

Mistake 2: “Agile means stages no longer matter today.”

Until ASU 2025-06 is adopted, the existing project-stage model still applies.

Mistake 3: “After ASU 2025-06, capitalize from project kickoff.”

The amended model still requires funding authorization and probable completion/use, including resolution of significant development uncertainty.

Mistake 4: Capitalize entire sprint payroll

Planning, support, maintenance, and training can sit beside qualifying coding in the same sprint.

Mistake 5: Capitalize every AI cost because AI writes code

Shared subscriptions, research, maintenance, and production support do not become direct development costs merely because developers use the tool.

Mistake 6: Use tokens as the accounting rule

Token measurement can support attribution; it does not determine capitalization.

Mistake 7: Put SaaS implementation in owned software

A CCA service contract produces a different asset/presentation model.

Mistake 8: Capitalize data migration because it is expensive

Magnitude does not change the cost’s nature.

Mistake 9: Call every retraining cycle an AI enhancement

Maintenance of current model relevance is different from adding new functionality.

Mistake 10: Delay go-live to keep capitalizing

Capitalization stops when the relevant software/module is substantially complete and ready for intended use.

How SkillAbility Builds ASC 350-40 Capability

BASE — Software-cost fundamentals

• Scope
• current project stages
• capitalizable vs expensed costs
• payroll and contractor support
• ready-for-use and amortization

MAPS — Modern development judgment

• agile sprint evidence
• SaaS / CCA implementation
• cloud migration
• upgrades vs maintenance
• ASU 2025-06 adoption
• significant development uncertainty

SUMMIT — AI and reviewer readiness

• AI agent / token / subscription accounting
• AI training data
• development uncertainty review
• module-level go-live decisions
• impairment / abandonment
• controls over engineering-to-GL evidence
• reviewer coaching without rebuilding the capitalization file

Frequently Asked Questions About Internal-Use Software Accounting

What is ASC 350-40?

ASC 350-40 is the U.S. GAAP Subtopic governing accounting for internal-use software and certain implementation costs incurred in cloud computing arrangements.

What qualifies as internal-use software?

Internal-use software generally includes software developed or obtained for an entity’s own internal needs. Depending on delivery facts, software used solely to provide hosted access to customers can also fall within ASC 350-40.

What software falls under ASC 985-20 instead?

Software developed to be sold, leased, or otherwise marketed as software to third parties is generally subject to ASC 985-20 rather than ASC 350-40.

Is SaaS software always internal-use software?

No. “SaaS” can describe the provider’s hosted software or the customer’s service arrangement. Scope depends on whether a substantive software license exists, how the software is delivered, and which party is developing or implementing it.

When do software development costs start being capitalized under the current ASC 350-40 model?

Before adopting ASU 2025-06, capitalization generally begins after the preliminary project stage is complete, management authorizes and commits funding, and project completion and intended use are probable.

What changes under ASU 2025-06?

ASU 2025-06 removes the project-stage recognition model and bases capitalization on management authorization/funding plus a probable-to-complete threshold, including an explicit assessment of significant development uncertainty.

When is ASU 2025-06 effective?

It is effective for annual reporting periods beginning after December 15, 2027, including interim periods within those annual periods. Early adoption is permitted subject to the transition requirements.

What is significant development uncertainty?

Under the amended guidance, significant development uncertainty exists when software has novel, unique, or unproven functions or technological innovations that remain unresolved, or when significant performance requirements have not been determined or remain subject to substantial revision.

Does ASU 2025-06 change which software costs are eligible for capitalization?

No. The ASU changes the recognition threshold and presentation/disclosure framework but does not broadly expand the categories of costs that can be capitalized. Training, data migration, maintenance, and general overhead remain expense items.

Are developer salaries capitalized?

Payroll and payroll-related costs can be capitalized to the extent employees are directly associated with and spend time on qualifying software development activities during the capitalization period.

Are project-management costs capitalized?

It depends on the nature of the work. General administration and oversight are typically expensed, while some directly attributable technical project activities may qualify. Staff should analyze the actual activity rather than the job title.

Are software training costs capitalized?

Employee training costs are generally expensed as incurred, even when incurred as part of a larger implementation project.

Are data migration costs capitalized?

Manual or outsourced data conversion and migration costs are generally expensed. Separate software obtained to perform data conversion can require a different analysis.

Can AI coding-agent costs be capitalized?

Potentially. AI costs can qualify when they represent direct external development services for a specific qualifying project and activity during the capitalization period. The fact that AI generated code does not by itself make the cost capitalizable.

Are token or API charges automatically capitalized?

No. Usage measures can support cost attribution, but capitalization depends on the nature of the activity, direct project linkage, and timing.

Can an enterprise-wide AI subscription be capitalized?

Generally not merely through an allocation. A broadly available stand-ready tool used across projects and business functions is often more like shared overhead unless facts establish direct project attribution.

How are AI training-data costs accounted for?

They require a separate analysis based on software scope, whether the data has other uses, when the cost is incurred in the development lifecycle, and whether later retraining creates new functionality or only maintains existing functionality.

What is the difference between an upgrade and maintenance?

An upgrade or enhancement adds functionality—meaning the software can perform a task it could not previously perform. Maintenance keeps existing functionality operating or current.

How are cloud computing implementation costs accounted for?

For a hosting arrangement that is a service contract, qualifying implementation costs are deferred using ASC 350-40 principles, while training, data migration, and other nonqualifying costs are expensed.

When does amortization begin?

For owned internal-use software, amortization generally begins when the software or relevant module is substantially complete and ready for its intended use. For a CCA service contract, deferred implementation costs begin amortizing when the applicable module or component is ready for intended use.

How do you know when a staff accountant is review-ready for ASC 350-40?

A review-ready staff accountant can scope the software, identify the applicable current or amended model, support the capitalization start date, classify agile activities, trace direct payroll/vendor/AI costs, distinguish SaaS service-contract implementation from owned software, identify enhancements versus maintenance, establish go-live and amortization dates, and reconcile the capitalization file to the financial statements.

Current Research and Authority Resources

• FASB — ASU 2025-06: Targeted Improvements to the Accounting for Internal-Use Software
• KPMG — Software and Website Costs Handbook, February 2026
• Deloitte — Accounting for AI Costs Associated With Internal-Use Software Development, August 3, 2026
• KPMG — Software Data Costs: Accounting Considerations, February 2026
• Deloitte — Cloud Migration Complexities
• Google Search Central — Optimizing for Generative AI Features
• Google Search Console — Generative AI Performance Report

Internal-use software accounting can intersect with ASC 985-20 external-use software, ASC 340-40 contract fulfillment, ASC 730 R&D, ASC 350-30 intangible assets, ASC 360 impairment, ASC 230 cash flows, ASC 350 website/software guidance, and cloud computing/service-contract accounting. Verify current authoritative literature and entity-specific facts for live work.

The Bottom Line

Internal-use software accounting training should not produce staff who know only that “coding capitalizes.”

It should produce accountants who can explain why a specific project crossed the capitalization threshold, why a specific dollar qualifies, and why amortization starts when it does.

Scope the software before touching the cost ledger.

Know whether the entity has adopted ASU 2025-06.

Under the current model, respect the project-stage capitalization gate.

Under the amended model, prove authorization, probable completion, and resolution of significant development uncertainty.

Account for agile activities—not sprint labels.

Capitalize direct qualifying costs, not broad allocations.

AI does not create a shortcut around ASC 350-40.

Token usage is evidence, not the accounting conclusion.

Separate SaaS implementation assets from owned software.

Expense training, data migration, maintenance, and overhead when required.

Capitalize enhancements only when they add functionality.

Stop capitalizing when software is ready for intended use.

Keep the engineering evidence, GL, amortization, and disclosures synchronized.

That is SOFTWARE READY.

Protect Knowledge. Develop People. Scale the Firm.

To staff who can defend the capitalization before review has to reverse-engineer the sprint,

Vincent Howard, CPA
Managing Partner, Howard, Howard and Hodges
SkillAbility for Accounting Firms

© 2026 SkillAbility for Accounting Firms. This article provides general educational information and does not replace client-specific U.S. GAAP, audit, tax, legal, SEC, valuation, IT-governance, or other professional advice.