SaaS-era capitalization rules; written when software was a deterministic artifact built once and amortized over five to seven years; produce systematically wrong numbers on AI projects. Inference is variable cost on most customer query, not fixed infrastructure. Eval suites are intangible assets but most finance teams expense them as operational testing. Fine-tuned model weights have a 12 to 24-month useful life capped by the base-model release cadence, not the legacy 5 to 7-year horizon. Prompt registries, when versioned and tested, qualify as software-in-progress under ASC 350-40. CFOs running AI projects on the SaaS template overstate amortization, understate gross margin pressure, and misprice most renewal. This piece walks through where the SaaS rules break, what the underlying frameworks (ASC 350-40 and IAS 38) say, and a working accounting model for AI projects.
It is a spoke under the AI project economics manifesto, which argues that AI economics has shifted from feature cost to evaluation cost; and accounting treatments inherited from the feature-cost era misrepresent both sides of the income statement.
The SaaS capitalization template
The SaaS-era capitalization template; the one most enterprise CFOs run on a software project; looks like this. During the application development stage, internal labor and external contractor costs are capitalized under ASC 350-40 (US GAAP) or IAS 38 (IFRS). The capitalized cost lands on the balance sheet as an internal-use software asset and amortizes over a useful life of five to seven years. Hosting, ongoing operational costs, maintenance, and bug fixes are expensed as incurred.
Run that template against a typical SaaS project and the numbers behave. Sixty to eighty percent of project spend is capitalized. Gross margin runs in the 70 to 85 percent range. Operating expense covers hosting and ongoing engineering. The income statement looks like a software business.
Run the same template against an AI project and the numbers stop behaving. The pieces are the same; engineering labor, infrastructure, deployed system; but the cost dynamics differ in three structural ways. Inference cost scales with usage and behaves like cost of goods sold. Eval discipline is the production-quality function and is its own separately identifiable asset. The base model has a release cadence that caps the useful life of most derived asset.
The result is an income statement that looks broken under the SaaS template; gross margins compressed by inference, capitalized base amortizing too slowly against a structurally short-lived production system, opex understating the operational burden of evals and observability. The fix is not to force AI projects onto the SaaS template. It is to apply the underlying frameworks (ASC 350-40 and IAS 38) to the actual cost structure of an AI project.
Where AI economics break the template
Three breaks stand out.
The inference break. SaaS hosting cost is roughly fixed at the project level. Inference cost scales linearly (or super-linearly) with usage and behaves like a marginal cost of goods sold. Treating it as opex aggregated under “hosting” hides the gross-margin reality.
The eval break. SaaS testing is a development-stage cost. AI eval suites are production-stage operational artifacts that gate most model upgrade, most prompt revision, most new use case. The SaaS template either expenses eval cost (understating the asset) or capitalizes it as part of feature build (overstating depreciation against features that retire while the eval persists).
The release-cadence break. Legacy enterprise software amortizes over 5 to 7 years because the underlying platform is stable. Base models release on a 12 to 18-month cadence, and useful behavior of derived artifacts (fine-tuned weights, prompt families, RAG configurations) is capped by the base-model lifecycle. The 5 to 7-year amortization horizon is wrong; the underlying useful life is closer to 12 to 24 months.
Inference is COGS, not capex
Inference cost is the cost of running a customer query against the deployed model. It is paid on most query, scales with usage, and cannot be capitalized. Under ASC 350-40, capitalizable costs are those incurred during the application development stage. Inference is incurred at the operational stage on the marginal unit; structurally identical to cost of goods sold on a manufactured product or variable cost on a transactional service. It belongs in COGS alongside hosting and bandwidth.
The mistake CFOs make is to bundle inference into a generic “hosting” or “platform” line, and then to either capitalize a portion as part of the platform build or expense the entire line without breaking it out. Both approaches obscure gross margin. Inference deserves its own COGS line with a per-unit cost monitored as carefully as any other unit economic. The AI cost-per-action framework describes the unit economics model; the accounting treatment is the income-statement reflection.
The practical effect is that AI projects run with a cost-of-revenue line materially larger than the corresponding line on a SaaS product. Gross margins of 50 to 70 percent are common for AI products in 2026; the 80 to 85 percent SaaS gross margin floor does not hold. Treating that compression as a temporary inefficiency rather than a structural feature is the most common forecasting error among finance teams new to AI economics.
Eval suites are intangible assets
An eval suite; test cases, rubrics, scoring harness, CI integration; is a separately identifiable, controlled, future-economic-benefit-producing asset. It meets the IAS 38 criteria for an internally developed intangible asset. The development cost is capitalizable once technical feasibility is demonstrated.
Most finance teams expense the cost as part of QA or testing. The result is an undervalued balance sheet; the eval suite is doing structurally more work than a traditional test suite, gating most production change against a quality bar that defines the system’s value.
The treatment splits along useful life. The harness; runner, rubric scorer, CI integration; is durable infrastructure with a 3 to 5-year useful life. The test cases degrade as the domain shifts and as base models change; 12 to 24 months is more honest, with refresh on most base-model release cycle.
The discipline behind eval suites is detailed in stop budgeting AI projects in story points, budget them in eval runs and stop scoping AI projects in features, scope them in evaluations. Both argue that the eval is the work product. The accounting follows.
Fine-tuned weights have a short useful life
Fine-tuned weights from owned training data with documented procedure and reproducible results meet the IAS 38 criteria for an internally developed intangible asset. The debate is not whether; it is over useful life.
The naive answer defaults to the 5 to 7-year horizon used for legacy enterprise software. That answer is wrong. Fine-tuned weights inherit a useful life capped by the base model’s release cadence. When the base model is upgraded; on a 12 to 18-month cadence in 2026; derived weights lose much of their relative quality advantage and most teams refresh the fine-tune.
Capitalize the fine-tune. Amortize over 12 to 24 months. Refresh on the base-model release cycle. The capitalization treatment applied with the wrong useful life produces an income statement that looks too good in year one (under-amortizing a short-lived asset) and a balance sheet carrying impaired weights into years three and beyond. Year-end impairment review on AI intangibles is mandatory; the impairment trigger is most often the base-model release.
Prompt registries as software-in-progress
A production prompt registry; versioned, tested against an eval suite, integrated into deployment pipelines; is application-development output under ASC 350-40. The development cost (prompt engineering, eval integration, deployment plumbing) is capitalizable.
The line is technical feasibility. Drafting and exploration of prompts before the registry is structured; before there is a versioning scheme, an eval suite gating commits, a deployment integration; is operating expense. Once the registry is structured, subsequent prompt engineering is application-development cost.
The mistake teams make is to treat prompts as “configuration” in the loose sense; operational chatter, casually edited, not tracked. That treatment makes capitalization impossible because the asset is not separately identifiable. The fix is the same one the AI project economics manifesto argues for: structure the registry, version it, gate it on evals, integrate it into deployments. Once it is a real artifact, it is a real asset.
Useful life on prompts is short; 12 months or less for prompt families tied to a specific base model. Capitalize, amortize aggressively, refresh on each base-model release.
Observability is opex
Logging, tracing, monitoring, dashboards, alerting; observability infrastructure for an AI system; is operational instrumentation. It supports the running of the system and does not encode independent business value separable from the operating system itself. Under both ASC 350-40 and IAS 38, observability spend during the operational stage is operating expense. Edge cases exist; a custom observability platform with reusable application value can be capitalized; but the default treatment is opex.
The reason this matters is that observability cost on AI systems is materially higher than on SaaS systems. Trace storage on long-running agent runs, evaluation telemetry, prompt-registry change tracking, model-output sampling for post-hoc analysis; many of it adds up to a meaningful operating expense line that does not exist on a comparable SaaS product. Treating it as capitalizable hides the operating cost; expensing it correctly surfaces the operational burden.
A working AI project accounting model
Capitalized assets (balance sheet):
| Asset | Framework | Useful life | Notes |
|---|---|---|---|
| Eval harness | ASC 350-40 / IAS 38 | 3 to 5 years | Durable infrastructure |
| Eval test cases | IAS 38 | 12 to 24 months | Refresh on base-model release |
| Fine-tuned weights | IAS 38 | 12 to 24 months | Capped by base-model cadence |
| Prompt registry | ASC 350-40 | 12 months | Refresh on each base-model release |
| RAG corpus engineering | ASC 350-40 | 12 to 24 months | Capitalize structuring; expense ingest |
| Custom integration / agent skeleton | ASC 350-40 | 3 to 5 years | Standard internal-use software |
Operating expenses (income statement):
- Inference cost; COGS, separately tracked
- Hosting and bandwidth; COGS
- Observability infrastructure; operating expense
- Ongoing eval refreshes (when not material to capitalize); operating expense
- Operational prompt iteration (post-registry); split: structural changes capitalize, ad-hoc tuning expense
- Maintenance, bug fixes, on-call; operating expense
Practical capitalization ratio: 30 to 45 percent of total project spend, against the 60 to 80 percent typical for SaaS. The shift is driven by inference (now COGS rather than amortized infrastructure) and by the shorter useful lives on AI intangibles. CFOs forecasting on a SaaS template will overstate amortization and understate gross margin pressure.
The mature treatment is to run the AI project on its own template; capitalize what the frameworks support, expense what they don’t, accept the gross margin reality of inference, and forecast against the right amortization horizon. The pricing implications are in AI project pricing models, ranked by alignment with outcomes.
Frequently asked questions
Can inference cost be capitalized as part of internal-use software under ASC 350-40?
No. ASC 350-40 capitalizes costs incurred during the application development stage. Inference cost is incurred when an end user runs a query against the deployed system; a per-transaction operating cost, structurally identical to cost of goods sold on a marginal unit. Inference belongs in COGS, alongside hosting and bandwidth, not on the balance sheet.
Are eval suites intangible assets under IAS 38?
Yes, when they meet the IAS 38 criteria for separately identifiable intangible assets developed internally. An eval suite is identifiable (discrete test cases, rubrics, harness code), controlled by the entity, and produces probable future economic benefits (it gates most model upgrade, prompt revision, and new use case). The development cost meets IAS 38 capitalization criteria once technical feasibility is demonstrated.
Should fine-tuned model weights be capitalized?
Conditionally, with a much shorter useful life than legacy software. Fine-tuned weights from owned training data with reproducible results meet IAS 38 criteria. The debate is useful life: the base model is on a 12 to 18-month release cadence, so derived weights inherit a capped useful life. Capitalize, but amortize over 12 to 24 months; not the 5 to 7-year horizon used for legacy enterprise software.
Are prompt registries software-in-progress under ASC 350-40?
Yes, when the registry is a versioned, tested, documented production artifact. A registry integrated into deployment pipelines and gated by an eval suite is application-development output. The development cost meets ASC 350-40 capitalization criteria. Drafting and exploration before technical feasibility is operating expense.
Why is observability infrastructure expensed rather than capitalized?
Because observability is operational instrumentation, not a separately identifiable asset producing future economic benefits. Logging, tracing, monitoring, and dashboards support the running of the system. Under both ASC 350-40 and IAS 38, observability spend during the operational stage is operating expense.
What is the practical capex-to-opex ratio shift from SaaS to AI projects?
SaaS projects typically capitalize 60 to 80 percent of total project spend. AI projects invert toward 30 to 45 percent capitalized, because inference cost flows through COGS, and eval and prompt registries are smaller intangible-asset line items than full feature codebases. CFOs forecasting AI project economics on the SaaS template overstate amortization and understate gross margin pressure.
Does outcome-based AI pricing change capitalization treatment?
It changes recognition, not classification. The vendor’s cost to deliver; inference, eval runs, observability; remains COGS regardless of how the buyer is billed. The shift is on the revenue side: outcome-based revenue scales with outcomes, COGS scales with usage, and the gross margin equation becomes the central financial planning artifact.
What useful life should be assigned to capitalized eval test sets?
Three to five years for the harness; 12 to 24 months for the test cases. The harness; runner, rubric scorer, CI integration; is durable infrastructure. The test cases degrade as the domain shifts and as base models change. Refresh on each base-model release cycle.
Key takeaways
- The SaaS capitalization template; 60 to 80 percent capitalized, 5 to 7-year amortization, hosting as opex; produces structurally wrong numbers on AI projects.
- Inference is variable cost on most customer query. It belongs in COGS, separately tracked. AI gross margins of 50 to 70 percent are structural, not temporary.
- Eval suites meet the IAS 38 criteria for internally developed intangibles. The harness is durable (3 to 5-year useful life); the test cases are short-lived (12 to 24 months).
- Fine-tuned weights are capitalizable with a useful life capped by the base-model release cadence. Amortize over 12 to 24 months and impair on each base-model upgrade.
- Prompt registries qualify as software-in-progress under ASC 350-40 once versioned, tested, and integrated. Pre-structure drafting is operating expense.
- Observability is operating expense; instrumentation supporting the running of the system, not an independently valuable asset.
- The practical capitalization ratio for AI projects is 30 to 45 percent, materially below the SaaS template. The SaaS template overstates amortization and understates gross margin pressure.
Arthur Wandzel
