Why Capitalizing Engineering Costs Can Make a Software Company Look More Profitable Than It Is

The line item that quietly moves

A twelve-person engineering team at a vertical software company building practice management tools for accounting firms spends its quarter shipping a new module: automated workpaper reconciliation, something clients have asked for since the product launched. Six engineers work on it for four months. Their combined salaries and benefits run a meaningful chunk of the company's monthly burn.

Under one accounting treatment, that spend shows up as research and development expense, reducing operating income dollar for dollar in the quarter it happens. Under another, permitted by U.S. GAAP, a portion of those same salaries gets capitalized: recorded as an asset on the balance sheet and depreciated over the module's useful life, typically three to five years, instead of expensed immediately.

Same engineers. Same payroll. Same work. Two very different income statements.

The mechanics of capitalizing internal-use software

GAAP has allowed capitalization of internally developed software costs for decades, governed by guidance that predates the SaaS era but still applies to it. The rule, as PwC's accounting guidance lays out in detail, splits software development into three phases: preliminary project planning, application development, and post-implementation. Only costs incurred during the application development phase, once management has authorized and committed to funding the project and it's probable the software will be completed and used as intended, are eligible for capitalization.

FASB has continued to refine this test. As Deloitte's recent guidance describes, the standard hinges on a two-part judgment: management must have authorized the project, and completion must be "probable," a threshold that leaves real room for interpretation. Two finance teams looking at the identical project can reach different conclusions about when capitalization should start and how much of it applies.

Once a cost is capitalized, it doesn't disappear. It moves onto the balance sheet as an intangible asset and then gets amortized, spread out as a non-cash expense over the following several years. The immediate effect is that current-period expenses shrink and current-period profitability rises, even though cash left the company exactly the same way it would have under expensing.

What this does to gross margin and EBITDA

For a vertical SaaS company selling to accounting or professional services firms, this matters more than it does for many other software categories. These products tend to have long build cycles: compliance requirements, integrations with practice management and tax software, data migration tooling, and client-specific configuration all push development timelines out. Longer builds mean more engineering hours plausibly tied to a single "project," which means more dollars eligible for capitalization.

When a company capitalizes a large share of its engineering payroll, several things happen to the reported numbers at once:

• Cost of revenue looks lighter, because engineers building new features aren't counted as an operating cost the way support and infrastructure staff are.
• Gross margin rises, sometimes by ten or more percentage points, without any change in pricing, churn, or actual delivery cost.
• EBITDA improves, because the capitalized salaries never touch the expense line that EBITDA is calculated from, only the amortization does, and amortization is smoothed over years rather than concentrated in the period the work occurred.
• Free cash flow tells a different story than EBITDA does, because the cash still went out the door for payroll. This is the gap that experienced investors check first.

The result is a company that can look meaningfully more efficient on paper than a peer doing the exact same engineering work but expensing it as incurred. Two companies with identical burn rates, identical headcount, and identical products can report EBITDA margins that differ by twenty points purely because of where their accountants drew the capitalization line. This is a close cousin to the distortion covered in why cloud bills hide the real margin on a video software product: a real operating cost gets reclassified or deferred in a way that's technically defensible but changes what the headline metric actually communicates.

When it's a legitimate choice

Capitalization isn't inherently a red flag. A company building a genuinely new module, one with a defined scope, a committed budget, and a clear expectation that it will ship and generate revenue, is doing exactly what the accounting standard anticipates. Amortizing that cost over the years customers will actually use the feature is arguably a more accurate representation of when the value gets consumed than expensing it all in the quarter it was built.

The test worth applying, informally, is whether the capitalized work resembles a distinct, plannable project with a real chance of not shipping, versus the ordinary churn of maintaining and incrementally improving a live product. Bug fixes, performance tuning, minor UX changes, and the continuous small adjustments that come from customer feedback don't qualify. Neither does work on a feature that gets started, stalled, and quietly abandoned, though companies sometimes keep it on the balance sheet longer than they should before writing it off.

When it becomes a way to obscure burn

The practice turns into a problem when the capitalization policy becomes a lever for the metrics rather than a reflection of the underlying work. Warning signs include: a rising share of total engineering cost getting capitalized quarter over quarter with no corresponding change in what's actually being built; capitalized software balances that grow steadily but rarely see write-offs, even though anyone who has shipped software knows some fraction of ambitious projects gets scrapped or rebuilt; and management presenting EBITDA in investor materials without also showing free cash flow or the cash burn rate alongside it.

Founders comparing themselves to competitors on gross margin or EBITDA should ask what each company's capitalization policy actually is, not just what the number says. A rival reporting an 80% gross margin while expensing all engineering costs is running a fundamentally more efficient business than one hitting the same number by capitalizing half its dev team's salaries. Reported profitability and cash reality can diverge for years before anyone outside finance notices, which is exactly the risk this treatment creates.

The cleanest way to evaluate any vertical software company, including your own, is to look past EBITDA to cash burn and the size of the capitalized software asset relative to revenue. If that asset is growing faster than revenue is, the balance sheet is absorbing costs the income statement should be showing.