Digital & IT · Software Carbon Intensity
Software Carbon Intensity (SCI) Calculator — Emissions per Functional Unit under ISO/IEC 21031
Compute a software system’s carbon intensity as a rate — grams of CO₂e per functional unit — under the ISO/IEC 21031 Software Carbon Intensity specification. The SCI calculator combines operational energy, live grid intensity, and amortised embodied hardware carbon, then divides by the unit of work your software actually does: per API request, per user, per inference, or a unit you define.
The SCI equation:
SCI = ((E × I) + M) / R — operational energy times grid intensity, plus embodied hardware carbon, all divided by the functional unit R.
A rate, not a total. This is the defining property of SCI and the one most often misunderstood. The specification produces a carbon intensity — emissions per unit of work — not an absolute footprint. A total tells you how big your software is; a rate tells you how carbon-efficient it is per thing it does, and whether an optimisation actually moved the needle rather than just shrinking the workload. The calculator shows the absolute tonnes as a secondary line, but the SCI rate is the headline, and it is period-independent: running the same workload for a year instead of a month changes the total, never the rate.
Operational (O = E × I). The energy each component draws (E, in kWh) multiplied by the carbon intensity of the electricity it draws (I). Server energy is modelled bottom-up from the machine’s power band and utilisation, scaled by the data-centre PUE; device energy from the device’s operating power and active hours. Grid intensity is read live from the MasterBrain per region. Summed across every component line, this is the operational term O.
Embodied (M). The manufacturing carbon of the hardware, amortised across its life and the share of it your software uses. The calculator takes each hardware line’s total embodied emissions, then charges only the fraction of life reserved (time-share) and the fraction of the machine’s resources used (resource-share), per the SCI specification’s M definition. Buying a slice of a server for an hour charges a slice of its manufacturing carbon, not the whole thing.
The functional unit R. R is the denominator — the unit of work the rate is expressed against. The specification requires it to be declared, because an SCI figure is meaningless without knowing what it is per. The calculator offers presets (per API request, per user-month, per active-minute, per transaction, per ML inference, per GB delivered, per device-day) and a custom label, plus the count of that unit over the period. Choosing R well is the hardest and most consequential decision on this page.
Grid intensity is location-based average here — a deliberate deviation. ISO/IEC 21031 prefers marginal intensity (the carbon of the next unit of electricity, which is what a workload actually causes). This calculator uses location-based average intensity by default, because average factors are available live for every region while marginal factors are not. A manual marginal-intensity override is provided — a single field that replaces every line’s intensity — for teams who hold a marginal figure. There is no automated carbon-aware or time-shifting mode in this version; marginal accounting is manual entry only.
What this is and is not. This is a screening-grade SCI estimate built on a live energy-and-intensity model. Server and GPU embodied values are provisional engineering constants, not sourced factors — the MasterBrain does not yet carry a server-embodied row. Device embodied and grid intensities are live and sourced. Use the tool to establish an SCI baseline, compare design options, and find the dominant term; treat the absolute tonnes as indicative and the embodied server figures as provisional.
SCI is reported as carbon per R — declare the unit your software’s work is counted in.
Numeric, greater than zero.
Average is MasterBrain grid data. The spec prefers marginal — a documented deviation, surfaced in your result.
One line per component the software runs on: cloud/on-prem compute, end-user devices, storage, network. Each carries its own method and grid region.
Embodied emissions are mandatory in a conformant SCI. Device TE auto-fills from MasterBrain; server/GPU use an editable provisional default until MasterBrain backfills them.
Enter your functional unit (R) and components above to calculate SCI
Results appear instantly. SCI rate, O/M split, confidence, audit trail and an ISO 21031 disclosure string available after calculation.
Indicative screening estimate of Software Carbon Intensity under ISO/IEC 21031. SCI is a rate (carbon per functional unit), not a total inventory figure, and depends heavily on the declared boundary, functional unit, and intensity source. Carbon offsets and market-based instruments are excluded by the specification. Location-based average grid factors are used by default (the spec prefers marginal intensity); server and GPU embodied values are provisional pending MasterBrain backfill. Validate the boundary, functional unit, and factors before external disclosure.
Every efficiency team eventually hits the same wall: they cut a service’s total emissions by twenty percent, then traffic grows thirty percent, and the total climbs anyway. Measured as a total, the optimisation looks like a failure. It was not — the software got more carbon-efficient per request. The total was just measuring the wrong thing.
Software Carbon Intensity exists to measure the efficiency, not the size — a rate per unit of work that a growing system can improve even as its total footprint rises.
Software Carbon Intensity is a rate: ((energy × grid intensity) + embodied hardware carbon) divided by a functional unit, giving grams of CO₂e per request, user or inference. Defined by ISO/IEC 21031, it measures efficiency, not a total.
What the SCI specification is
Software Carbon Intensity (SCI) is a methodology for calculating the rate of carbon emissions of a software system, standardised as ISO/IEC 21031. It answers one question — how much carbon does this software emit per unit of work it performs — and answers it as a rate, not a total. This calculator implements that specification: it takes the operational energy, the grid intensity, the embodied hardware carbon, and a declared functional unit, and returns grams of CO₂e per unit.
Where SCI comes from
SCI originated with the Green Software Foundation as a specification for teams that build and run software, and was published as an international standard, ISO/IEC 21031. It is deliberately narrow: it does not try to be a full organisational GHG inventory, and it does not replace the GHG Protocol. It is a design-and-operations metric — a number an engineering team can move by changing how software is built and run, and can track release over release.
The consumption-based principle
SCI is a consumption-based score: it counts only the energy and hardware a piece of software actually causes to be used, not a share of everything the organisation owns. This is what makes it actionable. A location-wide average would tell a team nothing about whether their last deployment helped; a consumption-based rate tied to their own components and their own functional unit responds directly to the choices they control. The calculator builds the number component line by component line for exactly this reason.
SCI is a rate — carbon per unit of work — not a total footprint. This is the single most important thing to understand about it, and the source of most confusion. A total answers “how big is this software’s footprint”; SCI answers “how carbon-efficient is it per thing it does.” The two move independently: a growing service can improve its SCI while its total rises, and that is a real efficiency gain, not an accounting trick.
How the calculation works — the SCI equation
The whole specification reduces to one equation, applied across every component of the software system:
SCI = ((E × I) + M) / R
The operational term (E × I, summed across component lines) and the embodied term (M, summed across hardware lines) add to a total emissions figure in kg CO₂e; dividing by R — the count of functional units over the period — converts that total into a rate. The calculator computes each term explicitly so the breakdown is visible, not just the final number.
| Term | Meaning | Unit | How the calculator gets it |
|---|---|---|---|
| E | Energy drawn by a component | kWh | Server: power band × utilisation × hours × PUE. Device: operating power × active hours. |
| I | Carbon intensity of that electricity | kg CO₂e/kWh | Live location-based average per region from the MasterBrain (or a manual marginal override). |
| O = E × I | Operational emissions, summed over lines | kg CO₂e | The product of the two above, across every component. |
| M | Embodied hardware carbon, amortised | kg CO₂e | Total embodied × time-share × resource-share, across every hardware line. |
| R | Functional unit count | Count (dimensionless) | Declared by you — per request, per user, per inference, etc. Must be greater than zero. |
| SCI | The carbon-intensity rate | gCO₂e per R | (O + M) ÷ R, scaled to grams. |
The operational term — modelling energy bottom-up
The calculator does not use a single energy-per-vCPU shortcut. Server energy is modelled from the machine’s power characteristics: a power band (idle to peak) drawn from published server power data, scaled by utilisation, multiplied by run hours, and lifted by the data-centre PUE to account for cooling and overhead. PUE is a user input — the default is 1.5 (a typical enterprise facility), with hyperscale facilities nearer 1.1; the calculator shows reference PUE values as a helper but does not assume one for you, because it is one of the largest multipliers on the operational term.
The embodied term — amortising manufacturing carbon
Embodied carbon is the manufacturing footprint of the hardware, and SCI charges only the slice your software is responsible for. The calculator multiplies each hardware line’s total embodied emissions by two fractions: the time-share (the hours you reserve the hardware, divided by its full service life in hours) and the resource-share (the proportion of the machine’s capacity your workload uses). A server used at 60% of capacity for one year out of a six-year life carries one-sixth of six-tenths of its manufacturing carbon on that workload.
Server and GPU embodied figures in this calculator are provisional engineering constants, not sourced emission factors — the underlying data layer does not yet carry a validated server-manufacturing row. Device embodied values (laptops, monitors, phones) are sourced and live. Treat the M term as indicative for server-heavy and GPU-heavy systems, and do not present a server-embodied figure as an audited factor. When the embodied share of your SCI is large and server-dominated, that is exactly where the estimate is softest.
Why SCI is a rate, not a total
The specification’s designers made a deliberate choice to define SCI as a rate and to reject total emissions as the metric. The reasoning is that a total conflates two different things — how efficient the software is, and how much of it is being used — and only the first is under an engineering team’s control. Traffic doubling is not an engineering failure; it may be business success. A rate isolates the part the team owns.
| Scenario | Total emissions | SCI (rate) | What it means |
|---|---|---|---|
| Optimise code, traffic flat | Falls | Falls | Genuine efficiency gain, visible either way |
| Optimise code, traffic grows faster | Rises | Falls | The efficiency gain is real — only SCI shows it |
| No change, traffic grows | Rises | Flat | Bigger, not less efficient — SCI stays honest |
| Cut a feature, shed its traffic | Falls | Flat or worse | Smaller, not more efficient — a total would mislead |
Do not sum SCI figures across workloads to get a total — a rate is not additive that way. Two services at 5 gCO₂e/request do not combine to 10; they combine to a blended rate weighted by their request counts, or to an absolute total via the tonnes line. SCI and the absolute footprint are two different questions. Report both: the rate for efficiency, the tonnes for the inventory line.
Choosing R — the functional unit is the hard part
The arithmetic of SCI is trivial; choosing R is where the judgement lives. R defines what the rate is per, and the specification requires it to be declared because the same system has a different — and equally valid — SCI depending on the unit chosen. A poorly chosen R produces a technically correct number that answers no useful question.
| Software type | Candidate functional unit R | Why it fits |
|---|---|---|
| API / backend service | Per API request | The atomic unit of work; scales directly with what the service does |
| Web / SaaS application | Per user-month, or per active-minute | Ties carbon to delivered value rather than raw traffic |
| Machine-learning inference | Per inference (per prediction) | The billable, meaningful unit for a served model |
| Machine-learning training | Per training run, or per model version | Training is episodic; per-run captures the real event |
| Batch / data pipeline | Per job, or per GB processed | Matches the unit the pipeline is actually sized by |
| E-commerce / transactional | Per transaction, or per order | Aligns carbon with a unit the business already tracks |
Pick the R that a stakeholder outside engineering would recognise as a unit of value — a request, a user, a transaction, an inference — not an internal artefact like a container-hour. The right R makes the SCI figure comparable across releases and legible to the people who set targets. Once chosen, hold it fixed: changing R between measurements breaks the comparison, the same way changing the denominator mid-way breaks any ratio.
The four SCI levers
Because SCI is an equation, every way to improve it maps to a term. This is the practical value of the rate framing: it turns decarbonisation into four concrete levers, each acting on a different part of the formula.
Energy efficiency → E
Do the same work with less energy: more efficient algorithms, fewer wasted cycles, better resource utilisation, right-sized instances. Every reduction in E flows straight through the operational term. This is the classic software-efficiency lever, and it improves the rate at any traffic level.
Hardware efficiency → M
Get more work from each piece of hardware, or extend its life. Higher utilisation spreads the same embodied carbon across more functional units; longer service life shrinks the time-share charged per hour. Consolidation and lifecycle extension both act on M, the term most people forget to optimise.
Carbon awareness → I
Run the work where and when the electricity is cleaner. Shifting compute to a low-intensity region, or to a time when the grid is greener, lowers I without changing the work done. This calculator supports the location lever directly (choose the region) and a manual marginal figure; it does not automate time-shifting.
Demand shaping → R
The subtle lever: increase the useful work per unit of carbon by serving more value from the same footprint — caching, deduplication, eliminating wasted or repeated requests. This raises R relative to (O + M) and lowers the rate, without any hardware or energy change.
Read the term breakdown before choosing a lever. If your SCI is operational-dominated, energy efficiency (E) and carbon awareness (I) are the levers; if it is embodied-dominated, hardware utilisation and lifecycle (M) matter more. The calculator’s decomposition into O/R and M/R tells you which fight you are in before you spend effort on the term that was already small.
The software boundary — what counts
SCI requires a declared boundary: the set of components whose energy and hardware count toward the system. Drawing it too narrow understates the rate and hides real emissions; drawing it too wide pulls in infrastructure the software does not cause. The specification’s guidance is to include everything the software genuinely causes to run and exclude everything it does not.
Typically inside
Compute (servers, containers, functions), the storage and networking the software drives, the client devices when the software runs on them, and the amortised embodied carbon of all of it. If the component would not run were the software switched off, it is inside.
Typically outside
Shared corporate IT the software does not cause, developer laptops used to build it (a separate boundary), the end user’s own unrelated device usage, and the emissions of whatever the software is about — an e-commerce platform does not carry the emissions of the goods it sells.
The judgement calls
Idle and baseline consumption, over-provisioned capacity, and shared platform services (a database serving many apps) need an allocation rule. The resource-share fraction in the embodied term is the calculator’s mechanism for splitting shared hardware; apply the same logic to shared operational energy.
Client-side matters
For user-facing software, the client device is often the largest energy line — see the worked example, where 2,000 laptops outweigh the server cluster. Excluding the client because it is “the user’s device” understates the true SCI. If the software runs there, it is inside the boundary.
Inputs this calculator needs — and where to source them
The calculation is one equation; the accuracy is in the inputs. The calculator builds the number from component lines, so most inputs are per-line. The four groups below drive every result.
| Input | Unit | Primary source | Fallback |
|---|---|---|---|
| Compute — class, count, utilisation, hours, PUE, region | W band, %, h, ratio, country | Cloud/infra telemetry, instance metadata, data-centre PUE report | Server power band presets; PUE default 1.5; dominant region |
| Device — type, count, active hours, region | Count, h, country | Fleet/MDM records, product analytics for active time | Device operating-power presets; estimated active hours |
| Embodied — hardware type, count, service life, resource share | kg, yr, % | Device embodied factors (live); hardware amortisation policy | Service-life default 6 years; provisional server embodied constant |
| Functional unit — R type and count over the period | Label + count | Application metrics: request/transaction/inference counts | — (R must be declared; there is no default) |
Grid intensity here is location-based average, drawn live per region (UK factors via DEFRA). ISO/IEC 21031 prefers marginal intensity — the carbon of the electricity your workload actually causes to be generated — which is usually higher than the average and is the more decision-relevant figure for carbon-aware work. The calculator provides a manual marginal-override field for teams who hold a marginal number, but it does not source marginal data automatically. If your disclosure or target framework requires marginal accounting, enter the marginal figure explicitly and record its source.
SCI vs a carbon footprint vs a GHG inventory
SCI is frequently confused with a carbon footprint or a Scope 2/3 inventory line. They are related but answer different questions, and SCI feeds the others rather than replacing them.
| Dimension | SCI (ISO/IEC 21031) | Carbon footprint / GHG inventory |
|---|---|---|
| Output type | A rate — per functional unit | A total — absolute tonnes over a period |
| Question answered | How carbon-efficient per unit of work? | How much carbon in total? |
| Basis | Consumption-based, component by component | Organisational or product boundary, scope by scope |
| Grid intensity preference | Marginal (per the spec) | Location- and market-based (GHG Protocol Scope 2) |
| Primary audience | Engineering and product teams | Sustainability, finance, disclosure |
| Additive? | No — rates blend by weight, not by sum | Yes — totals sum across the inventory |
The relationship is complementary. The absolute tonnes that SCI computes on the way to the rate is the figure that feeds a GHG Protocol Scope 2 (purchased electricity for owned compute) or Scope 3 (cloud, devices, upstream hardware) inventory line. SCI does not replace the inventory; it gives engineering a rate to optimise, while the inventory gives the organisation a total to disclose. Note the intensity-basis mismatch: SCI prefers marginal, Scope 2 accounting uses location-based and market-based figures — so an SCI figure and an inventory line for the same software can legitimately use different intensities.
The result components — SCI rate and term breakdown
The calculator reports the rate as the headline and decomposes it so the dominant term is visible. The absolute tonnes appear as a secondary line for the inventory.
| Output | Unit | What it answers | Where it goes |
|---|---|---|---|
| SCI rate | gCO₂e per R (auto-scales) | The headline carbon intensity per unit of work. | Engineering targets; release-over-release tracking |
| Operational per unit (O/R) | gCO₂e per R | The share of the rate from energy × intensity. | Energy-efficiency and carbon-awareness targeting |
| Embodied per unit (M/R) | gCO₂e per R | The share of the rate from amortised hardware carbon. | Hardware-utilisation and lifecycle targeting |
| Absolute total | tCO₂e over the period | The absolute footprint (rate × R, over the period). | The Scope 2 / Scope 3 inventory line |
The O/R versus M/R split is the actionable output. A rate that is almost all operational points at energy and grid intensity; a rate with a heavy embodied share points at hardware utilisation and lifecycle. Reading the split first stops a team from optimising the wrong term — the same discipline the worked example demonstrates, where the operational term is more than nine-tenths of the rate.
Worked example — an API service at one gram per request
This is the default example the calculator boots with, reproduced to the digit. It measures an API service running on a four-node UK cloud cluster with two thousand client laptops, over a year, against a functional unit of one million API requests.
| Component | Configuration |
|---|---|
| Cloud compute | 4 nodes · modern class (90–450 W band) · 50% utilisation · 8,760 h · PUE 1.2 · region GB |
| Client devices | Laptop · 2,000 units · 600 active hours · region GB |
| Server embodied | 4 servers · 1,200 kg each (provisional) · 6-year life · 8,760 h reserved · 60% resource share |
| Functional unit R | Per API request · 1,000,000 requests · annual period |
| Grid intensity (GB) | 0.13096 kg CO₂e/kWh (DEFRA 2026, location-based average) |
Operational term (O)
Each node’s power is its idle draw plus utilisation across the band: 90 + 0.50 × (450 − 90) = 270 W. Four nodes for 8,760 hours, lifted by the 1.2 PUE, give E₁ = 4 × 270 × 8,760 ÷ 1,000 × 1.2 = 11,352.96 kWh, and at the GB intensity O₁ = 11,352.96 × 0.13096 = 1,486.75 kg. The two thousand laptops at 22 W for 600 active hours give E₂ = 22 × 2,000 × 600 ÷ 1,000 = 26,400 kWh, and O₂ = 26,400 × 0.13096 = 3,457.34 kg. The client fleet outweighs the server cluster — the operational total is O = 4,944.09 kg.
Embodied term (M)
Each server’s 1,200 kg of provisional embodied carbon is amortised: the time-share is 8,760 ÷ (6 × 8,760) = 0.16667 (one year of a six-year life), and the resource-share is 0.60. Across four servers, M = 1,200 × 4 × 0.16667 × 0.60 = 480.00 kg.
Result
| Quantity | Value |
|---|---|
| Operational (O) | 4,944.09 kg CO₂e |
| Embodied (M) | 480.00 kg CO₂e |
| Total (O + M) | 5,424.09 kg = 5.4241 tCO₂e |
| Functional unit (R) | 1,000,000 API requests |
| SCI | 5.42 gCO₂e per API request |
| — operational per request (O/R) | 4.94 gCO₂e |
| — embodied per request (M/R) | 0.48 gCO₂e |
| Embodied share | 8.85% |
5.42 gCO₂e per API request · operational 4.94 · embodied 0.48 · embodied share 8.85%
Two things stand out, and both are typical of user-facing software. First, the rate is operational-dominated — 91% of it is energy × intensity, so energy efficiency and cleaner electricity are the levers here, not hardware lifecycle. Second, the client devices, not the servers, drive the operational term: excluding the laptops as “the user’s own hardware” would understate the SCI by more than two-thirds. The boundary decision — include the client — is what makes the number honest.
Read the split before acting. This system is 91% operational and its energy is dominated by client devices — so the highest-leverage moves are reducing client-side work and serving from a cleaner grid, not extending server life. The server-embodied figure is provisional in any case; because it is only 8.85% of the rate, the softness of that constant barely moves the headline. When embodied is small, its uncertainty is small too.
Carbon-aware computing — the intensity lever
The intensity term I is the one lever that lowers emissions without changing the work done: run the same computation on cleaner electricity. This is carbon-aware computing, and it splits into two moves — shifting where the work runs and shifting when. Both act on I, and both are real: grid intensity varies by more than an order of magnitude between regions and by a large factor across the hours of a single day.
Location shifting
Move the workload to a region with a cleaner grid. The spread is large — some national grids are several times more carbon-intensive than others for the same kWh. This calculator supports location shifting directly: set each component’s region and the live intensity follows. It is the most tractable carbon-aware move for batch and flexible workloads.
Time shifting
Move flexible work to hours when the grid is cleaner — typically when renewable output is high. The daily intensity swing is substantial, so deferring a nightly batch to a greener window genuinely lowers I. This version of the calculator does not automate time shifting; model it by entering the intensity for the target window as a manual figure.
Average vs marginal intensity
The calculator uses location-based average intensity by default. Carbon-aware decisions are more correctly made on marginal intensity — the carbon of the next unit of electricity your workload causes — which the specification prefers. The two can differ materially. Use the manual marginal override when you hold a marginal figure and your framework calls for it.
What v1 does and does not do
This version supports the location lever live and marginal intensity by manual entry. It does not ship an automated carbon-aware scheduler, a live marginal-intensity feed, or a time-series of grid intensity. Those are analysis inputs you supply; the calculator does the SCI arithmetic on them, not the forecasting.
Carbon awareness only helps flexible workloads. A latency-critical API cannot wait for a greener hour or hop regions mid-request, so its I is effectively fixed by where it must run. Batch jobs, model training, data pipelines, and asynchronous processing are where location and time shifting pay off — target the intensity lever there, and use the energy and hardware levers on the workloads that cannot move.
Standards and frameworks
SCI sits alongside the digital-energy models it borrows from and the GHG accounting standards it feeds. The frameworks below define the surface an engineering team and a sustainability team share.
| Framework | Role for software carbon intensity | Status |
|---|---|---|
| ISO/IEC 21031 (SCI) | The specification this calculator implements. Defines the equation, the functional-unit requirement, the marginal-intensity preference, and the embodied amortisation. | Published international standard |
| Sustainable Web Design | A sibling digital-energy model. Shares the byte-and-segment energy logic used across the digital cluster; useful for web-delivery components of a software system. | Open model, current revision v4 |
| Uptime Institute PUE | The data-centre power-usage-effectiveness reference behind the PUE multiplier on the operational term. Anchors the default and helper PUE values. | Industry benchmark |
| GHG Protocol Scope 3 | The accounting standard the SCI absolute total feeds. Cloud, device, and upstream-hardware emissions land in Scope 3; owned-compute electricity in Scope 2. | Voluntary accounting standard; near-universal reference |
| Grid factor source | DEFRA and equivalent national sources supply the live location-based intensities the operational term multiplies by. | Live factor sets, updated annually |
Audit checklist — what gets challenged in SCI review
An SCI figure presented for a target or disclosure gets scrutinised on a predictable set of points. The findings below are where SCI calculations most often come apart.
- R undeclared or shifting. An SCI figure with no stated functional unit is not compliant — the spec requires R to be declared. A figure compared across releases on different R values is not a valid comparison. Confirm R is stated and held constant.
- SCI summed to a “total.” Rates are not additive. Adding per-request SCI figures across services to produce a total is a category error; the absolute-tonnes line is the total. Confirm rate and total are not conflated.
- Client devices excluded. For user-facing software the client is often the largest energy line. Dropping it as “the user’s device” understates the rate — as the worked example shows, by more than two-thirds. Confirm the boundary includes components the software causes to run.
- Average intensity presented as marginal. The spec prefers marginal; this and most tools default to average. A figure labelled as spec-compliant while using average intensity should say so. Confirm the intensity basis is disclosed and matches the claim.
- Server embodied treated as an audited factor. Server and GPU embodied values here are provisional constants, not sourced factors. An embodied-heavy SCI resting on them should be flagged as indicative. Confirm the embodied basis is disclosed.
- PUE assumed, not sourced. PUE is a large operational multiplier and a user input. A figure using the 1.5 default for a hyperscale workload (nearer 1.1) overstates it; the reverse understates. Confirm PUE traces to the actual facility.
- Embodied life or resource-share mis-set. The amortisation depends on service life and resource share. A too-short life or a 100% resource-share on shared hardware overstates M. Confirm both trace to the hardware policy and the real allocation.
- Utilisation guessed. Server energy scales with utilisation across the power band. A default utilisation applied to a lightly-loaded fleet misstates E. Confirm utilisation traces to telemetry, not an assumption.
Reporting context — where a rate lands in disclosure
SCI is an engineering metric, but its absolute-tonnes by-product and its efficiency trajectory both surface in corporate disclosure. The regimes below are where a software carbon figure appears.
| Framework | Role for a software carbon figure | Cadence |
|---|---|---|
| GHG Protocol | The absolute total feeds Scope 2 (owned-compute electricity) and Scope 3 (cloud, devices, upstream hardware). SCI itself is the efficiency metric behind those totals. | Annual inventory cycle |
| CSRD ESRS E1 | The EU mandate. Digital and IT emissions sit within Scope 2/3 datapoints; an SCI trajectory is a defensible efficiency KPI alongside the absolute figures. | Annual sustainability statement |
| IFRS S2 | The global climate-disclosure baseline. Requires material Scope 3 with methodology transparency; the SCI term breakdown supports that transparency for software-intensive businesses. | Annual, aligned with financial statements |
The practical pattern is to disclose the absolute tonnes in the inventory and to use the SCI rate internally as the efficiency target — the number engineering commits to reducing release over release. A falling SCI with rising absolute emissions is a coherent, honest story for a growing product, and the two figures together tell it better than either alone.
Data sources, factor versioning, and transparency
Energy model — server power and PUE
Server energy is modelled bottom-up from published server power bands (idle and peak watts) scaled by utilisation, not from an energy-per-vCPU constant. The default modern server class uses a 90–450 W band; a legacy class uses 70–260 W. PUE is a user input defaulting to 1.5; hyperscale facilities sit nearer 1.1, and the calculator surfaces reference PUE values as a helper without assuming one. Device operating power is read live per device type (for example, laptops, monitors, tablets, and smartphones each carry their own operating wattage).
Grid intensity — live, location-based average
| Region (example) | Location-based average intensity | Source |
|---|---|---|
| United Kingdom (GB) | 0.13096 kg CO₂e/kWh | DEFRA 2026 |
| France (FR) | 0.04144 kg CO₂e/kWh | National location-based average |
| Germany (DE) | 0.32965 kg CO₂e/kWh | National location-based average |
| United States (national) | 0.349667 kg CO₂e/kWh | National location-based average |
These are the live values behind the worked example and the region presets; they update on their source cycles and the engine reads them at render, so a rendered figure tracks the deployed data version. The spread — France below 0.05 against Germany above 0.32 — is why location shifting is a real lever. The same grid-factor logic underlies the Scope 2 electricity calculator, and the full set is browsable in the grid electricity emission factors library.
Embodied hardware — sourced devices, provisional servers
Device embodied carbon is read live from published device-manufacturing data (for example, laptop, desktop, monitor, tablet, and smartphone embodied totals). Hardware service life defaults to six years, from a standard amortisation reference. Server and GPU embodied values are provisional engineering constants — the data layer does not yet carry a validated server-manufacturing row, so those figures are indicative and flagged as such throughout, not presented as sourced factors. Every result stamps the live MasterBrain version via MasterBrain v2026.284, so the vintage behind any figure is recoverable, and the paired SCI methodology page documents the full model.
What’s next — the rest of your digital footprint
SCI measures the software; the rest of the digital cluster measures the infrastructure and activities around it, each with its own calculator.
Compute & cloud
Size the underlying infrastructure with the cloud compute calculator and the data-centre PUE calculator — the facility and compute layers behind the operational term.
AI workloads
For model training and inference specifically, the AI compute calculator handles the per-run and per-inference energy that a machine-learning SCI is built on.
Web & advertising
The website carbon calculator covers page delivery, and the digital advertising carbon calculator covers ad serving — adjacent digital surfaces that share the same energy-and-grid logic.
Devices
The end-user devices calculator owns the client-hardware footprint that SCI’s device lines draw their operating and embodied figures from.
Once assembled, the digital lines roll into the broader Scope 3 inventory. The full methodological treatment of the SCI approach — the bottom-up server energy model, the embodied amortisation, and the marginal-intensity handling — is published on the paired Software Carbon Intensity methodology page, and the cloud and AI energy models it relies on are detailed in the cloud compute allocation methodology and the AI compute methodology.
Frequently asked questions
SCI is a rate that measures the carbon emissions of a software system per unit of work it performs. Defined by the ISO/IEC 21031 specification, it is calculated as ((energy × grid intensity) + embodied hardware carbon) divided by a functional unit R — giving grams of CO₂e per API request, per user, per inference, or another declared unit. It is deliberately a rate rather than a total, so it measures carbon efficiency rather than sheer size.
With the equation SCI = ((E × I) + M) / R. E is the energy each component draws in kWh; I is the carbon intensity of that electricity; their product summed across components is the operational term O. M is the embodied hardware carbon, amortised by how long you reserve the hardware and how much of its capacity you use. R is the functional unit count. The calculator models server energy from power bands and utilisation, reads grid intensity live, amortises embodied carbon, and divides the total by R to produce the rate.
Because a total conflates efficiency with scale, and only efficiency is under an engineering team’s control. If traffic doubles, a total doubles — that is business growth, not an engineering regression. A rate isolates the part the team owns: carbon per unit of work. A growing service can improve its SCI while its total emissions rise, and that is a genuine efficiency gain a total would hide. Report both — the rate to optimise, the total to disclose.
R is the unit of work the rate is expressed per, and the specification requires it to be declared. Choose the unit a non-engineer would recognise as value: per API request for a backend service, per user-month for a SaaS app, per inference for a served model, per transaction for e-commerce. Avoid internal artefacts like container-hours. Once chosen, hold R constant across measurements — changing it breaks the comparison, the way changing any denominator breaks a ratio.
Location-based average by default, because average factors are available live for every region. ISO/IEC 21031 prefers marginal intensity — the carbon of the next unit of electricity your workload causes — which is usually higher and more decision-relevant for carbon-aware work. The calculator provides a manual marginal-override field for teams who hold a marginal figure, but it does not source marginal data automatically and has no live carbon-aware feed. If your framework requires marginal accounting, enter the figure explicitly and record its source.
The embodied term M charges only the slice of a device’s manufacturing carbon your software is responsible for. Each hardware line’s total embodied carbon is multiplied by a time-share (hours reserved ÷ full service life in hours) and a resource-share (proportion of capacity used). A server used at 60% for one year of a six-year life carries one-sixth of six-tenths of its manufacturing carbon. Device embodied values are sourced and live; server and GPU embodied values are provisional engineering constants, so an embodied-heavy figure resting on them should be flagged as indicative.
Yes, if the software runs on them. For user-facing software the client device is often the largest energy line — in the worked example, two thousand laptops outweigh the four-node server cluster and account for the majority of the operational term. Excluding the client as “the user’s own device” understates the true SCI by more than two-thirds. The boundary rule is what the software causes to run: if it runs on the client, the client is inside.
No — SCI is a rate, and rates are not additive by sum. Two services at 5 gCO₂e/request do not combine to 10; they blend into a request-weighted rate, or roll up via their absolute tonnes into a combined total. Use the SCI rate for per-service efficiency and the absolute-tonnes line for the combined footprint. Summing rates directly is a category error that shows up in audit.
They are complementary. SCI gives engineering a rate to optimise; the GHG Protocol gives the organisation a total to disclose. The absolute tonnes SCI computes on the way to the rate feed a Scope 2 line (electricity for owned compute) or Scope 3 line (cloud, devices, upstream hardware). SCI does not replace the inventory. Note the basis difference: SCI prefers marginal intensity while Scope 2 uses location-based and market-based figures, so the two can legitimately use different intensities for the same software.
It supports location shifting directly — set each component’s region and the live intensity follows — and marginal intensity by manual entry. It does not ship an automated carbon-aware scheduler, a live marginal feed, or a grid-intensity time series in this version. Model time shifting by entering the intensity for the target window manually. Carbon awareness only helps flexible workloads: a latency-critical API cannot wait for a greener hour, so target batch jobs, training, and asynchronous work with the intensity lever.
Methodology notes and limitations
Specification. The calculator implements the ISO/IEC 21031 Software Carbon Intensity specification: SCI = ((E × I) + M) / R, a consumption-based rate expressed per declared functional unit. The rate is period-independent — running longer changes the absolute total, never the rate.
Screening-grade estimate. Server energy is modelled bottom-up from published power bands and utilisation, not metered per workload. This is the right tool for baselining, comparing design options, and finding the dominant term. It is not a metered measurement of a specific deployment and does not certify any reduction or neutrality claim.
Grid intensity is location-based average — a flagged deviation. ISO/IEC 21031 prefers marginal intensity; this calculator uses location-based average by default because average factors are available live per region and marginal factors are not. A manual marginal-override field replaces every line’s intensity for teams who hold a marginal figure. There is no automated carbon-aware mode, no live marginal feed, and no grid-intensity time series in this version — marginal and time-shift accounting are manual inputs.
Server and GPU embodied are provisional. The data layer does not yet carry a validated server-manufacturing embodied row, so server and GPU embodied values are provisional engineering constants, flagged throughout as indicative rather than sourced. Device embodied values and grid intensities are live and sourced. An SCI figure with a large, server-dominated embodied share is at its softest there.
PUE is a user input. Power usage effectiveness is a large multiplier on the operational term and is entered by the user (default 1.5). Reference values are shown as a helper; the calculator does not assume a facility’s PUE. A figure using the default for a hyperscale workload overstates the operational term.
Boundary and allocation are the user’s responsibility. The calculator computes what it is given. Declaring the system boundary, allocating shared hardware and energy via the resource-share fraction, and setting service life and utilisation honestly are the user’s decisions, and they drive the result more than the arithmetic does.
Failure mode. Master Brain reads are guarded: if a grid or device factor is unavailable at load, the engine falls back to its built-in value rather than emitting a blank or a silent zero, and the result stamps the live Master Brain version so the vintage is always recoverable.
No assurance opinion. Results are estimates for engineering analysis and screening-level disclosure. The absolute total should be reconciled into the appropriate Scope 2/3 inventory line by a qualified practitioner before external use, and the audit trail (component energy, intensity basis, PUE, embodied amortisation, and declared R) should be exported and checked against telemetry. The full methodological treatment is on the paired SCI methodology page.