How to calculate your company's AI carbon footprint: the Scope 3 method, and whether CSRD applies to you

Most companies are not. Directive (EU) 2026/470, adopted on 24 February 2026, published on 26 February and in force since 18 March 2026, limits the CSRD reporting duty to undertakings with more than 1,000 employees on average and more than EUR 450 million in net turnover. Both conditions apply, for financial years starting on or after 1 January 2027, so reports under the new scope appear from 2028. The Commission estimates about 85% fewer companies in scope. Member States have until 19 March 2027 to transpose these provisions. The thresholds do not depend on AI use, and the Scope 3 requirements in ESRS E1 do not name it. For a company outside that scope, an AI line in a greenhouse gas inventory is a choice or a commercial request, and the rest of this page treats it that way.

• 24 February 2026. Directive (EU) 2026/470 adopted, with the new thresholds. For the first group of reporters, Member States may also exempt financial years from 2025 to 2026 (recital 31), so a company already reporting should check its own national rules.
• 18 March 2026. The directive enters into force, twenty days after publication.
• 3 July 2026. The Commission adopts the revised ESRS and a voluntary standard.
• 21 September 2026. Both are published in the Official Journal, as Delegated Regulation (EU) 2026/1563 and Delegated Regulation (EU) 2026/1560. The second entered into force three days later.
• 10 November 2026. The revised ESRS enter into force. They apply to financial years starting on or after 1 January 2027, and for financial years starting in 2026 an undertaking may apply either version if it says which one.
• 19 March 2027. Transposition deadline for the reporting provisions.

The bill that was meant to transpose the CSRD did not pass. Congress records bill 121/000038, the Proyecto de Ley de información empresarial sobre sostenibilidad, as concluded and lapsed (caducado) since 6 October 2026. Royal Decree 806/2026, in force that day, dissolved both chambers and called elections for 29 November 2026, with the new chambers meeting on 23 December 2026. The lapsed bill was drafted against the original CSRD, so a new text would have to be introduced in the next legislature. We found no other Spanish act transposing the CSRD as of the date above.

The non-financial statement duty in Ley 11/2018 is a separate matter. As enacted, it applies to companies with more than 500 employees on average that are public-interest entities or that meet two of three size tests, and it covers greenhouse gas emissions generated by the company's activities. Check the consolidated text and take advice on how it applies to you.

Because customers, lenders and tender teams send questionnaires, and because a company that follows a voluntary standard may want a complete inventory. The Omnibus limits one route for these requests. A CSRD reporter cannot require companies in its value chain to provide more information than the voluntary standard covers, and the Commission's text gives undertakings with up to 1,000 employees a statutory right to refuse anything beyond that.

That limit has edges worth knowing. It applies to information gathered for reporting under the Accounting Directive, it applies from financial years starting on or after 1 January 2027, and it does not prohibit voluntary sharing of information commonly shared in a sector. The data points it covers are listed in Annex II of Regulation 2026/1560. Those include gross greenhouse gas emissions at paragraph 33 for undertakings above 10 employees, which paragraph 33 describes as Scope 1 and location-based Scope 2. The Scope 3 paragraphs are not in that list. So a CSRD customer asking a protected supplier for its own AI line, which is Scope 3, is asking for something the supplier may decline for that purpose. Many will still answer, for commercial reasons or because a lender or tender asks outside that route.

The voluntary standard, which builds on the earlier VSME recommendation, makes Scope 3 optional. Paragraph 49 says that depending on the activities it may be appropriate to disclose a quantification of Scope 3 emissions, and paragraph 51 says that a company choosing to do so refers to the fifteen Scope 3 categories. An AI service your company buys falls in the first of them, purchased goods and services.

The GHG Protocol Scope 3 Standard is an accounting standard published by WRI and WBCSD, not legislation. A company using it shall account for all scope 3 emissions and disclose and justify any exclusions, and the minimum boundary of Category 1 is all upstream, cradle-to-gate emissions of purchased goods and services. The GHG Protocol plans to consolidate its corporate standards, with a draft for public consultation estimated for Q2 2027 and publication estimated for Q4 2028, so this may change.

The revised ESRS E1 asks for Scope 3 emissions from each significant Scope 3 category (paragraph 30). Its application requirement AR 24 tells the undertaking to consider the GHG Protocol Scope 3 Standard, to screen the fifteen categories, to identify significant categories by magnitude and other criteria, and, where applicable, to disclose emissions from purchased cloud computing and data centre services as a subset of Category 1. Reading AI APIs and enterprise AI seats into that subset is our interpretation, since the text does not name them. Whether the amount is significant is a judgement for your materiality assessment and your assurance provider.

