Tech Spend Meets GAAP: Are You Capitalizing Software & AI Costs Correctly?

Internal-Use Software, AI Investments, and What Changes Under ASU 2025-06

Technology has become one of the largest spending decisions for many private companies. Enterprise resource planning (ERP) replacements, customer relationship management (CRM) platforms, automation, and artificial intelligence (AI) projects all raise the same question for accountants: Is this an asset or an expense?

Why This Matters for Private Companies

The answer (asset or expense) affects earnings and projections, EBITDA-based covenants, working capital trends, and how owners, lenders, or buyers evaluate the business. It also depends on documentation gathered throughout the project — approvals, budgets, scope decisions, and labor records — not on documentation gathered only after year-end.

The question is rarely just technical, and the rules are changing. In September 2025, the Financial Accounting Standards Board (FASB) issued ASU 2025-06, Intangibles—Goodwill and Other—Internal–Use Software (Subtopic 350-40), which changes when internal-use software costs begin to be capitalized.

Where the Rules Sit Today

ASC 350-40 (the subtopic of ASU 2025-06 that we’re discussing here) applies to software that a company develops or obtains for internal use, including qualifying implementation costs in a cloud arrangement that is a service contract. Software developed to be sold, leased, or licensed follows ASC 985-20, which ASU 2025-06 does not change.

Today’s model is stage-based. Preliminary activities, such as evaluating alternatives and selecting a vendor, are expensed. Application development activities, such as coding, configuring, installing, and testing, are capitalized once management has approved and committed to funding the project and completion is probable. Training, maintenance, overhead, data conversion, and general administrative costs do not qualify.

Where Practice Goes Off Course

Software capitalization remains one of the more frequent sources of financial statement corrections. The recurring themes include:

• Using the project kickoff as the start date. Capitalization is driven by the criteria in the standard, not by when the invoice arrives or the project charter is signed.
• Sweeping in costs that never qualify. Training, data conversion, change management and allocated overhead ride along in the same project code and end up on the balance sheet.
• Confusing the subscription with the implementation. In a cloud arrangement that is a service contract, the software fee itself is not an internal-use software asset; only qualifying implementation costs are evaluated under ASC 350-40.
• Capitalizing past the finish line. Capitalization stops when the software is substantially complete and ready for its intended use. Later work qualifies only if it adds functionality, which fixes and maintenance do not.
• Amortization that never starts, or lives that no one revisits. Assets sit in construction-in-progress long after go-live or carry a life that no longer reflects how the system is used.
• Thin documentation. No evidence of funding approval or time records supporting labor charged to the project, which becomes problematic under the new model.

What ASU 2025-06 Changes

The three-stage model was written in 1998, when software was built sequentially. ASU 2025-06 will require companies to use judgment when determining what constitutes a software development project with uncertainties and whether such a project will meet thresholds for capitalization, potentially resulting in the recognition of more expenses up front. The ASU moves the focus from project-stage labels to whether the project is funded, probable, and ready for its intended use.

In evaluating whether completion is probable, companies must consider whether significant development uncertainty exists. That includes whether the software uses technological innovations or novel, unique, or unproven functions that have not yet been resolved through coding and testing, and whether the company has determined what the software needs to do, including whether significant performance requirements are still being substantially revised.

Website development costs now sit within the internal-use software guidance, and ASC 360-10 disclosure requirements apply to capitalized internal-use software costs regardless of balance sheet presentation.

The types of costs eligible for capitalization, the point at which capitalization stops, amortization, impairment, and software developed for sale remain unchanged.

ERP, CRM, and AI Are Not the Same Project

These projects can land in very different places. A licensed or on-premises ERP build is classic internal-use software. A hosted CRM or automation platform often is a service contract; the subscription is not a software asset, but qualifying implementation costs may be capitalized and amortized over the hosting term. Automation and workflow projects also require separating software work from business process redesign, which is expensed under ASC 720-45.

AI adds another layer because US GAAP does not contain AI-specific cost guidance. Companies generally apply existing software guidance by analogy: internal-use AI tools follow ASC 350-40, while AI software sold or licensed to customers follows ASC 985-20.

The new uncertainty concept matters most for AI. If a project is still testing whether a model can achieve acceptable accuracy or if performance requirements are still changing, costs are expensed until those uncertainties are resolved. Configuring a proven commercial AI tool is different and may meet the threshold sooner.

Three Projects, Before and After

The impact will not be uniform: two companies may spend the same amount on technology and reach different capitalization conclusions depending on the project’s purpose, structure, and level of development uncertainty.

The change does not point in one direction. Conventional ERP and CRM projects with clear scope may capitalize sooner. Exploratory AI projects may capitalize less. Companies running both should expect mixed effects in the same year.

Timing and Transition

The amendments are effective for annual periods beginning after December 15, 2027, and interim periods within those annual periods (calendar year 2028 for most private companies). Early adoption is permitted at the beginning of an annual reporting period. Companies may apply the guidance prospectively, retrospectively, or using a modified approach. Because the modified approach may require derecognizing costs on in-process projects, the transition method should be modeled before adoption.

What to Do Before It Matters

• Inventory in-flight and planned projects and identify which ones carry development uncertainty.
• Make funding authorization an observable event — a dated approval with an amount attached, not an assumption.
• Tighten project time tracking now; the new threshold depends on judgment that must be evidenced.
• Make capitalization support easy to trace: approved budget, signed contract, governance minutes, and direct labor time records.
• Model the three transition methods against your in-process projects before choosing one.
• Talk to lenders early if capitalization patterns will shift EBITDA-based metrics.

For private companies, the practical challenge is building evidence while the project is underway. The effective date is not far ahead, but the accounting evidence is being created now through project approvals, funding, staffing, and documentation. Companies that build discipline into the next technology project will find adoption easier and less disruptive.

For assistance evaluating software and AI project costs, transition alternatives, or accounting policy updates, contact us using the form.