Why do software companies capitalize development costs instead of expensing them as R&D?
Software development is the most aggressively capitalized cost category in modern finance. The reason is structural: software companies live and die by their products, and their survival depends on relentless investment in R&D. But R&D is expensed immediately, hitting the income statement and depressing earnings.
The alternative, under accounting rules ASC 350-40 (Internal-Use Software) and ASC 985 (Software), is to capitalize development costs and amortize them over the software's useful life. For a company developing a mission-critical application, capitalizing the entire development cost and amortizing it over five years (instead of expensing it upfront) can transform a $50 million loss into a $10 million profit.
This is not inherently fraudulent. The accounting rule is designed to match costs with benefits: if software development generates value over multiple years, spreading the cost over those years is theoretically sound. But the practice is rife with abuse. Companies capitalize costs that should be expensed (research, conceptual design, failed projects). They capitalize high percentages of developer salaries (arguing developers spend 80% of time on capital projects, even when there's no evidence). They extend the useful lives of capitalized software far beyond their economically rational lifespans.
The forensic investor learns to spot these abuses and adjust reported earnings downward. The adjustment is often large enough to change the investment thesis.
Quick definition
Capitalized software refers to costs incurred to develop or acquire software (internal or external) that are capitalized as an asset on the balance sheet and amortized over the software's estimated useful life, rather than expensed immediately as research and development.
Key takeaways
- ASC 350-40 permits capitalization of software development costs, but only after a project has passed a technological feasibility threshold and has a probable future economic benefit.
- The research phase (conceptual design, exploration) must be expensed; only development-phase costs can be capitalized.
- The technological feasibility threshold is vague, allowing companies to interpret it aggressively (capitalizing early) or conservatively (expensing until production is near).
- Software companies often capitalize percentages of developer and management salaries, which is discretionary and difficult to audit.
- Capitalized software growth that outpaces revenue growth is a major red flag; it suggests the company is capitalizing more or at higher rates, or that previously capitalized software isn't generating expected returns.
- Amortization of capitalized software is often written into expense and difficult to isolate, hiding the true cost of development.
- Many software companies and tech firms appear more profitable than they truly are because capitalization masks the true cost of R&D.
How software capitalization works (and how it's abused)
Conservative approach:
A software company develops a new customer-relationship-management (CRM) application. It allocates developer time strictly:
- Research phase (2025 Q1–Q2): Conceptual design, market research, feasibility studies. All expensed as R&D. Cost: $2 million.
- Development phase (2025 Q3–2026 Q2): Once the project design is finalized and economic benefit is probable, the company begins capitalizing developer costs, testing costs, and documentation. The company tracks developer hours carefully, allocating only time spent on the CRM project, excluding overhead and management time. Cost: $6 million, capitalized as a software asset.
- Post-development (2026 Q3 onward): Training, deployment, bug fixes, and enhancement are expensed as maintenance (not capitalized further). Cost: $500K annually.
The capitalized asset of $6 million is amortized over five years at $1.2 million annually. Current earnings are affected by $2 million (research) + $1.2 million (first year's amortization) = $3.2 million in CRM-related costs.
Aggressive approach:
The same company uses wider discretion:
- Research phase: Limited to the first month of conceptual work. Everything else is considered development. Cost capitalized: $0.5 million.
- Development phase: Capitalized more broadly. The company capitalizes 80% of all developer and PM (project manager) time on projects in the "development portfolio" (broadly defined). The company also capitalizes a portion of infrastructure, support staff, and management overhead. Cost capitalized: $12 million.
- Post-development: Maintenance, patches, and "enhancements" are borderline. The company capitalizes any enhancement that adds features, expensing only "bug fixes." Cost capitalized: $2 million annually.
The capitalized asset is now $12 million, amortized over six years (vs the conservative five), at $2 million annually. Current earnings are affected by only $0.5 million (research) + $2 million (amortization) = $2.5 million, vs the conservative $3.2 million. The aggressive approach defers $0.7 million in costs, inflating earnings by 28%.
Over five years, if the company maintains this aggressive approach, the cumulative deferred costs compound. By year five, the capitalized software asset grows to $40–50 million, masking the true annual R&D investment of $8–10 million.
The forensic signals
1. Capitalized software growing faster than revenue. This is the single best red flag. Capitalized software should grow roughly in line with the business (or slower, as the company matures and consolidates products). If capitalized software grows 30% annually while revenue grows 10%, the company is capitalizing more aggressively than before. Flag this immediately.
2. Amortization of capitalized software as a percentage of revenue declining. Amortization is buried in operating expense (usually in R&D or general administrative). If you can isolate it, track it as a percentage of revenue. If it's declining, the company is either:
- Amortizing over longer periods (extending useful lives).
- Capitalizing newer software at higher rates (the asset base is growing faster than it's being amortized).
Both suggest aggressive capitalization.
3. A change in capitalization thresholds or useful lives. If the company lowers the threshold for what's capitalizable (e.g., "now we capitalize projects over $500K, down from $1 million"), or extends useful lives (from 3 years to 5 years), report it as an earnings inflater.
4. The lack of disclosure on capitalization policies. Transparency is a good sign. If a company discloses clearly that it capitalizes software development, the thresholds, the useful lives, and the percentage of developer time allocated to capital projects, you can assess aggressiveness. If the company is vague or silent, assume the worst.
5. Capitalized software with unclear future economic benefit. Capitalized software should be amortized based on expected useful life. But determining "useful life" for a technology asset is speculative. If the company is capitalizing software it developed 7 years ago and amortizing it over 10 years, ask: Is this software still generating economic value? Or is it legacy code the company is keeping on the books to avoid a write-off?
6. Failed or abandoned projects not written off. If a company capitalizes a software project that is later abandoned or merged with another product, the capitalized cost should be written off (impaired). If the company is slow to write off failed projects, it's inflating the asset base.
7. Insider transactions in software company stock during periods of aggressive capitalization. If executives are selling stock (or their stock options are vesting) while capitalization is ramping, that's a signal that insiders know the true profitability is weaker than reported.
The developer-allocation trap
Many software companies capitalize a percentage of developer salaries, arguing that developers spend a portion of their time on capital projects (new product development) and a portion on maintenance or non-capitalizable activities.
Conservative approach: Allocate based on detailed time tracking. Developers log hours to projects. Capital-project hours are capitalized; maintenance hours are expensed. Overhead (company meetings, training, admin) is allocated proportionally.
Aggressive approach: Allocate based on broad assumptions. "Developers spend 70% of time on capital projects and 30% on maintenance." This percentage is rarely verified. Once set, it's applied to the entire developer payroll (salaries + benefits + equipment), creating a large automatic allocation to capital.
The problem: developers almost never spend 70% of their time on new product development. They spend time on bug fixes, customer issues, security patches, and support—all of which should be expensed as maintenance. A 70% allocation is aggressive.
To spot this, look for:
- Developer headcount growth that outpaces revenue growth. If you're hiring developers faster than revenue is growing, where are they working? If they're all being allocated to capital projects, that's aggressive.
- Lack of detail on developer allocation methodology. If the company says "We capitalize a percentage of developer costs" without specifying the percentage or how it's determined, that's a red flag.
- Changes in the developer allocation percentage. If the company raises the allocation from 60% to 75%, that's a change that inflates earnings without any operational change.
Useful-life assumptions and the amortization game
Capitalized software is amortized over its estimated "useful life"—typically 3–7 years for commercial software, but sometimes longer for enterprise applications.
The useful life is a judgment call. A company might argue that its core CRM application will be useful for 7 years, so it amortizes over 7 years. But technology depreciation is fast: a software application that's state-of-the-art today may be obsolete in 3–4 years. By extending the useful life to 7 years, the company cuts annual amortization by more than half (compared to a 3-year life), inflating earnings.
Red flag: If your software company is amortizing core products over 5–7 years, ask whether that's realistic. Compare to the company's actual history. Do products really stay competitive for 7 years? Or do they need major rewrites every 3–4 years?
The decision tree guides the forensic analysis.
Real-world case: Activision Blizzard and capitalized development
Activision Blizzard, the video game company, uses capitalized software extensively because game development is inherently capital-intensive. Developing a major game title can cost $100 million or more and take two to three years.
Activision capitalizes game development costs and amortizes them over the game's expected revenue-generating life (typically 5–7 years for major titles, longer for franchises like Call of Duty). This is defensible; games genuinely generate revenue over multiple years.
But forensic analysts watch for:
- When major game titles flop. If a capitalized game underperforms, Activision takes an impairment charge, writing down the asset. Frequent impairments suggest the company's useful-life estimates are overly optimistic.
- Shifts in the useful lives. Activision extends useful lives for successful franchises (Call of Duty's useful life extends as long as the franchise generates revenue). This is reasonable, but it inflates earnings in mature franchise years when development cost is low but amortization is also minimal.
- Capitalization of live-service updates. For games that monetize through continuous updates and cosmetic items (like Call of Duty: Warzone), determining what's capitalizable (new content generation) vs expensable (maintenance, server costs) is murky. Aggressive companies capitalize more content as "feature development" rather than "operational maintenance."
Investors in game-development companies should adjust for the impact of capitalization on reported earnings. A company might report $1 billion in adjusted EBITDA, but if $200 million of that is offset by capitalized game development, the true sustainable earnings are lower.
Common mistakes in analyzing software capitalization
Assuming all capitalized software is fraud. It's not. Legitimate software development should be capitalized (up to a point). The issue is aggressive capitalization (capitalizing too much, at too high rates, over too long periods).
Not adjusting earnings at all. Some investors ignore capitalization entirely, saying "the company manages R&D separately; capitalization doesn't matter." This is wrong. Capitalization materially affects reported profitability. If you're valuing the company on earnings, you need to understand how much of that earnings is inflated by capitalization deferral.
Comparing across industries without context. Software companies capitalize more than hardware companies (because software development is more discretionary). Don't conclude a software company is aggressive just because capitalization is higher than a hardware peer. Compare to other software companies.
Focusing only on capitalized software, ignoring depreciation. Capitalized software without amortization (or with very slow amortization) is a sign of aggressive useful-life assumptions. Analyze both the numerator (capitalization) and denominator (amortization).
FAQ
Q: How do I estimate what earnings should be if the company weren't capitalizing software? A: Start with the capitalized software balance on the balance sheet. Estimate the weighted-average useful life (if disclosed, use that; if not, assume 4 years). Divide the balance by the useful life to estimate the annual amortization that's baked into the current P&L. Then add back to operating income the capitalization that occurred this year (reduce it by the amortization recognized). The difference between reported EBITDA and adjusted EBITDA (removing the capitalization effect) is your normalization. It's an estimate, but it's disciplined.
Q: If the company discloses capitalized software in the footnotes, is it safe to assume it's not aggressive? A: Disclosure is good (transparency is always better), but it doesn't guarantee conservative treatment. Read the policy carefully. If the company says it capitalizes software development costs "as applicable," that's vague. If it says "we capitalize costs incurred after technological feasibility is established, using a 70% developer allocation and a 5-year useful life," you can assess aggressiveness against peers.
Q: What's a "normal" level of capitalized software as a percentage of revenue? A: For a mature software company, capitalized software should be 5–15% of annual revenue (roughly 1–3 years of revenue on the balance sheet at any time). If it's above 20%, the company is capitalizing aggressively. If it's below 3%, the company is expensing most R&D (very conservative).
Q: Should I use non-GAAP "adjusted EBITDA" to avoid the capitalization issue? A: Non-GAAP metrics sometimes exclude capitalization effects, but not always. Read the reconciliation carefully. Some companies add back capitalization; others ignore it. You need to make your own adjustment if management doesn't.
Q: Is software capitalization better or worse than a company with low R&D? A: It's neither inherently better nor worse; it's just different. A low-R&D company has lower reported R&D expense and higher reported profitability (all else equal). But it may be investing less in future products and facing competitive risk. A high-capitalization software company is deferring R&D costs and reporting higher profitability, but it carries more balance-sheet risk (capitalized assets can be impaired). As an investor, adjust for the difference and decide what type of business model you prefer.
Related concepts
- Capitalising vs expensing: The broader principle. Chapter 13, article 5.
- R&D as an investment: Understanding research and development as a strategic investment. Chapter 2, article 10.
- Impairment of intangible assets: When capitalized software is written down. Chapter 3, article 11.
- GAAP vs non-GAAP metrics: Understanding adjusted earnings. Chapter 11, article 2.
- R&D capitalisation under IFRS: An international comparison. Chapter 13, article 7.
Summary
Software capitalization is a pervasive and powerful earnings inflater in the technology sector. The principle—that software development generates value over multiple years and should be amortized rather than expensed upfront—is sound. But in practice, companies exploit the discretion in defining the research phase, capitalizing percentages of developer time, and extending useful lives.
The forensic signals are: capitalized software growing faster than revenue, amortization as a percentage of revenue declining, policy changes toward more aggressive treatment, and vague or absent disclosure of capitalization methodology.
A forensic investor adjusts reported earnings by estimating the true R&D cost (capitalized plus expensed) and compares to peer companies. The adjustment is often large—10–30% of reported earnings—and changes the investment thesis.
Software companies that are aggressive in capitalization appear more profitable than they truly are. When you adjust for capitalization deferral, the earnings are often more modest and the valuation multiple should be lower. Conversely, companies that are conservative in capitalization (expensing most R&D) appear less profitable but are often more transparent and carry less balance-sheet risk.
The key is discipline: read the policies, compare to peers, track trends, and adjust your earnings estimates accordingly. Capitalization is a lever management can pull to inflate earnings, and forensic investors stay alert for its abuse.