Capitalized software development costs under ASC 350-40 and ASU 2025-06

ASC 350-40 currently sorts internal-use software development into three stages. The paragraph numbers below are those in the current Codification as shown in ASU 2025-06.

• Preliminary project stage. Internal and external costs are expensed as incurred (350-40-25-1).
• Application development stage. Costs to develop the software are capitalized (25-2), including software that converts old data (25-3). Training is expensed (25-4), and other data conversion costs are too (25-5).
• Post-implementation stage. Training and maintenance are expensed (25-6).

What counts as a capitalizable cost is narrow (350-40-30-1): external direct costs of materials and services, payroll and payroll-related costs for employees directly associated with the project, to the extent of time spent directly on it, and interest under Subtopic 835-20. General overhead isn't on the list.

Upgrades and enhancements are capitalized only when they add functionality, meaning the software can perform tasks it couldn't before (25-7). Bug fixes and routine changes are maintenance and are expensed.

Software to be sold, leased or marketed to customers follows ASC 985-20 instead. The two are separate regimes, and the same team can work on both.

The Update removes every reference to project stages from Subtopic 350-40. A company starts capitalizing when both of these have happened:

1. Management has authorized and committed to funding the software project.
2. It is probable that the project will be completed and the software used to perform the function intended.

In judging the second point, the company considers whether there is significant development uncertainty. FASB gives two factors: whether the software has technological innovations or novel, unique or unproven functions or features whose uncertainty hasn't been resolved through coding and testing, and whether the company has determined what the software needs to do or keeps substantially revising its significant performance requirements.

Other changes (all from ASU 2025-06): Subtopic 360-10 disclosures apply to all capitalized internal-use software, whatever its balance sheet line; the intangibles disclosures in 350-30-50 do not; and website development guidance in Subtopic 350-50 moves into 350-40. Costs under 985-20 are untouched.

The Board expects capitalization to be broadly unchanged for most software, and expects a possible decrease for software delivered through a cloud computing arrangement. The Update is effective for all entities for annual periods beginning after December 15, 2027, with early adoption allowed as of the beginning of an annual period. Companies can transition prospectively, with a modified approach based on project status, or retrospectively.

Stages were written for waterfall projects: design, build, test, launch. Most teams now ship in increments, which is why FASB dropped them. The test becomes a question about each project at each point in time, and the answer needs evidence your engineering and finance teams already produce.

For the first condition, authorization and funding, the evidence is a budget or roadmap approval: a board-approved plan, a funded epic, a release scope signed off by the head of product. It should be dated, because capitalization starts on that date and not before.

For the second, probable completion, the evidence is the state of the work: requirements defined, prototype built, major technical risks resolved. A feature that is a routine extension of a proven stack reaches the threshold sooner than one built on unproven technology. A project where requirements keep changing may not reach it yet.

Our policy template sets out four things: what counts as a project, the dates and evidence that start and stop capitalization, how time is tracked (tickets, time sheets or sprint allocations), and how contractors are coded. It also has the approach to shared platform work that serves capitalized and expensed projects at once. We draft it; management adopts it, and the controller owns the judgments.

When your company is the customer, not the builder, ASU 2018-15 applies. If a cloud computing arrangement is a service contract, the fees for the hosting service are expensed. The implementation costs, such as configuration and integration done during the application development stage, are capitalized and expensed over the term of the hosting arrangement.

The term includes the noncancellable period plus option periods the customer is reasonably certain to exercise. The expense goes in the same income statement line as the hosting fees. The capitalized costs go in the balance sheet line where a prepayment of the hosting fees would sit, and the cash payments in the same cash flow category as the hosting fees. Training and certain data conversion costs can't be capitalized. The Update applied to entities other than public business entities for annual periods beginning after December 15, 2020.

A company that builds a SaaS product and also buys cloud tools therefore runs two schedules: one for what it develops (350-40 as amended by ASU 2025-06) and one for what it implements (ASU 2018-15). Keeping them apart makes the audit trail and the impairment checks cleaner.

IAS 38 expenses research and capitalizes development costs, but only when the company can demonstrate all six criteria in paragraph 57: technical feasibility, intention to complete, ability to use or sell, how the asset will generate probable future economic benefits, adequate resources, and the ability to measure the expenditure reliably. The model is criteria-based rather than the two-part threshold ASU 2025-06 introduces.

The two frameworks can therefore start capitalizing at different dates for the same project, and a US subsidiary reporting to an IFRS parent needs the difference in its bridge. The US GAAP vs IFRS guide has the wider comparison.

For software-as-a-service, the IFRS Interpretations Committee's April 2021 agenda decision on configuration or customization costs said that a customer often wouldn't recognize an intangible asset because it doesn't control the software being configured. Where no asset arises, the costs are expensed when the supplier performs the configuration, or over the term of the SaaS contract as a prepayment when the configuration isn't distinct from access to the software. That differs from ASU 2018-15, which allows capitalization over the hosting term. Group policy may have taken a view on this, so ask before booking the pack.

The auditor starts from the cost records. Payroll capitalized has to tie to time records and to the payroll register, with the same people and the same rate. Contractor costs tie to invoices and to project codes. The auditor then asks how each project met the start condition and when it stopped (ASC 350-40-25-14 on completion, and the example in 350-40-55-17 shows a project ceasing capitalization the day substantial testing was completed).

Amortization follows from the ready-for-use date. Each release gets a useful life, and the schedule shows the amounts by release. Impairment gets tested when a project is abandoned, the plan changes or usage falls, under the long-lived asset test described on the impairment page.

We hand over a workbook built so those tie-outs are visible: cost by project and month, the payroll reconciliation, the dated start and stop evidence, the amortization schedule and a roll-forward of the asset. For an ASU 2025-06 transition, it adds a comparison of what would be capitalized under the old and the new rules for in-process projects, which is the basis for choosing a transition method.