R&D Capitalization: Where Software Accounting Hides the Optics

Two software companies spend the same dollar on engineers. One reports it as an expense and posts an operating loss. The other capitalizes it onto the balance sheet and reports a profit. Same cash out the door. Different income statements. This is the single most important accounting choice in software, and most retail decks gloss right over it.

If you only learn one thing from this post: when a company tells you about "adjusted operating margin," your first question should be how much R&D and internal-use software they capitalized in the period — and whether that number is growing faster than revenue.

The GAAP rules that create the optics gap

There are two relevant rulebooks, and both leave room for judgment.

ASC 985-20 governs software developed for sale (think: a packaged product, a SaaS platform sold to customers). The rule says you expense everything until "technological feasibility" is established, then you can capitalize development costs until the product is generally available. "Technological feasibility" is a squishy threshold — some companies declare it early and capitalize aggressively; others declare it late or never bother.

ASC 350-40 governs internal-use software — the systems a company builds to run itself (billing platforms, internal tools, even some customer-facing infrastructure if it's considered internal). Costs in the "application development stage" get capitalized; planning and post-implementation costs get expensed. The dividing lines are, again, judgment calls.

Net effect: two reasonable CFOs looking at the same engineering team can defensibly capitalize wildly different percentages of their payroll. One reports those salaries as opex. The other parks them on the balance sheet as an intangible asset and amortizes them over three to five years.

IFRS (IAS 38) is even more permissive — it requires capitalization once criteria are met, which is part of why cross-listed comparisons get messy.

How capitalized software flatters the P&L

The mechanics are straightforward but worth walking through, because the effect compounds.

Suppose a company spends $100M on engineers in year one. If it expenses all of it, opex goes up by $100M. If it capitalizes $60M and amortizes over five years, only $40M hits opex this year plus $12M of amortization — call it $52M. Reported operating income just improved by $48M, and not a dime of cash changed hands differently.

It gets better (or worse, depending on your seat). In year two, the company spends another $100M and capitalizes $60M again. Opex is now $40M + $12M (year-one amort) + $12M (year-two amort) = $64M. Still well below the $100M cash cost. The gap between reported opex and cash spending persists as long as capitalization stays elevated.

This is why the cash flow statement is your friend. Look at "capitalized software development" or "additions to internal-use software" inside investing activities. That's real cash leaving the business that never touched the income statement.

A reusable checklist for spotting aggressive software accounting

When you pick up a 10-K, run this quick scan:

1. Find the capitalized software line. It lives in the cash flow statement (investing section) and in the intangible assets footnote. Note both the period addition and the gross balance.
2. Compute the capitalization ratio. Capitalized software additions divided by total R&D spend (capitalized + expensed). Anything north of 20-30% deserves a closer look. A ratio that's rising year over year while revenue growth slows is a yellow flag — management may be propping up margins.
3. Check the amortization life. Three years is conservative. Five years is standard. Seven or more years on a fast-moving SaaS product is aggressive — you're being told this code has a long useful life, in an industry where tech stacks get rewritten constantly.
4. Compare to free cash flow. If GAAP operating income is much higher than free cash flow minus stock-based compensation, capitalization is usually a big part of why. The cash doesn't lie.
5. Read the accounting policy footnote. Look for language about "technological feasibility" and what triggers it. Vague policies that capitalize broadly are a tell.

Illustrative reference points: large enterprise software companies capitalize a meaningful slice of development costs; many pure-play SaaS companies capitalize relatively little of their product R&D but capitalize substantial internal-use software for their cloud infrastructure. Neither approach is wrong — but the comparability problem is real.

Adjusting earnings so peer comparisons actually work

The practical fix when you're comparing two software companies: build a "cash R&D" version of operating income.

Start with reported operating income. Add back amortization of capitalized software (it's a non-cash charge). Subtract the period's capitalized software additions (real cash spending the P&L missed). What you're left with is operating income as if the company had expensed everything — closer to a true economic margin.

Do this for both companies you're comparing. The gap often narrows dramatically, and sometimes the "more profitable" company is actually the less profitable one once you neutralize the accounting choice. This is exactly the adjustment Aswath Damodaran has written about for two decades, and it's still underused by the sell side.

What to watch next

• Pull the cash flow statement on any software name you own and find the capitalized software line. Note the dollar amount and the trend over three years.
• Compute the capitalization ratio (capitalized / total R&D). Flag anything above 25% or anything rising faster than revenue.
• Build the cash-R&D adjusted operating margin for at least two peers you're comparing. The ranking may surprise you.
• Re-read the critical accounting estimates section of the latest 10-K for the software policy language — any change in estimate (useful life, capitalization threshold) is a material signal worth a full read.