The whole job, in the order you would do it: find the services, get the usage, pick the method, apply the factor, write the line an auditor can follow. Factors dated , version soma-ai-ef-2026.09-lifecycle-v2.
In Scope 3 Category 1, purchased goods and services. 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 belong in the same category as any other purchased service. They are not Scope 2: you are not buying the electricity, the provider is.
ESRS E1-6 asks for gross Scope 1, 2 and 3 emissions, and ESRS points at the GHG Protocol Corporate Standard and its Scope 3 Standard for how to measure them. The full text of the standards is in Delegated Regulation (EU) 2023/2772. Nothing below is legal advice about whether your company must report; it is the mechanics of producing the line once you have decided that AI is in scope.
All of them, including the ones IT did not buy. The single most common gap in an AI inventory is not a wrong factor, it is a missing service, and the services that go missing are the ones on a team credit card. Build the list from three places: the IT asset register, the finance system's vendor list, and the single sign-on log.
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; everything after this is filling in cells.
Tokens by model and by month, for the reporting period. That one sentence covers every API provider, and each of them can already produce it — you are asking for something the billing system computes anyway.
Keep the export itself, not a figure copied out of it. When an auditor asks where a number came from, the answer should be a file with a date on it, not a recollection. If a vendor cannot produce usage at all, note that you asked and when — a documented refusal is what justifies dropping to a spend-based estimate for that line.
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, not a failure.
| Tier | Data you have | Method | Uncertainty |
|---|---|---|---|
| Tier 3 | A certified figure for your account from the provider | Use it directly, no calculation | Provider's own |
| Tier 2a | Exact token counts per model | Tokens in millions × the factor for that class and region | ±40% to ±50% |
| Tier 2b | Message counts, or seats and an activity rate | Messages × 400 tokens, then as Tier 2a | Wider than 2a |
| Tier 1 | An invoice total and nothing else | Spend in EUR × 0.1181 kg CO₂e | ±300% |
The Tier 2b conversion of 400 tokens per exchange is a general business-use assumption and has to be disclosed as one. Raise it for coding and long-document work, lower it for short question-and-answer use, and do not use it at all for reasoning models, which generate 10 to 50 times more tokens per question — for those, get the billing tokens and use Tier 2a.
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.
Getting the class wrong is the largest single error in this method — about four to five times, more than the uncertainty band on any factor (arXiv 2606.10660, section 7.3). Two traps to know about: "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: an Azure deployment, an AWS Bedrock call and a Vertex endpoint all name their region, and it is 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 costs 39.3 kg CO₂e served from US East and 10.1 kg served from EU Sweden — a difference of 29.2 kg for identical work. Factors are location-based, the grid average for the region, so this is a fact about where the electrons come from and not about the provider's renewable contracts. The per-region tables are at /ai-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.
The same company, same usage, served from EU Sweden: 10.07 kg CO₂e — but 756 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; 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 reason to do this work is not the magnitude, it is that the category is reportable, an assurance provider will ask about it, and an answer of "we did not look" is worse than a small number with a method behind it.
Next to the figure, in the same row, not in a footnote nobody reads. A Tier 2a line carries ±50% on the electricity term; 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: the energy to serve the tokens grossed up for facility overhead, plus the share of the server hardware and the amortised training. They exclude data-centre construction, 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 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:
soma-ai-ef-2026.09-lifecycle-v2, with the dataset DOI (10.5281/zenodo.20443585).A well-documented uncertain estimate is worth more to an assurance provider than a precise-looking figure with no method behind it. The second one has to be defended from memory; the first one defends itself.
All seven are answerable in advance. The last one is the one that 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, are what make that answer a yes.
Because it measures 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 39.25 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 €332. Any realistic invoice for 1,920,000 messages is well above that, which is how a spend-based AI line ends up an order of magnitude or more above a physically derived one — 10 to 40 times, on the comparison in the method paper.
That does not make the spend-based factor wrong; it makes it 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.
SOMA turns your providers' usage exports into the finished Scope 3 Category 1 entry, with the tier, factor, version, sources and uncertainty attached, ready for your auditor. The factors and their sources are on the methodology page, the tables at /ai-factors, and if you are reconciling two different published numbers, start with why AI footprint estimates differ. Write to lili@somaai.earth.