Compute infrastructure as capital expenditure.

Buying GPUs, servers, and related hardware is normally capital expenditure. Renting cloud GPU capacity on demand is normally revenue expenditure. AI companies face this issue more sharply than traditional SaaS companies because model training, evaluation, and inference can require expensive GPUs, networking, cooling, power, and colocation arrangements — all of which sit in different places on the capital-vs-revenue spectrum depending on how they’re acquired.

The distinction matters because capital expenditure isn’t deductible in the year it’s incurred. Instead, it’s relieved through capital allowances over time — though current rules around full expensing have made owned hardware significantly more tax-efficient than it was historically. Revenue expenditure, by contrast, is deductible in the period incurred. The tax timing difference between the two treatments is material at the scale most AI companies now operate.

GPUs, server chassis, racks, networking equipment, and other hardware used in the trade will normally be plant and machinery. Companies may be able to claim full expensing for new qualifying main-rate plant and machinery, or the Annual Investment Allowance. AIA is currently £1 million per year. Full expensing gives a 100% first-year allowance for qualifying new main-rate plant and machinery, with a 50% first-year allowance for qualifying special-rate expenditure.

Second-hand equipment does not qualify for full expensing, but may qualify for AIA or writing-down allowances. Special-rate pool issues can arise for integral features — including certain electrical systems, cooling, or power infrastructure in a data centre. The treatment depends on the specific facts, and the apportionment between main-rate and special-rate items in a complex installation can be material.

Disposal of GPUs can trigger balancing charges, which is especially relevant where there’s an active resale market and full expensing has been claimed. The current GPU resale market is genuinely active — H100s and similar high-end accelerators retain substantial residual value — so balancing charge exposure on disposal is real, not theoretical.

See HMRC’s full expensing guidance, the Annual Investment Allowance guidance, and the Capital allowances manual on AIA.

On-demand cloud GPU usage is usually a revenue expense, deducted in the period incurred. Reserved instances and committed-use discounts often create a prepayment or commitment, rather than ownership of an asset — the company has bought future capacity, not infrastructure.

Dedicated cloud capacity may raise lease-accounting questions where the customer controls an identified asset, though many standard cloud arrangements are service contracts rather than leases. The judgement turns on whether the contract gives the customer the right to direct the use of a specifically identified asset — a question that’s increasingly relevant as providers like CoreWeave offer dedicated GPU contracts that look more like leases than services.

Hybrid models should keep owned baseline infrastructure separate from cloud bursting. Record-keeping should separate production, R&D, internal tooling, and customer-specific usage — the same separation pattern that matters for API cost classification applies to compute spend.

Buying can make sense where utilisation is high, workloads are predictable, the hardware will be used over a sensible time horizon, capital is available, and the company has operational maturity. The cash impact of full expensing on a profitable company can make owned infrastructure significantly more attractive than the headline cost suggests.

Renting can make sense where workloads are variable, the company is pre-product-market fit, the hardware market is moving fast, or capital is better preserved for runway. For early-stage AI companies still finding their model architecture, the option value of renting often outweighs the unit-economics advantage of buying.

Financing options include asset finance, hire purchase, leasing, and specialist GPU finance. The legal form affects tax timing, accounting presentation, VAT treatment, and balance sheet treatment — and the right structure is rarely obvious from the headline terms. A specialist GPU finance arrangement that looks economically similar to a lease may be structurally different for tax purposes, and vice versa.

Treating reserved cloud prepayments as owned capital assets.

Failing to claim capital allowances on owned GPUs and servers.

Misclassifying colocation, power, and cooling costs — these can sit in different capital pools depending on the specific facts, and lumping them with the GPU spend loses material allowance value.

Missing reverse charge VAT on overseas cloud suppliers.

Forgetting balancing charges when GPUs are sold. Where full expensing has been claimed, disposal can produce a meaningful tax liability if not anticipated.

Confusing accounting capitalisation with tax relief — the two regimes operate independently, and capitalising for accounts doesn’t automatically generate or prevent tax allowances.

Where a US AI company has a UK subsidiary running training, the group must identify which entity owns the IP, bears the R&D risk, pays for compute, and earns the reward. The economic substance of the arrangement should drive the tax position, not the legal entity structure alone.

UK companies using US cloud providers should consider VAT reverse charge and corporation tax deductibility. Centralised compute arrangements need intercompany agreements and transfer pricing support — both for the cost allocation between entities and for the underlying commercial substance.

A common pattern: the US parent contracts directly with the cloud provider but the UK subsidiary actually uses the compute for training work. Without a defensible recharge arrangement, the UK entity loses the deduction for its actual operating costs and the US entity claims costs it isn’t really bearing economically. Both directions create exposure.

FRS 102 Section 18 is relevant where AI development creates an identifiable intangible asset. Capitalisation may be appropriate only where the company can demonstrate technical feasibility, intention and ability to complete and use or sell the asset, probable future economic benefits, adequate resources, and reliable measurement of expenditure.

Many AI companies expense development costs because technical feasibility or future benefits remain uncertain. This is usually the right answer for early-stage work where the model architecture, performance, or commercial viability is still being established. Capitalisation becomes more relevant once the product is technically stable, commercially viable, and clearly separable from other ongoing development.

Accounting capitalisation does not automatically prevent an R&D tax claim, but the R&D claim must still be based on qualifying activity and qualifying expenditure under the tax rules. The two regimes ask different questions: capitalisation is about whether the spend produces an identifiable asset; R&D tax relief is about whether the spend resolves scientific or technological uncertainty. The same project can meet one test but not the other.

Escalate to specialist advice where there’s material owned GPU hardware, cross-border compute spend or shared group infrastructure, asset finance or hire purchase arrangements, multi-entity structures with centralised compute, or where the business is preparing for IPO, audit, due diligence, or investor reporting.

See ICAEW’s overview of intangible assets under FRS 102 and HMRC’s R&D tax relief collection.