The buy-side Quality of Earnings provider is trying to reclassify our capitalized software development costs as operating expenses, which would severely slash our trailing EBITDA. How do we defend our historical capitalization policy using accounting standards and our EOS tracking tools?

Question

Tyler Smith · Accepted Answer

Buy-side Quality of Earnings teams routinely target capitalized software development costs to artificially depress your historical EBITDA. Their goal is to prove that these costs are recurring operating expenses, which would lower your baseline cash flow and multiple. To defend your historical capitalization policy, you must present a highly systemized defense. Start by aligning your defense with US GAAP or IFRS guidelines, specifically pointing to ASC 350-40, which governs internal-use software. Show that capitalization only occurred during the application development stage, after the preliminary project stage was complete. This is where your EOS® documentation becomes a major asset. Pull your historical V/TO® archives, Accountability Chart, and Rock sheets. Use these to prove that the team members working on these initiatives were dedicated to building new, scalable intellectual property, not performing routine maintenance. By showing that these projects had clearly defined timelines, measurable deliverables, and were tracked as quarterly Rocks, you prove the work was capital expenditure by definition. Additionally, provide time-tracking logs linked directly to these developmental Rocks. This structured documentation leaves the QofE analyst with no room to claim the labor was operational overhead. This protects your EBITDA and maintains your target valuation multiple.