Capitalizing Software Development Costs in Agile

TL;DR: Capitalizing engineering work was designed for waterfall: a tidy design phase, a build phase, a done. Agile deleted those phases, and for years finance teams have been squinting at sprints trying to find them. US GAAP finally caught up. FASB's ASU 2025-06 removes the project-stage model entirely, and what replaces it under both GAAP and IFRS is a judgment call that runs on evidence. Teams that can show where engineering time went, from real delivery data, walk into audits calm. The rest reconstruct the year in a spreadsheet every spring. (This is an engineering leader's guide, not accounting advice. Bring your actual auditor.)

Why agile broke the old capitalization model

US GAAP's internal-use software guidance (ASC 350-40) historically described a linear project: a preliminary phase (expensed), an application-development phase (capitalized), and a post-implementation phase (expensed). That maps beautifully onto a 2003 Gantt chart and onto almost nothing your team does today. Continuous delivery has no ribbon-cutting moment where "development" ends; feature work, refactoring, and maintenance interleave in the same week - sometimes the same pull request.

The practical result was translation pain. Finance asked "which stage is this sprint in?", engineering answered "all of them," and the compromise was usually a crude percentage someone estimated once and defended annually. Nobody trusted it, and auditors knew nobody trusted it.

What changed: ASU 2025-06

In September 2025, FASB issued ASU 2025-06, Targeted Improvements to the Accounting for Internal-Use Software. The amendments remove the references to project stages from ASC 350-40 and replace them with a threshold that fits iterative development: capitalization starts when management has authorized and committed to funding the project and it is probable that the project will be completed and the software will perform its intended function (Grant Thornton's summary). The update is mandatory for annual reporting periods beginning after December 15, 2027, and early adoption is permitted.

Read that threshold again as an engineer. It asks whether the work is committed and likely to ship, and your delivery data can actually answer that. The evidence bar just moved from "plausible percentages" toward "show me."

And under IFRS: IAS 38

If you report under IFRS, the stage problem never existed in the same form. The judgment bar is arguably higher. IAS 38 splits work into a research phase (always expensed) and a development phase, and development costs must be capitalized only when you can demonstrate all six criteria: technical feasibility, intention to complete, ability to use or sell the asset, probable future economic benefits, adequate resources to finish, and the ability to measure the development expenditure reliably (IAS 38, IFRS Foundation).

That last criterion is the one engineering leaders underestimate. "Reliably measure the expenditure attributable to the asset" means, in practice: you can say which engineering effort went into which initiative, with a straight face, under questioning.

What qualifies, what never will

The boundary both frameworks agree on, in engineering terms:

• Capitalizable (once the threshold/criteria are met): building genuinely new capabilities and enhancements committed to ship. This is the work that creates the asset.
• Never capitalizable: exploration and spikes before anything is probable; bug fixing and maintenance of what already exists; keep-the-lights-on operations. The waste categories are expense by definition too - every hour a PR burns idle in a queue is pure operating cost, which is one more reason to price what slow review costs you.

The money at stake scales with your cost basis. The rate you capitalize at should be the fully loaded engineering cost, not raw salary. If you have not computed that number, do it first, because it is the multiplier under every figure in this exercise.

Keeping the evidence audit-ready with continuous delivery

What auditors actually probe is your allocation method. The failure mode is universal: a year of interleaved work, reconstructed each April from calendars, tribal memory, and a survey nobody answered carefully. The fix is to make the record a by-product of delivery instead of an annual archaeology project.

• Attribute work at the source. Your commits, PRs, and tickets already say which initiative every hour served. An allocation derived from that record is reproducible. One derived from memory is negotiable, and auditors negotiate.
• Mark the thresholds explicitly. Record the date management committed to an initiative and the date it shipped or died. Under ASU 2025-06's probable-to-complete framing, those two dates are the capitalization window.
• Keep the method deterministic. Same inputs, same allocation, every time it is run. The moment a report cannot be regenerated, it stops being evidence and starts being testimony. This is exactly the job of an audit-ready investment view built from engineering data: allocation with receipts attached, regenerable on demand.
• Review the split quarterly, not annually. A drifting new-work/maintenance ratio is a management signal in its own right. If your capitalizable share is shrinking, your roadmap is quietly becoming upkeep. Better to learn that in Q2 than in the audit.

The door: pick one current initiative and run the full trace this month - commitment date, the engineering time attributable to it from your actual delivery data, loaded cost applied, expense/capital split stated. If that takes you an afternoon, you are audit-ready. If it takes a week, you have just found next quarter's most profitable process fix. Either way, you will never again have to answer "which stage is this sprint in?"