How to Use AI on Capitalized Software Costs Now That the Project Stages Are Gone

FASB removed the project stages from internal-use software accounting, and what replaced them is a two-part test that a good AI agent can feed with evidence and cannot answer for you. In our database of 50,542 active, de-duplicated accounting and finance postings, 106 mention capitalized software, internal-use software or ASC 350-40, spread across 62 employers, and 92 of those show a salary with a median posted midpoint of $116,254. That's a small corner of the market, and the people hired into it are about to have a very different year.

Honestly I like this change, because the old stage model (preliminary project, application development, post-implementation) was written with waterfall projects in mind and agile teams have been squeezing their sprints into it for years. The new model is cleaner, and it still leaves you holding a judgment call that no tool should make for you.

What changed in the internal-use software rules?

ASU 2025-06, issued in September 2025, eliminates the references to project stages in ASC 350-40. Per RSM's summary, capitalization starts once management has authorized and committed to funding the project and it is probable the project will be completed and the software will be used to perform the function intended. Capitalization can't begin while significant development uncertainty remains, meaning novel or unproven features that coding and testing haven't resolved, or significant performance requirements that haven't been identified or keep getting substantially revised.

The amendments are effective for annual periods beginning after December 15, 2027, with early adoption permitted, and you can adopt prospectively, on a modified basis, or retrospectively. Capitalized costs also pick up the Topic 360 disclosures, and the Subtopic 350-30 intangible disclosures no longer apply to them. You have time, and I'd still start now, because the evidence trail this standard asks for is the part that takes a year to build.

Which parts of capitalized software accounting can AI handle?

The tracing work. Software capitalization is mostly a cost allocation exercise: payroll for the engineers, contractor invoices, cloud and tooling spend, all matched to a project and split between capitalizable and expensed activity. An agent with read access to your payroll export, your ticketing system and your AP ledger can propose that split, line by line, with a reason attached to each. That's the same shape of work as the allocation tasks in our post on stock comp, and it's where the hours go.

A second good use is the evidence file. For each project the agent can assemble the funding approval, the dated requirements documents, the test results and the release notes into a single binder with a summary of what changed and when. The significant-development-uncertainty test depends on whether requirements were still being substantially revised, and a timeline built from ticket history shows that far more reliably than a controller's memory of a standup.

Third is the roll-forward. Once costs are capitalized, the amortization schedule, additions, abandonments and impairment indicators are mechanical, and an agent can reconcile them against the subledger the way it can for other assets, as we covered in the fixed asset roll-forward piece.

What should a human still decide?

The probable-to-complete call, for one. That's a judgment about whether the project will finish and do its job, it carries your auditors' attention, and a model can summarize the evidence while having no stake in being wrong. The second thing is the line on significant development uncertainty, because deciding whether a feature is novel or unproven needs someone who understands the product, and the engineer who built it will have a different answer than the VP who funded it.

Same goes for the transition method. Picking prospective, modified or retrospective adoption is a policy decision with comparability consequences, so run the numbers all three ways with the agent and then make the call yourself. If you're drafting the position paper, our guide on using AI on a technical accounting memo covers how to keep the conclusion in your hands.

The counterweight is worth stating: an agent can propose a probable-to-complete conclusion that reads beautifully and is wrong, because it only sees the documents you gave it. Treat its output as a draft assessment and make the engineering lead sign the facts.

Who is hiring for this work?

Of the 106 postings that mention it, 66 carry a CPA signal, 20 are hybrid and 15 are remote, and 12 name AI tools. The roles skew toward senior accountants (14), accounting managers (12), technical accounting managers (8) and technical accounting (7), with 4 controllers, and a large chunk (39) don't map cleanly to one of our role buckets. If you want to see the current set, the remote senior accountant jobs page is a good place to scan how employers describe the work, and our accounting software directory lists the ERPs and fixed asset tools the work runs through.

What I'd do

Pick one product team and run last quarter through it. Export the payroll and contractor data for that team, pull the ticket history, and ask an agent to propose a capitalizable versus expensed split under the new two-part test, with a sentence of reasoning per line. Compare it against what your team did under the stage model, and look hard at the lines where the two disagree, because that's where your policy needs work. Then write the funding authorization and probable-to-complete assessment as a one-page template that the engineering lead and finance sign together.

Do that before January and you'll walk into 2027 with a repeatable process and an audit file, which beats scrambling in 2027 with a shit-show of spreadsheets and a Slack thread full of guesses. And if the dev team keeps changing requirements mid-sprint, that's data too, since it tells you which projects you shouldn't be capitalizing yet.

Frequently asked questions

What did ASU 2025-06 change for internal-use software?

It removed the references to project stages in ASC 350-40 and replaced them with a test: management has authorized and committed to funding the project, and it is probable the project will be completed and used for its intended function. Significant development uncertainty can still delay capitalization.

When does ASU 2025-06 take effect?

For annual periods beginning after December 15, 2027, and interim periods within those years, with early adoption permitted. Entities can adopt prospectively, on a modified basis or retrospectively.

Can AI decide whether software costs should be capitalized?

It can propose a split and assemble the evidence, and a person should make the probable-to-complete and development-uncertainty calls, since those are judgments your auditors will question.

What data does an AI agent need for software capitalization?

Payroll by employee and project, contractor invoices, cloud and tooling spend, ticket or time-tracking history, and the funding approvals and requirements documents for each project.

Are accounting employers hiring for capitalized software experience?

Some are. 106 of 50,542 active postings in our database mention it, from 62 employers, and 92 of them show pay with a median posted midpoint of $116,254.

The standard is changing on a schedule you can see coming, and the teams who build their evidence process this winter will spend next year reviewing rather than reconstructing. Pick the product team and start the pilot this month.