Location-based or market-based: what should be published?

Both, ESRS E1-6 requires it and the GHG Protocol recognises both methods. The real question concerns internal steering: only the location-based method responds to the decisions your teams make. A dashboard fed exclusively with market-based figures shows zero whatever the effort made, which removes any possibility of measuring progress and, in practice, any interest in making it.

Does changing region really reduce emissions?

On a tenfold intensity gap, yes, in proportions no application optimisation reaches. The gain must however be net of data egress fees, the possible loss of multi-year commitments, added latency and service availability in the target region. On some workloads the conclusion is not to move, and it is better to establish that before raising the subject in committee.

Is time shifting a real lever?

It depends entirely on grid variability. On a grid with high wind penetration, intensity can vary by a factor of two within the day and shifting batch processing produces a measurable gain. On a stable nuclear grid, variation is low and the scheduling effort is not justified. We check the hourly variability of the grid concerned before recommending anything, and the relevant signal is marginal intensity, not the average.

How reliable are provider dashboard figures?

They differ on points that change the order of magnitude: upstream emissions boundary, Scope 2 method used, monthly rather than hourly granularity, PUE and WUE averaged globally, allocation key for shared hardware rarely published, publication lag of several weeks. They are useful starting points, provided an internal model is rebuilt in parallel and the gap between the two is documented.

What about artificial intelligence workloads?

The main constraint is not environmental but capacity related: graphics processors are available in few regions, which narrows placement choice. Training, deferrable and sometimes movable, is handled as a batch, inference is handled as a latency-bound production workload. Electrical density also imposes liquid cooling whose PUE and WUE profiles differ from classic facilities, which invalidates the use of fleet averages.

Energy Sources and Location

The region and the hour in which a workload runs weigh more on its emissions than almost any software optimisation, yet they also commit price, latency, compliance and your multi-year reservations. We frame that trade-off using your billing data and your real constraints, then write it into your deployment rules.

Schedule a conversation See the other GreenOps domains

CHALLENGES

Engagement framework and macro challenges

Sources: Electricity Maps, Ember, 2024.

These gaps do not appear in most reporting. When Scope 2 is calculated on a market-based basis, the renewable energy certificates purchased by the provider bring the result back to zero, and a real 20 % reduction achieved by your teams stays strictly invisible, taking with it the signal that would justify the effort. The first task is therefore not to reduce, but to rebuild data that responds to decisions.

Engagement scope

Dimensions and stakes addressed in the field

Carbon intensity: average, marginal, hourly

Two different signals serve two different uses. Average intensity describes the grid mix at a given instant, and it feeds carbon accounting. Marginal intensity (marginal operating emissions rate, the emission rate of the generation actually called at the margin) describes the plant that answers one additional megawatt, and it describes the effect of shifting a workload. Steering a time shift with a national annual average amounts to optimising blind. We qualify the source used (Electricity Maps, WattTime, Ember, RTE éCO2mix), its granularity and its boundary: market zone, country or administrative region, since those borders do not coincide.

Accounting methods and regulatory propagation

The location-based method measures what physically powers the servers, the market-based method measures what the provider has contracted. The propagation mechanism is the decisive point and remains poorly understood: the electricity consumed by the data centre belongs to your provider's Scope 2, and that Scope 2 becomes your Scope 3 (Category 1, purchased goods and services). The accounting method chosen by the provider therefore propagates directly into your own reporting, without you having arbitrated it: if it reports market-based, you inherit a figure whose emissions have already been absorbed by the certificates it purchased. ESRS E1-6 also requires you to publish your own Scope 2 under both methods. We document that chain end to end and produce both sets of figures, while steering on location-based.

Facility efficiency: PUE, WUE and their trade-off

PUE (power usage effectiveness) relates total electricity to that of the IT hardware, WUE (water usage effectiveness) relates litres of water consumed to the IT kWh. Three limits shape how they are read: the published value is most often an annual fleet average rather than the value for the region concerned, PUE improves mechanically as load rises, including on under-used servers, and finally PUE and WUE pull against each other, adiabatic cooling lowering the former at the cost of the latter. Moving a workload to a hot, dry region may indeed lower your carbon footprint, but at the cost of higher water consumption in areas already threatened by drought.

Electricity contracts and the quality of commitments

A provider claiming to be 100 % renewable on an annual basis can, in reality, run its servers on fossil energy half the time. This is why we dissect the technical reality behind the announcements: nature of the contracts (guarantees of origin, physical or virtual power purchase agreements), granularity of coverage (annual offset vs hour-by-hour carbon-free supply), geographic relevance and real additionality of the projects funded. Our posture is objective: we audit the actual scope of these commitments, without accepting them blindly or dismissing them on principle.

