The thesis: software capitalization is now an operating system problem.
The weak reading of ASU 2025-06 is that FASB removed the old stage-gate vocabulary. The stronger reading is that finance can no longer hide behind a waterfall fiction when the company builds software through agile teams, vendor implementation partners, cloud migrations, finance automation tools, and internal AI workflows.
FASB issued ASU 2025-06 in September 2025 to update Subtopic 350-40 for internal-use software. The standard removes references to prescriptive, sequential project stages and says capitalization begins when management has authorized and committed funding and it is probable the project will be completed and used as intended. The effective date is annual periods beginning after December 15, 2027, with early adoption permitted at the start of an annual period.
That sounds distant. It is not. Public-company filings already discuss the update, and at least one filer, Lumen Technologies, disclosed an intent to early adopt prospectively effective January 1, 2026. The implementation question for controllers is therefore immediate: can the ERP prove when a software project crossed the recognition threshold, which costs were eligible, and when capitalization stopped?
What changed.
FASB says the update applies to all entities subject to internal-use software guidance in Subtopic 350-40 and to entities accounting for website development costs under Subtopic 350-50. It does not affect software costs subject to Subtopic 985-20 for software to be sold, leased, or marketed.
The operative shift is timing and evidence. The old model asked finance to identify project stages. The new model asks finance to support two threshold facts: management has authorized and committed funding, and completion plus intended use is probable. FASB also requires assessment of significant development uncertainty, including unresolved novel functionality and performance requirements that have not been identified or continue to be substantially revised.
The standard also pulls website development recognition requirements into Subtopic 350-40 and says Subtopic 360-10 property, plant, and equipment disclosures apply to capitalized internal-use software costs regardless of financial-statement presentation. That matters for ERP reporting because software cost data can no longer live in a side spreadsheet owned by technical accounting.
Why this belongs in the ERP, not the policy binder.
The accounting conclusion depends on facts created outside accounting: who approved funding, what the software is supposed to do, whether functionality is novel or unproven, which work items were built, which vendor invoice lines were implementation versus maintenance, and when testing made the software ready for use. If those facts are not captured in the ERP and connected systems as work happens, the close team has to reconstruct them after the period ends.
A serious design treats software cost accounting like a controlled subledger. The project ledger owns accounting scope and threshold dates. Procurement owns vendor-line classification. Engineering owns work-item evidence. Finance owns policy, review, capitalization, amortization, impairment, transition, and disclosure support. The ERP should preserve the join key across all of them.
The data model finance actually needs.
The dangerous shortcut is a single project code called "ERP implementation" or "AI automation." That code does not prove whether the cost was eligible, whether the threshold had been met, whether uncertainty had been resolved, or whether capitalization should have ceased.
Example internal-use software cost record
{
"software_project_id": "ius_erp_close_automation_2026",
"project_name": "Close automation workflow rebuild",
"accounting_scope": "ASC_350_40_INTERNAL_USE_SOFTWARE",
"business_owner": "controller",
"funding_authorized_at": "2026-05-14",
"funding_authorized_by": "cfo",
"probable_to_complete_assessed_at": "2026-06-18",
"significant_uncertainty_status": "RESOLVED",
"performance_requirements_version": "req_2026_06_15_v3",
"capitalization_start_at": "2026-06-18",
"ready_for_use_at": null,
"cost_lines": [
{
"source": "time_entry",
"work_item": "workflow-engine/idempotent-close-task-runner",
"employee_id": "eng_184",
"hours": 6.5,
"cost_class": "eligible_development",
"accounting_treatment": "capitalize"
},
{
"source": "vendor_invoice",
"invoice_line_id": "bill_4811_line_03",
"description": "admin training",
"cost_class": "training",
"accounting_treatment": "expense"
}
],
"evidence_ref": "s3://audit-evidence/software-costs/ius_erp_close_automation_2026/"
}The minimum viable data model separates the business project from the accounting threshold, the work item from the cost line, the vendor contract from the invoice line, and the ready-for-use date from the public go-live announcement. It also stores negative evidence: unresolved uncertainty, substantially revised requirements, abandoned modules, and replaced software.
Control design for ASU 2025-06.
| Risk | Control | Evidence |
|---|---|---|
| Project approval | Capitalization cannot start from a roadmap label. Capture the approval body, budget owner, funding commitment, and intended internal-use function. | Approved business case, funding memo, project ID, module scope, authority matrix, start date. |
| Probable-to-complete threshold | Require finance review before capitalization begins, with explicit assessment of completion probability and intended use. | Recognition memo, threshold date, reviewer, probability rationale, unresolved blockers. |
| Significant development uncertainty | Block capitalization while novel functionality is unproven or significant performance requirements are still being substantially revised. | Feature risk register, proof-of-concept results, testing evidence, requirements baseline, change history. |
| Agile time capture | Map epics, stories, and releases to accounting treatment without forcing engineering into fake waterfall stages. | Time entries, work item links, sprint/release tags, cost class, capitalization rule, approver. |
| Vendor and cloud spend | Separate implementation, configuration, integration, training, maintenance, support, and hosting charges at purchase-order and invoice-line level. | PO line classification, contract allocation, invoice support, receiving record, capitalization decision. |
| Ready-for-use date | Stop capitalization no later than substantial completion and readiness for intended use, then trigger amortization and replacement assessment. | Testing sign-off, go-live decision, ready-for-use date, amortization start, replaced asset review. |
| Impairment and abandonment | When the project loses funding, changes scope, or is replaced, reassess existing balances instead of letting WIP age silently. | Impairment trigger, abandonment memo, write-off approval, retained component analysis. |
| Transition election | Choose prospective, modified, or retrospective adoption with evidence for in-process projects and retained earnings impacts. | Transition method memo, project inventory, adoption-period entries, disclosure support. |
The control owner is not only technical accounting. Controllership defines the policy and reviews judgments. FP&A and procurement structure project and vendor data. Engineering and IT supply work evidence. ERP administration protects the master data and workflow. Audit needs a packet that shows the conclusion, not only the ending journal entry.
Implementation checklist for finance operators.
Build an inventory of all internal-use software projects: ERP implementations, finance automation, data warehouse work, internal AI tools, integrations, websites, and cloud migrations.
Assign every project a finance-owned capitalization profile: software type, accounting scope, business owner, budget owner, cost centers, start threshold, ready-for-use trigger, and useful life policy.
Create a review gate that records when management has authorized and committed funding and when completion is probable.
Require engineering and finance to document significant performance requirements before costs begin capitalizing.
Track novel, unproven, or AI-driven functionality separately until coding and testing resolve the relevant uncertainty.
Classify vendor invoices at the line level, not at the vendor level, so training, maintenance, hosting, implementation, data conversion, and specified enhancements do not collapse into one account.
Connect time tracking to work items, projects, releases, and cost classes so capitalization is supported by operational evidence rather than quarterly estimates.
Define ready-for-use evidence before go-live: testing completion, access provisioning, production release, operating acceptance, and replacement of prior software.
Run a transition dry run for in-process projects before adoption so retained earnings, WIP, amortization, and disclosure effects are not discovered during close.
Do not start with journal-entry templates. Start with the project inventory and the evidence chain. Once the company can prove threshold dates, eligible costs, exclusions, ready-for-use dates, and transition treatment, the accounting entries are the easy part.
Audit evidence is the product.
Auditors will not be satisfied by "engineering said it was development" or "the project was in implementation." ASU 2025-06 asks for judgment around authorization, probability of completion, intended use, development uncertainty, performance requirements, and cessation of capitalization. Those judgments need contemporaneous evidence.
The audit packet should include the policy, project inventory, threshold memo, requirements baseline, unresolved-uncertainty assessment, sampled time entries, sampled vendor invoices, ready-for-use proof, amortization setup, impairment trigger review, and transition election. If any of those artifacts cannot be retrieved by project ID, the process is not controlled.
Failure modes that will hurt close.
Treating ASU 2025-06 as a technical accounting memo while the ERP still cannot distinguish approved build work from exploration, bug fixes, training, hosting, and maintenance.
Using engineering sprint status as accounting status without a finance-owned recognition threshold.
Capitalizing AI, automation, or integration work before novel functionality and performance requirements are sufficiently resolved.
Recording all implementation partner bills to one project code, then trying to separate maintenance, support, data conversion, and enhancement work at audit time.
Letting ready-for-use dates depend on finance memory instead of release, testing, and operating-acceptance evidence.
Ignoring in-process projects until the adoption year, when transition options are more expensive to analyze and explain.
Assuming no impact because the effective date is later than the next close cycle.
The most expensive failure is late classification. Once invoices are posted, sprints are closed, contractors roll off, and requirements have changed, finance has to infer facts that should have been captured when the work happened. That creates audit friction and inconsistent treatment across teams.
What ERP buyers should ask vendors now.
Can the ERP project ledger store the capitalization-threshold date separately from the project start date, budget approval date, release date, and amortization start date?
Can time entries inherit accounting treatment from a controlled work-item or release classification while still allowing finance override and review?
Can purchase orders and invoices split implementation, configuration, maintenance, hosting, training, data conversion, and specified enhancement work into different accounting treatments?
Can the system preserve the evidence used to conclude that significant development uncertainty has been resolved?
Can in-process project balances be exported by transition method, capitalization status, component, cost type, and ready-for-use date?
A credible answer will include project subledgers, line-level vendor classification, work-item lineage, controlled threshold dates, amortization triggers, impairment review, and exportable transition evidence. A generic "project accounting" module is not enough.
Market signals.
Practitioner commentary is converging on the same operating point: the rule is more compatible with agile delivery, but it raises the documentation burden. PwC explicitly calls out ERP implementations, cloud migrations, analytics platforms, and digital customer tools as projects that can fall in scope. RSM frames the change around the shift from waterfall to agile development methods. Deloitte notes that the update does not fully align internal-use software with external-use software guidance.
Public company disclosures show the topic has moved from standards update to operating queue. Zeta Global disclosed that the guidance removes software development stage references and requires capitalization when funding is authorized, completion is probable, and intended use is expected. Lumen disclosed a prospective early adoption intent effective January 1, 2026 and said it did not expect a material impact.
Practical takeaway.
ASU 2025-06 does not reward companies for creating a prettier capitalization spreadsheet. It rewards companies that can prove project approval, development uncertainty, cost eligibility, ready-for-use, amortization, impairment, and transition decisions inside the operating workflow. Build the software cost subledger once, connect it to procurement and engineering, and make the audit packet a byproduct of work. Anything else turns the close into archaeology.
Sources.
- FASB ASU 2025-06: Targeted Improvements to the Accounting for Internal-Use Software
- FASB project page: Accounting for and Disclosure of Software Costs
- Deloitte Heads Up: FASB amends guidance on accounting for and disclosure of software costs
- PwC: New software capitalization standard changes
- RSM: Accounting for internal-use software costs
- Zeta Global 2026 Form 10-Q disclosure on ASU 2025-06
- Lumen Technologies 2025 Form 10-K disclosure on early adoption intent