In Scope 3 Category 1, purchased goods and services, if you include it. An AI API, an enterprise chat seat and a SaaS tool with AI features are all third-party services your company buys, so their emissions are upstream of you and sit in the same category as any other purchased service. They are not Scope 2, because you are not buying the electricity, the provider is. The steps below are the mechanics of producing that line once you have decided to.

All of them, including the ones IT did not buy. The common gap in an AI inventory is a missing service rather than a wrong factor, and the services that go missing are the ones on a team credit card. Build the list from three places, which are the IT asset register, the finance system's vendor list and the single sign-on log.

• APIs with usage billing. OpenAI, Anthropic, Azure OpenAI, AWS Bedrock, Google Vertex AI, Mistral, Cohere, and anything your own product calls.
• Seat-licensed AI products. ChatGPT Enterprise or Team, Claude for Work, Microsoft 365 Copilot, GitHub Copilot, Gemini for Workspace.
• SaaS with embedded AI. The CRM, the note-taker, the support desk, the design tool. Usually invisible in usage terms and usually Tier 1.
• Internal tools built on somebody else's API. The support chatbot, the document reader, the internal search. The usage sits in your own logs, which makes these the easiest to count precisely.

For each service, record the vendor, the contract type, the annual spend, the owner and the reporting period covered. That table is the skeleton of the inventory, and everything after this is filling in cells.

Tokens by model and by month, for the reporting period. That one sentence covers API providers, and you are asking for something the billing system computes anyway.

• OpenAI. The usage page in the platform console exports input and output tokens per model per day. For ChatGPT Enterprise or Team, the admin dashboard gives seats and message counts instead.
• Anthropic. The console usage view exports tokens per model. Claude for Work reports seats and activity.
• Azure OpenAI. Token metrics per deployment through Azure Monitor, plus the invoice in Cost Management. The deployment region is stated, which removes the region guess.
• AWS Bedrock. Input and output token metrics in CloudWatch, or model invocation logging to S3 for per-call detail. The AWS region is the serving region.
• Google Vertex AI. Token counts through Cloud Monitoring and the billing export. The endpoint location is the serving region.
• Microsoft 365 Copilot and GitHub Copilot. No token export. The admin centre gives assigned seats and active users, which is Tier 2b data.

Keep the export itself, not a figure copied out of it. When someone asks where a number came from, the answer should be a file with a date on it. If a vendor cannot produce usage at all, note that you asked and when, because that record explains why the line falls back to a spend-based estimate.

Assign the tier per service, from the data you were able to get in step 2, never to the company as a whole. Most inventories end up with three tiers in the same table, and that is the expected outcome.

The Tier 2b conversion of 1210 tokens per exchange is a general business-use assumption and should be disclosed as one. Raise it for coding and long-document work and lower it for short question-and-answer use. Reasoning modes generate many more tokens per question, and no public source gives the multiplier, so Tier 2b multiplies estimated output tokens by 2.20. That uplift combines an author-assumed k of 25 (range 10 to 50) with the Anthropic Economic Index share of 5% of Claude.ai conversations using thinking, a share of conversations and not of tokens, and that share is likely low for later years. Declare it as an assumption, and where a tool is reasoning-heavy get the billing tokens and use Tier 2a, which already includes those tokens and is not multiplied.

One of three, and the choice matters more than the exact model name. Providers do not publish model sizes, so models are grouped by their published tier and benchmark behaviour, and the class decides the factor.

• Class A — Small. gpt-4o-mini, gpt-4.1-mini, gpt-4.1-nano
• Class B — Mid. gpt-4o, chatgpt-4o-latest, gpt-4.1
• Class C — Frontier. gpt-4, gpt-4-turbo, gpt-5

Getting the class wrong is the largest single error in this method, at about four to five times, more than the uncertainty band on any factor (arXiv 2606.10660, section 7.3, under peer review). Two traps are worth knowing. "Mini" in a model name does not always mean a small model, since some reasoning models carry it, and a mixture-of-experts model is classed on its active parameters rather than its total. If your export lists several models, split the tokens by model and apply each class separately rather than averaging.

The region where the provider runs the model, not where your office is. On a cloud platform you already know it, because an Azure deployment, an AWS Bedrock call and a Vertex endpoint all name their region in the same export as the tokens. On a consumer-style API you often do not, and the honest answer is to use the provider's usual serving region and record that you assumed it.

It is worth the effort to find out. In the worked example below, the same usage comes to 107.1 kg CO₂e served from US East - N. Virginia and 26.6 kg served from EU North - Sweden, a difference of 80.5 kg for identical work. Factors are location-based, the grid average for the region, so this describes where the electrons come from and not the provider's renewable contracts. The per-region tables are at SOMA AI Emission Factors.

