CSRD 2026: Why Your LLM API Spend Is Scope 3 Category 1 (and How to Report It)

Many engineering and finance teams do not realise it, but the invoices you pay to OpenAI, Anthropic, Mistral, and Google for API access are almost certainly Scope 3 Category 1 emissions under ESRS E1 and the GHG Protocol. For financial year 2025 — reports due in 2026 — large EU companies must disclose these emissions if they are material. This article explains the reasoning, the calculation method, and what data you need to collect now.

This is not legal or accounting advice. CSRD boundary and materiality decisions require a qualified sustainability professional or auditor.

Why LLM API expenses fall under Scope 3 Category 1

The GHG Protocol defines Scope 3 Category 1 as Purchased goods and services — the upstream emissions associated with goods and services you procure but do not directly control. When you call an LLM API, you are purchasing a service: the provider runs inference on their hardware, consuming electricity, in data centers with a specific Power Usage Effectiveness (PUE) and grid mix. Those emissions are yours to account for on the Scope 3 side.

Some companies treat cloud compute more broadly as a Category 1 item alongside SaaS subscriptions. Others apply a narrower boundary. The exact classification depends on your organisation's reporting boundary and how your advisors frame "purchased services" vs "cloud infrastructure." What matters for your data collection is the same regardless of the category label: you need token-level activity data per provider and model.

What CSRD / ESRS E1 actually requires for FY 2025

CSRD applies to the financial year starting 1 January 2025 for companies that meet at least two of: more than 250 employees, more than €50M in net revenue, or more than €25M in total assets. Reports are due in 2026. The European Sustainability Reporting Standards (ESRS) — specifically ESRS E1 Climate Change — require:

• Gross Scope 1, 2, and 3 GHG emissions, broken down by material category.
• Scope 3 disclosure where value chain emissions are material — with a rebuttable presumption that they are material for most large companies.
• Intensity metrics (e.g. tCO₂e per €M revenue) for comparability over time.
• Alignment notes with your climate transition plan and 1.5 °C pathway where applicable.

The November 2025 Amended ESRS (EFRAG) reduced the total number of mandatory datapoints by 61%, but the climate standard (E1) was not materially weakened. If LLM API spend is material to your climate inventory — and for AI-native companies it often is — you are expected to quantify and disclose it.

Spend-based vs activity-based: which method to use

The GHG Protocol allows two approaches for Scope 3 calculations:

For LLM inference, the activity-based method is clearly superior and is what auditors prefer. Token counts are available directly from every major provider's API response (the usage object: prompt_tokens, completion_tokens). The challenge is that you need to collect and retain this data systematically — not as a one-off export.

The data you need to collect — starting now

For each LLM API call in production, you need to retain:

• Model identifier — e.g. gpt-4o-2024-11-20, claude-3-5-sonnet-20241022. The version matters because coefficients differ across model versions.
• Prompt tokens and completion tokens — from the provider's usage object, not estimated.
• Tenant / customer identifier — for per-customer attribution (see per-tenant allocation).
• Timestamp — for monthly period aggregation.

You do not need to retain prompts or completions — in fact, you should not, both for GDPR reasons and because auditors do not need them. The token counts are sufficient. carbon-llm's POST /api/v1/track was designed exactly for this: metadata-only, append-only events that build an audit-ready ledger.

How the coefficient is applied

Once you have token counts, the calculation is straightforward:

gCO₂e = (prompt_tokens + completion_tokens) / 1000 × coefficient_gco2e_per_1k_tokens

Where the coefficient comes from: vendor-published LCAs where available (Mistral, Google), peer-reviewed inference benchmarks (arXiv:2505.09598), or documented defaults with an Estimated label. Each coefficient should carry its confidence level and source — this is the "evidence trail" your auditor reviews, not just the headline tonnes.

Aggregate monthly totals in tCO₂e, split by provider and model, and you have the data you need for ESRS E1 Scope 3 disclosure. The carbon-llm methodology page documents all coefficients and their sources.

The EU AI Act adds another layer

Since August 2025, providers of General Purpose AI (GPAI) models are required to disclose their energy consumption under EU AI Act Article 51. Harmonised standards for AI system energy efficiency (Article 40) are in progress, with Commission deliverables expected in 2026. For deployers — companies building products on top of LLM APIs — collecting token-level activity data now positions you to meet whatever reporting requirements emerge, without a retroactive data gap.