Foundation models are becoming infrastructure rather than products, and that shift is changing how AI projects sit in the income statement and balance sheet. The 2010s SaaS shift moved enterprise software from capitalized perpetual licenses to expensed subscription opex. AI is driving a similar shift, but at a different boundary: the intelligence layer (inference) is opex by default, while the application layer that wraps the model; eval suite, fine-tuning artifacts, prompt registry, integration code; is capitalizable under standard internal-use software accounting. CFOs that understand the new boundary capture the EBITDA benefit; CFOs that treat AI as fully opex (or fully capex) miss in opposite directions and produce financial statements that do not match the underlying economics. This piece decomposes the SaaS analogy, names what to capitalize and what to expense in the AI stack, and gives the depreciation schedule and impairment risks that AI accounting needs to handle.
This is a spoke under the AI project economics manifesto. The manifesto argues that AI economics requires evaluation-cost framing rather than feature-cost framing. The capex/opex split is the financial-statement layer of that framing; how the cost categories show up in finance’s books across multiple years.
The 2010s SaaS analogy
The 2010s saw a major capex/opex shift in enterprise software. Pre-2010, enterprise software was a perpetual license; a one-time capitalized purchase, depreciated over 3 to 5 years, with maintenance fees expensed. Post-2010, enterprise software became subscription; expensed in the period consumed, with no capitalized asset on the balance sheet.
The shift had two financial-statement effects. First, EBITDA pressure: subscription opex hit the income statement immediately rather than being smoothed across years through depreciation. Second, balance-sheet thinning: software stopped showing up as an intangible asset, replaced by a contractual obligation in the form of multi-year subscription commitments.
CFOs adjusted. Multiples for SaaS companies rose because the business model was more predictable; multiples for legacy software companies compressed. The shift was net-positive for the SaaS category and net-negative for the perpetual-license category, but it required CFOs to learn a new analytical apparatus.
Why the analogy is partly wrong
The AI capex/opex shift is similar in structure but different in detail. SaaS replaced “buy the software” with “rent the software”; the entire product became opex. AI is more granular: the intelligence layer is rented, but the layer above it (the application built on top) is still owned and capitalizable.
The reason: the foundation model is not the AI project. The foundation model is a substrate that the project consumes via API. The project itself is the eval suite, the fine-tuning artifacts, the prompt registry, the integration code, the application logic. These are buyer-owned, internally-used software assets that meet the standard test for capitalization under US GAAP ASC 350-40 (internal-use software).
The mistake CFOs make when extrapolating from the SaaS analogy: treating the entire AI project as opex because the model is rented. This understates the capitalizable portion (typically 40 to 60 percent of build cost) and produces an EBITDA hit that does not match the economics. The correct framing recognizes the bifurcation: rented intelligence layer (opex), owned application layer (capex).
The new capex/opex boundary
The boundary runs through the project at a specific seam. Below the seam: the model itself, accessed via inference API, paid per token. Above the seam: everything the buyer’s team builds to make the model useful for the buyer’s task.
| Layer | Treatment | Example |
|---|---|---|
| Foundation model | Opex (inference) | API calls to GPT, Claude, Gemini |
| Reserved-capacity inference | Amortized opex | Multi-year prepaid inference contract |
| Fine-tuning compute | Capex (asset cost basis) | GPU hours to produce a fine-tuned model |
| Fine-tuned model artifact | Capex (capitalized) | Buyer-owned fine-tuned weights |
| Eval suite | Capex | Test set, harness, scoring rubrics |
| Prompt registry | Capex | Versioned prompts, approval workflow |
| Application code | Capex | Integration, routing, business logic |
| Observability infrastructure | Capex (build), opex (subscription) | Tracing, dashboards, on-call |
| Inference (production) | Opex | Per-token cost from upstream provider |
| Retainer | Opex | Ongoing engineering and triage |
The boundary is at the model. The model is rented; everything above it is owned. Two clean rules: if it is the buyer’s asset producing future benefit, capitalize. If it is consumption of someone else’s service, expense.
What to capitalize
Four categories are reliably capitalizable in an AI project:
Engineering build for the application layer. Standard internal-use software treatment. Costs incurred during the application development stage (after preliminary project stage, before post-implementation stage) are capitalized. Typical AI project: $200K to $400K of $500K total build is in this category.
Eval suite construction. The test set, the eval harness, the scoring rubrics, the threshold-locking process. These are buyer-owned software assets that produce future benefit (continuous quality enforcement, regression detection). Typical: $40K to $100K of build cost, capitalized.
Fine-tuning artifacts and the compute used to produce them. A fine-tuned model that the buyer owns and uses internally is a capitalizable software asset. The training compute (GPU hours) is part of the cost basis. Typical: $20K to $200K depending on artifact complexity. The AI project distillation case covers when fine-tuning artifacts are economically attractive; the capex treatment makes them more attractive than the cash-flow numbers alone suggest.
Prompt registry build. The schema, the versioning, the deployment integration, the audit trail. These are buyer-owned software assets. Typical: $10K to $25K of build cost, capitalized.
The total capex-eligible portion of a typical $500K AI project is $250K to $350K; meaningfully more than zero, meaningfully less than 100 percent. The mid-range capitalization rate of 50 to 60 percent of build cost is the right planning assumption for most enterprise AI projects in 2026.
What to expense
Four categories are reliably opex:
Inference. Per-token cost paid to the upstream model provider. Consumed in the period, expensed in the period. The exception (reserved-capacity multi-year prepayment) is amortized rather than fully expensed but functions as opex. The why-AI-inference-belongs-in-COGS piece covers the income-statement placement question separately.
Retainer. Ongoing engineering, triage, eval maintenance. Recurring service consumption, expensed as incurred.
Subscription tooling. Observability subscriptions, eval-platform subscriptions, prompt-management subscriptions. Standard SaaS opex treatment.
Ongoing eval maintenance. The expansion and refinement of the eval suite after initial construction. Expensed as incurred because it is a continuous activity rather than the production of a discrete asset.
Depreciation and impairment
Capitalized AI assets need a depreciation schedule and an impairment policy.
Depreciation schedule. Standard treatment under US GAAP ASC 350-40 is 3 to 5 years on a straight-line basis. Some teams use 2 to 3 years to reflect faster model deprecation, which is defensible if the underlying model architecture is expected to be replaced within that window. The why-your-AI-project-budget-should-have-a-model-deprecation-reserve piece covers the rationale for shorter useful-life assumptions.
Impairment risk. Capitalized assets that lose value require impairment write-downs that hit the income statement abruptly. AI-specific impairment triggers:
- A foundation model that the asset’s prompts and fine-tuning are built around is deprecated, requiring full reconstruction
- An eval suite is invalidated by a major prompt revision or use-case change
- A fine-tuned artifact is rendered obsolete by a frontier upgrade that no longer benefits from the same fine-tuning approach
Impairment policy: review at least annually, more frequently in years 1-2 of any AI project where model deprecation cadence is high. Document the impairment test in the year-end audit package.
EBITDA implications
The capex/opex split affects EBITDA materially. Worked example for a $500K AI project with $300K capex-eligible build:
| Metric | Full opex | Correct capex/opex split |
|---|---|---|
| Year-1 EBITDA impact | -$500K | -$200K (opex only) |
| Year-1 capex | $0 | $300K |
| Year-1 depreciation | $0 | -$60K to -$100K |
| Year-1 net income impact | -$500K | -$260K to -$300K |
| Cash flow impact | -$500K | -$500K |
The cash flow is identical (the project costs $500K in cash either way). The income-statement effects diverge significantly. EBITDA is $300K higher under correct capex/opex split, which moves valuation multiples for capital-intensive AI buyers.
The why-AI-projects-should-be-capitalized-differently-than-SaaS-projects piece covers the depreciation-period question in more detail. The the-ai-project-rule-of-40-adjusted-for-inference-cost piece covers how the split interacts with operating-margin metrics.
Frequently asked questions
How is the SaaS capex/opex shift relevant to AI?
The 2010s shift moved enterprise software from capitalized perpetual licenses to expensed subscription opex. AI is now driving a similar shift inside the software category: model access via inference is opex, while the eval suite, fine-tuning artifacts, and prompt registry that wrap the model are capex-eligible. The categories are different from SaaS but the framing question is the same.
What in an AI project is capitalizable?
Engineering build cost for the application layer, eval suite construction, fine-tuning artifacts produced for internal use, and prompt registry build. These are typically depreciated over 3 to 5 years under standard internal-use software accounting (US GAAP ASC 350-40 and similar IFRS treatment). Inference, retainer, and ongoing eval maintenance are expensed.
Should inference cost be capex or opex?
Opex, in nearly many cases. Inference is consumption-based access to a model that is not the buyer’s asset. It functions like cloud compute or SaaS access fees and is expensed in the period consumed. The exception is reserved-capacity inference that prepays for a multi-year window, which may be amortized over the prepayment period.
Are fine-tuning costs capex?
The output (the fine-tuned model artifact) is capex-eligible if the buyer owns the artifact and uses it internally. The training compute (GPU hours to produce the artifact) is typically capitalized as part of the asset’s cost basis. The ongoing inference against the artifact is opex. The treatment is similar to internal-use software: building the asset is capitalized, running it is expensed.
What’s the depreciation schedule for an AI project?
Typically 3 to 5 years on a straight-line basis under US GAAP ASC 350-40. Some teams use 2 to 3 years to reflect faster model deprecation, which is defensible if the underlying model architecture is expected to be replaced within that window. The schedule should be set at kickoff and consistent across the AI portfolio.
How does the capex/opex shift affect EBITDA?
Significantly. Capitalized AI build cost flows to depreciation rather than operating expense, lifting EBITDA in the period. For a $500K AI project with $300K capex-eligible build, EBITDA in year one is $300K higher than under full-opex treatment, while depreciation in years one through three each carries roughly $100K. The shift affects valuation multiples, not just cash flow.
What’s the risk of over-capitalizing AI projects?
Two risks. First, capitalized assets that lose value (model deprecation, prompt obsolescence, eval suite invalidation) require impairment write-downs that hit the income statement abruptly. Second, auditors apply increasing scrutiny to AI capitalization claims; aggressive capitalization that does not meet the “probable future benefit” test produces restatement during audit.
How is the AI capex/opex split different from traditional software?
Traditional software: build cost capitalized, license fees expensed. AI: build cost capitalized similarly, but the underlying intelligence is rented (inference) rather than purchased (license). The intelligence layer is opex; the wrapping layer (eval, prompt registry, app integration) is capex. The split happens at a different boundary than traditional software.
When should AI projects be treated as fully opex?
When the build cost is small relative to ongoing inference (heavy-usage products), when the asset’s expected useful life is under 12 months (rapid-iteration features), or when the project is clearly an experiment without committed long-term use. Forcing capitalization on these projects creates accounting work without material EBITDA benefit.
Does the capex/opex split affect contract structure?
Yes. Contracts that bundle build, retainer, and inference into a single line make the capex split harder. Contracts that separate the build SOW (capitalizable), the retainer (opex), and the inference pass-through (opex) make the accounting clean. Buyers pursuing capitalization should require this separation in the contract.
Key takeaways
- The AI capex/opex boundary runs through the project at the model: intelligence layer (inference) is opex, application layer (eval suite, fine-tuning, prompt registry, integration) is capex.
- Typical capitalization rate for an enterprise AI project is 50 to 60 percent of build cost; materially more than zero and meaningfully less than 100 percent.
- Depreciation schedule under US GAAP ASC 350-40 is 3 to 5 years straight-line, with shorter periods (2 to 3 years) defensible for projects where model deprecation cadence is high.
- Impairment risks are real and AI-specific: model deprecation, prompt obsolescence, fine-tuning invalidation can each trigger write-downs that hit the income statement abruptly.
- Contract structure matters: contracts that separate build SOW (capex), retainer (opex), and inference pass-through (opex) make the accounting clean; bundled contracts make capitalization harder to defend.
The capex/opex shift for AI is a smaller story than the 2010s SaaS shift in headline terms but a more nuanced one in detail. CFOs who place the boundary correctly capture the EBITDA benefit, defend the capitalization to auditors, and produce financial statements that match the economics. CFOs who treat AI as fully opex miss the capex benefit; CFOs who treat it as fully capex face impairment surprises. The boundary is at the model; and getting it right is a 4 to 8 hour conversation with the controller, not a strategic transformation.
Arthur Wandzel