A 100-person company. 80 people use an AI assistant, about 2,000 messages each per month, on a mid-size model. No token export is available, so this is Tier 2b.

1. Messages for the year. 80 × 2,000 × 12 = 1,920,000.
2. Tokens, with the reasoning uplift on output. 1,920,000 × (928 + 282 × 2.20) = 2,970,329,088, which is 2,970 million.
3. Class B — Mid. Region US East - N. Virginia, the provider's default.
4. Electricity. 2,970 × 0.03102 = 92.14 kg CO₂e.
5. Embodied hardware and construction. 2,970 × 0.00210 = 6.24 kg. Amortised training. 2,970 × 0.00293 = 8.72 kg.
6. Total for the line. 107.10 kg CO₂e, ±39% class range for class B at the world-average grid, with the wider lifecycle bands disclosed separately.
7. Water, reported beside it. 733 litres for the year.

The same company, with the same usage served from EU North - Sweden, comes to 26.61 kg CO₂e and 1,829 litres of water, more than twice as much, because that grid's low carbon comes with high water intensity. Both numbers come from the same token count, and neither is a substitute for the other.

Notice the size of the result. A hundred-person company running AI hard all year is at a few tens of kilogrammes of CO₂e, not tonnes. The case for doing this work is rarely the magnitude. It is that a customer, lender or reviewer may ask, and a small number with a method behind it is a better answer than none.

Next to the figure, in the same row, not in a footnote nobody reads. A Tier 2a line carries a class range of ±39% for class B at the world-average grid (±48% for A, ±67% for C). The embodied and training terms carry their own, wider bands, which is why they are reported as separate components rather than folded silently into one number.

The boundary is as much a part of the disclosure as the number. These factors cover inference, meaning the energy to serve the tokens grossed up for facility overhead, plus the share of the server hardware and the amortised training. They exclude provider offices and research, network transport and your own devices. Embedding, image, speech and video models are outside this factor version altogether and should be reported separately rather than priced at a chat factor. Full detail is on the methodology page.

Enough for somebody else to rebuild the number without asking you a question. In practice that is seven fields per service.

1. Activity data. Tokens, messages or spend, with the period covered.
2. Source of the activity data. Which export, from which console, downloaded when.
3. Method and tier. Tier 2a, 2b or 1, and why that tier and not a better one.
4. Emission factor. The value, the model class and the region it belongs to.
5. Factor version and source. Here, soma-ai-ef-2026.10-dataset-v3.0.0, with the dataset DOI (10.5281/zenodo.20443585).
6. Uncertainty. The band, and any assumption that widens it, such as the tokens-per-message conversion.
7. Estimated flag. Whether the line is a metered value, a conversion or an estimate.

A well-documented uncertain estimate is easier to defend than a precise-looking figure with no method behind it, because the second one has to be defended from memory.

1. How do you know the list of AI services is complete, and who checked it?
2. Where did this token or message count come from, and can I see the export?
3. Which factor did you apply, what version is it, and who published the underlying data?
4. Why that model class and that region, and what happens to the figure if the region is wrong?
5. Is the figure location-based or market-based, and is it consistent with the rest of the inventory?
6. What is excluded, and is that exclusion disclosed?
7. If the factors are updated next year, can you still reproduce this year's number?

These are the questions we would expect from an assurance provider or a customer's questionnaire, and they are answerable in advance. The last one catches people. If the factor source is a web page that changes silently, last year's figure cannot be rebuilt. Versioned factors with a citable DOI, and the version recorded on the line, make that answer a yes.

Because it counts money, not electricity. The spend-based route multiplies the invoice by 0.1181 kg CO₂e per EUR (EXIOBASE 3.8.2 — Computer and related services), a sector-average factor built from economy-wide input-output tables that mix software development, IT consulting and cloud services of every kind, with an uncertainty of ±300%. An API price contains margin, research and training recovery, none of which has a physical counterpart at inference time.

The worked example makes the size of it concrete. The physical estimate was 107.10 kg CO₂e for the year. To produce that same figure, the spend-based route would need the annual invoice for that usage to be about €907. Any realistic invoice for 1,920,000 messages is well above that, which is how a spend-based AI line ends up well above a physically derived one, at 1.7 to 12.3 times on deflated spend in the method paper's comparison (2.0 to 15.1 times before deflation).

That makes the spend-based factor a fallback. Use it where no usage data exists, label it an upper bound covering the whole subscription rather than its AI part, and treat it as a prompt to go back to the vendor for usage data next year.

• Methodology. Every term of a factor and its sources
• Why AI footprint estimates differ. Published figures, each with its boundary and its date
• SOMA AI Emission Factors table and download. The factors to apply, by region and model class