API costs: COGS, OpEx, or R&D?

Why classification matters

Classifying all AI API costs as software subscriptions is usually too blunt. Under UK GAAP, accounts should reflect the substance of the activity. In practical terms, API spend used to deliver a customer service often belongs in cost of sales. API spend used for internal productivity is normally operating expenditure. API spend used in development may be development cost — and only a subset may qualify for R&D tax relief.

For VC and PE-backed AI companies, this classification affects gross margin, contribution margin, pricing, customer profitability, and fundraising narratives. A company with heavy production inference costs should not hide those costs in general admin expenses if investors are relying on gross margin metrics to assess the business model.

The reverse problem is equally real. Companies that classify all API spend as COGS — when much of it is actually internal tooling or experimentation — distort their gross margin downwards and create reporting that misrepresents the underlying economics. Either direction of misclassification creates problems at fundraising, audit, or due diligence.

See ICAEW’s overview of FRS 102 at FRS 102 ICAEW.

The three-way test

Question 1 — COGS: is the API call directly tied to customer revenue? A chatbot product that incurs an API call every time a customer sends a message should normally treat that API cost as cost of sales. An internal marketing tool that drafts blog copy should normally be operating expenditure. The test is whether the spend scales with — and is necessary to deliver — customer-facing revenue.

Question 2 — variability: does the cost vary with customer usage? Usage-based API charges usually support COGS treatment where linked to customer delivery. Reserved capacity, minimum commitments, and prepaid credits complicate the timing of recognition, but not necessarily the underlying classification. The key is whether the cost is incurred because customers are being served.

Question 3 — R&D: is the API use part of resolving scientific or technological uncertainty? Most API usage will not qualify for R&D tax relief. It must be directly linked to a qualifying R&D project. Experimentation, evaluation, training data generation, or technical methodology development may qualify; ordinary product use almost never does.

See HMRC’s R&D software guidance for the qualifying-activity framework.

Four common AI business models

Direct-to-customer, per-use mapping. API calls map directly to customer activity, so classify production API costs as COGS. Track cost per customer, cost per workflow, and margin by customer segment. This is the cleanest case and the easiest to get right — though it requires customer-level usage tracking that many early-stage companies skip.

AI feature inside broader SaaS. Where AI is one feature within a wider product, the materiality of the API cost determines treatment. If immaterial relative to overall hosting and infrastructure cost, it may be acceptable to include API costs within broader hosting or COGS lines. If material, separate the account so product margins are visible. The judgement on materiality should be documented and revisited as AI usage scales.

Internal AI tooling. Classify as operating expenditure across the relevant function — marketing, sales, support, finance, operations, or internal knowledge management. The spend isn’t tied to customer delivery; it’s an internal productivity investment.

AI development and experimentation. Classify as development or R&D expenditure for accounts. For tax R&D purposes, apply the qualifying activity test — most API spend in this category won’t qualify, but some genuinely will. For accounts purposes, consider whether FRS 102 Section 18 intangible asset criteria are met. Most AI companies will expense rather than capitalise, but the question is worth asking explicitly. See ICAEW’s overview of intangible assets under FRS 102.

Practical accounting setup

A practical chart of accounts should separate production inference costs, R&D API usage, internal AI tooling, cloud production hosting, cloud R&D compute, prepaid API credits, and development software. Each of these has different tax treatment, different investor-reporting implications, and different operational signals. Lumping them together obscures every one of those signals.

Where possible, use separate billing projects or workspaces for production, staging, R&D, and internal teams. Most foundation model API providers (OpenAI, Anthropic, Google) support project-level billing separation. Setting this up early — when the company has one workspace and three customers — is dramatically easier than retrofitting it later when usage has scaled across multiple teams and use cases.

Customer-level tracking is important. Finance teams should reconcile monthly invoices to product usage, customer cohorts, token volumes, prepaid balances, and margin reporting. This is particularly important where API providers bill on different cycles, require prepaid credits, or include committed-use discounts. Without this reconciliation, gross margin reporting becomes guesswork.

VAT and cross-border considerations

Where a UK VAT-registered business buys services from suppliers outside the UK, the reverse charge will often apply. The company accounts for output VAT and, subject to its recovery position, claims input VAT on the same VAT return. The net cash effect is usually neutral for fully taxable businesses, but the entries must still be made correctly.

A common error is treating overseas SaaS and API invoices as outside the VAT process altogether. They often still need to be included under the reverse charge. Businesses with partial exemption or non-business activities may not recover the input VAT in full, which makes the entries non-trivial.

See HMRC’s VAT on services from abroad guidance, VAT Notice 741A on place of supply, and the partial exemption guidance for detail.

If one group company incurs API spend but another company uses the API to earn revenue or develop IP, the group should document which entity bears the cost, which entity controls the risk, and whether an intercompany recharge is required. Transfer pricing becomes important where a UK company pays for API usage that supports a US parent, or vice versa. The cost should sit where the economic benefit arises, not where the credit card was registered.

Escalate to specialist advice where API spend is material to gross margin or fundraising metrics, where there are multiple legal entities or cross-border teams, where the business is partially exempt for VAT or has mixed taxable and exempt supplies, where the company wants to include API costs in an R&D claim, or where the business is preparing for audit, due diligence, IPO-readiness, or investor reporting.

Sources