An operating partner should plan the cost of a portfolio company's own AI application as an expense in EBITDA until a test on the company's own records shows it meets settled performance requirements, and have the CFO show anything the books capitalize before then on its own line.
The ground is Accounting Standards Update 2025-06, published in September 2025 by the Financial Accounting Standards Board. Under it, capitalizing internal-use software costs must start once management commits to funding and it is probable the software will be completed and used as intended. That is not probable while significant development uncertainty exists, meaning either of two factors: technological innovations or novel, unique or unproven functions not yet resolved through coding and testing, or significant performance requirements not yet identified or still being substantially revised.
For an application matching supplier invoices to purchase orders and receipts, the CFO writes one page before the board approves funding: the performance requirements, such as the share of invoices matched with no person touching them and the error rate the controller accepts; the test, the controller running one full month of the company's own invoices beside the current process and scoring both figures, and the month it is due; how the controller codes model training and data conversion, which the update left without specific guidance; and covenant headroom with the whole build expensed. Before work starts, the CFO gets the auditor's comment on the page, including the CFO's call on whether the function is novel. From funding, developers on payroll log weekly hours, which the controller codes to the project with the outside firm's invoices, since the update capitalizes payroll only for time spent directly on it. The CFO signs each test result against the page and dates any rerun on it.
Planned EBITDA carries every build cost, paid from the company's operating budget, as an expense until a test passes on the requirements then in force, and follows the books from then; reported EBITDA carries what the books expense. If the auditor agrees the function is novel, the page's test can both resolve it and complete substantial testing, when capitalization must end, so little or nothing may be capitalized. If nothing is novel and the page's requirements hold, as in the update's example of a company selecting from a vendor's existing functionality, capitalization starts at funding if completion is otherwise probable. If the capitalization requirements stop being met mid-build, the balance is tested for impairment, and the rebuttable presumption is that such uncompleted software has a fair value of zero.
The update applies to all entities for annual reporting periods beginning after December 15, 2027, with early adoption permitted from the start of an annual period, so portfolio companies with different fiscal years reach it on different dates. Until then the current guidance generally capitalizes eligible costs in the application development stage; whatever either guidance capitalizes before the test sits on its own line under planned and reported EBITDA in the CFO's monthly board report. Before its adoption year, the CFO chooses a prospective, modified or retrospective transition; the modified method removes through opening retained earnings the capitalized cost of an in-process project failing the update's requirements, and the retrospective method recasts comparative periods, one reason the plan waits for the test.
The plan holds at every portfolio company, while in the books software sold under an on-premises license stays under Subtopic 985-20, which the update does not affect, and a company under another framework follows its auditor's reading.
Weighing a single model for all software costs, the Board heard investors say they strive to compare earnings across entities and that different levels of capitalization make that comparison more challenging.
