Two banks deploy the same AI capability. One runs it on a cloud model API and a SaaS agent product. The other runs it on its own GPUs with an on-premises platform. The total cost over five years might be similar. Their financial statements will look quite different.
The cloud deployment is almost entirely operating expense, a monthly service charge that hits EBITDA straight away. The on-premises deployment is largely capital: hardware on the balance sheet, some software capitalised, depreciation and amortisation spread over several years. That changes budget approval routes, EBITDA, return-on-capital metrics and how the business case reads to a board.
This guide goes line by line through how on-premises AI costs are typically classified. It is not accounting advice. Classification depends on contract terms and facts, and the final call belongs to your finance team and auditors. The point is to show where the judgement calls are, so the AI programme can produce the evidence finance will need.
The line-by-line view
| Cost item | Typical IFRS treatment | Typical US GAAP treatment | Watch-outs |
|---|---|---|---|
| GPU servers, storage, networking | Property, plant and equipment (IAS 16), depreciated | Property, plant and equipment (ASC 360), depreciated | Useful life is contested for AI hardware |
| Leased hardware, colocation | Assess under IFRS 16; may give a right-of-use asset | Assess under ASC 842; may give a right-of-use asset | Colocation of a dedicated cage may contain a lease; shared services may not |
| Perpetual software licence, installed on premises | Intangible asset (IAS 38) | Internal-use software (ASC 350-40) | Separate maintenance and support, which is expensed |
| Term licence, installed on premises | Often an intangible asset with a liability; turns on contract terms | Often an intangible asset with a liability; turns on contract terms | Not automatically a subscription expense |
| Cloud and SaaS AI, model API tokens | Service expense | Service expense | Usage-based, so volume drives the line |
| SaaS configuration and implementation | Generally expensed (IFRIC agenda decision, 2021) | Capitalised and amortised over hosting term (ASU 2018-15) | A genuine IFRS–US GAAP divergence |
| Internal build: agents, workflows, integrations | Research expensed; development capitalised once IAS 38 criteria are met | Today, capitalised in the application-development stage; under ASU 2025-06, once the probable-to-complete threshold is met | Most AI pilots fail these tests |
| Data preparation, conversion, labelling | Generally expensed, unless directly attributable to a qualifying development asset | Data conversion expensed, except software built to automate it | Often the largest hidden line |
| Staff training, change management | Expensed | Expensed | |
| Power, cooling, operations staff, support renewals | Expensed | Expensed |
The hardware lines are the most familiar and the least controversial in principle. In practice, the useful life assumption is heavily debated for AI accelerators. Our guide to buying, leasing or colocating GPU capacity sets out the range in use and why it matters to the business case.
Where AI creates new judgement calls
Software capitalisation rules were written with conventional development projects in mind. AI programmes test them in four places.
Pilots are usually research. IAS 38 requires research-phase expenditure to be expensed. Development costs are capitalised only once six criteria are met: technical feasibility, intention to complete, ability to use, probable future benefits, adequate resources, and reliable measurement. US GAAP moved in a similar direction. ASU 2025-06, issued in September 2025, replaced the old project-stage model with a threshold. Capitalisation starts once management has authorised and committed funding and it is probable the project will be completed and used as intended. It is deferred while there is significant development uncertainty, including where functions are novel, unique or unproven, or where performance requirements are still being defined or significantly revised. That describes most AI pilots. It is effective for annual periods beginning after 15 December 2027, with early adoption permitted. Until an entity adopts it, the older stage model applies.
The pilot-to-production boundary is also a capitalisation boundary. The evidence that shows an agent is ready for production can also support technical feasibility and probable completion: evaluation results against a fixed test set, a signed-off design, a funded rollout. If the AI team keeps that evidence, finance can point to when the criteria were met. If it does not, the conservative answer is to expense everything. The cost difference between pilot and production has an accounting side as well as an operational one.
Fine-tuning is a grey area. Fine-tuning an open-weight model on proprietary data produces something the organisation controls and uses. Exploratory tuning runs look like research. A tuning pipeline that feeds a production model with defined acceptance criteria looks more like development. Expect your auditors to ask which one each run was, and keep run records that answer the question.
Useful lives are short. A capitalised agent workflow, integration or tuned model is amortised over its expected useful life. In AI, that life is set by replacement cycles, and those are fast. Base the life on your own model versioning and retirement history, not on a default software life. When a model or workflow is retired early, expect an impairment test.
The IFRS–US GAAP divergence on cloud
The table’s most surprising line is SaaS implementation. Under IFRS, the IFRS Interpretations Committee’s 2021 agenda decision concluded that configuring or customising a supplier’s cloud software usually gives the customer no asset it controls. Those costs are generally expensed as the related services are received. The exception is where the work creates separate code the customer controls. Under US GAAP, ASU 2018-15 takes the opposite approach for hosting arrangements that are service contracts: implementation costs are capitalised under the internal-use software rules and amortised over the hosting term.
This matters for multinational groups and for any comparison of cloud against on-premises AI. The same implementation project can reach EBITDA immediately in IFRS accounts and gradually in US GAAP accounts. A cost comparison built in one framework may not survive translation into the other.
What finance should ask the AI programme for
Classification quality depends on records the AI team controls. Agree on these at the start, not at year-end:
- Time recorded by activity, separating exploration, build, data preparation, training and operations.
- Gate evidence: design approvals, evaluation results and funding decisions, dated, so the capitalisation start date is defensible.
- Contract structure that separates licence, support, implementation services and hardware, so each can be classified on its own terms.
- An asset register for AI components covering models, agents and integrations, with owners, versions and planned retirement dates.
- Retirement records when a model or workflow is replaced, to trigger impairment review.
Do not let accounting pick the architecture
Capital treatment can make on-premises AI look better on an EBITDA basis, and operating treatment can make cloud look lighter on the balance sheet. Neither changes the cash. The architecture decision should rest on data control, workload profile, total cost and risk, as covered in the CFO’s guide to enterprise AI spending and the on-premise AI TCO guide. Accounting explains how the chosen answer will be reported. It should not choose the answer.
How VDF AI fits
VDF AI runs on infrastructure the customer owns or controls, so hardware stays a separate, visible line. On-premises deployments are licensed as a fixed-price annual capacity band, not metered per token, which keeps the platform line predictable and separate from model and infrastructure costs. The flat versus token pricing page explains the difference. Classification of that licence remains a matter for your auditors. The platform’s version history, evaluation records and audit trail also supply the gate and retirement evidence described above.
Sources and further reading
- FASB — ASU 2025-06, Targeted Improvements to the Accounting for Internal-Use Software (Subtopic 350-40)
- FASB — ASU 2018-15, Customer’s Accounting for Implementation Costs Incurred in a Cloud Computing Arrangement That Is a Service Contract
- IFRS Foundation — Configuration or Customisation Costs in a Cloud Computing Arrangement (IAS 38)
- Grant Thornton — IFRS Viewpoint: Configuration or customisation costs in a cloud computing arrangement
- Chargeback and Showback for a Shared On-Prem AI Platform
- The Business Case for Private AI: How CIOs Build the Board-Level ROI Argument
Building the business case for on-premises AI? Talk to us about the cost lines, and the records finance will ask for.