Placement, cost and enforceable constraints

Carbon is never the only criterion. Moving a workload means arbitrating between multiple imperatives: the same instance type shows 10 to 30 % price gaps across regions, and latency conditions user experience or application couplings. Add to this strict data residency rules (HDS for healthcare, SecNumCloud, DORA for finance), disparities in the availability of managed services and GPU quotas, as well as the real cost of transfer (egress fees and loss of ongoing commitments). A clean region that is non-compliant, unavailable or not meeting business needs is not an option.

Artificial intelligence workloads

Model training can be deferred or relocated, while inference demands optimal response time, ruling out both options in most cases. A hardware imperative compounds this: graphics processor availability remains concentrated in a handful of regions, which constrains geographic choices before any environmental consideration even enters the picture. Furthermore, the extreme electrical density of racks imposes liquid cooling, drastically altering the energy and water balances (PUE and WUE) of data centres. The training and inference phases must therefore be handled separately.

METHODOLOGY

Our approach

01
Reconstruct exploitable data
Each billing line is matched to its region and period, then crossed with grid carbon intensity at the finest temporal granularity. By reusing our own electrical consumption measurement model, we perform a systematic reconciliation with provider data to document and explain the inevitable gap between the two.
02
Qualify the actual room for manoeuvre
We classify your workloads by their capacity to be moved (regulation, latency, dependencies) or deferred (batch processing, AI models). By crossing these elements with your current financial commitments, we define your actual decision window. This step separates the theoretical potential from the optimizations concretely achievable within twelve months.
03
Cost each scenario in dual units
Each relocation or deferral scenario is evaluated in both euros and carbon emissions. The calculation integrates regional price differences, data transfer fees and the impact on your current commitments. When an emission reduction entails a financial cost, we quantify it with full transparency to inform management's arbitration.
04
Make decisions enforceable
Decisions are translated into technical and organisational rules: automated restriction of authorised regions in your Cloud configurations, criteria integrated into architecture reviews and clauses added to your calls for tenders. Without this strict anchoring in your processes, the arbitrations would constantly need to be redone and the gains would eventually dissipate.

WORKED EXAMPLE

Choose the region of execution before any optimisation

An application platform consuming 21.2 MWh over the year, facility efficiency included, produces a carbon footprint that varies by a factor of 16 depending on its region of execution alone.

France

around 40 kgCO₂e/kWh

0.8 tCO₂e

United Kingdom

around 180 kgCO₂e/kWh

3.8 tCO₂e

Germany

around 350 kgCO₂e/kWh

7.4 tCO₂e

Poland

around 650 kgCO₂e/kWh

13.8 tCO₂e

No software optimisation reaches this order of magnitude. It is also why an absolute reduction target can be met by a simple region change, without any resource having been saved: the trajectory must distinguish what belongs to placement from what belongs to efficiency.

Illustrative order of magnitude. Average power coefficients from the Cloud Carbon Footprint model and a facility efficiency of 1.15. The processor generation actually allocated can shift the result by a factor of two.

DELIVERABLES

Sample deliverables

Carbon intensity reference for the regions in use: source, time and geographic boundary, average versus marginal distinction, documented limits
Calculation model rebuilt from your billing exports, with coefficients, assumptions and the gap against the provider dashboard explained
Workload mapping crossing region, movability, deferrability, regulatory constraints and current financial commitments
Placement decision matrix, reusable for later projects and embeddable in architecture reviews
Scenarios costed in euros and in kgCO₂e, including data egress fees and loss of commitments
Placement policy and its implementation in configuration (authorised regions, automated guardrails)
Question grid and data clauses to embed in supplier contracts and tenders
Scope 2 dataset under both methods, aligned with ESRS E1-6 requirements and connected to your Scope 3 (Category 1)

KPIS

Steering indicators

Weighted average carbon intensity of the estate, in kgCO₂e/kWh
Share of workloads running in regions below 100 kgCO₂e/kWh
Ratio of amortised manufacturing emissions to operating emissions
Consumption per business unit of work, in kWh and in kgCO₂e
Share of regions covered by an automated placement policy
Measured gap between the internal model and the provider data

FAQ

Frequently asked questions

Compliance & CSRD
How location gains are reported under regulation.
Public Cloud
Price gaps between régions, the counterpart of the carbon trade-off.
Artificial Intelligence & GenAI
AI workloads, the most sensitive to geographic placement.
FinOps & IT Budgets
The governance framework that makes the trade-off enforceable.