The buyer's Quality of Earnings firm is claiming that our historical capitalization of internal software development and systems engineering was too aggressive, pushing to reclassify these as operating expenses to drag down our EBITDA. How do we defend our capitalization policy and protect our run-rate EBITDA?

Question

Tyler Smith · Accepted Answer

A buy-side Quality of Earnings review is designed to find reasons to reduce your historical EBITDA, and internal software development costs are a prime target. If the auditor successfully argues that your developers were performing routine maintenance rather than building new, scalable software assets, they will reclassify those capitalized costs as operating expenses. This directly reduces your EBITDA and your valuation.

To defend your numbers, you must provide precise operational documentation that links accounting entries to actual development progress. This is where your operational execution saves you. Pull your historical V/TO® records, your product development Rocks, and your project-specific tracking sheets to prove exactly what your team was building.

You must demonstrate that these software developers were focused on creating discrete, long-term operational capabilities that qualify for capitalization under GAAP, rather than day-to-day bug fixes. Show the auditors how your product roadmap aligns with your quarterly goals and how your developers spent their time on high-level initiatives rather than administrative tasks.

If you have clear Accountability Chart roles showing dedicated software development seats, use them. Prove that these individuals do not participate in routine customer support. When you back up your financial books with consistent, historical operating data, you make it incredibly difficult for a buy-side accounting firm to discount your capitalization policy as aggressive accounting.