If your organisation reports under the EU's corporate sustainability directive, the electricity your software uses is already in the numbers you sign off, but usually only as a supplier's estimate. This film shows how GreenCode measures software energy the way teams measure test coverage, and records it so that a reported figure can be traced back to what produced it.
Read the full page Watch on YouTube
If your organisation reports under the corporate sustainability directive, the electricity used by your software already sits inside the numbers you sign off: your own servers in one scope, cloud and leased capacity in another. The problem is the quality of the evidence. Most organisations know their IT emissions only as a line on a supplier's carbon statement, or a spend-based estimate. They cannot say which applications drive the total. And the gap is structural: disclosure is mandated, but there is no software-specific methodology behind it.
GreenCode treats energy as a measured property of software, like test coverage or response time. Its pipeline takes a codebase, reconstructs a representative version of its infrastructure, benchmarks it under load, and records energy use before and after each optimisation. Each measurement is tied to a specific release, a configuration and a test run, so a reported number can be traced back to what produced it.
Even where energy is measured today, the results are rarely in a form suitable for assurance, certification or comparable procurement claims. So the project's requirements make the fix a top priority: a certification-ready evidence bundle containing the measurement boundaries, the assumptions, the allocation rules, the tool versions, the diffs and the test results, with a human-readable report of what was changed and what it saved. The underlying carbon intensity specification is now an international standard, aligned with the greenhouse gas protocol, so it fits inside a corporate inventory.
Software-level measurement can produce activity data for a defined workload on specified hardware, show that a change reduced it, and rank applications so reduction effort goes where the energy is. It cannot replace the emission factors your provider publishes, because hardware counters are not exposed in public cloud, and any per-service figure there is an estimate. The specification is weak on multi-tenant allocation, so GreenCode states the rule it uses and attaches a confidence grade rather than hiding it. What it does is turn an estimate into a figure with a method behind it. Software emissions become a managed line rather than an inherited one, with a baseline and a measured trend. Reduction claims in a sustainability report or a tender response are backed by a reproducible test rather than a supplier's average, and the same evidence tells the engineering team where the energy is being spent. The tooling is being built and validated on partner use cases now. Reach out to us with the emissions line you cannot explain, and we will help you understand how GreenCode can put a method behind it.
Benefit film
AI is the fastest-growing consumer of energy in the ICT sector, so any tool that uses AI to cut software energy has to prove the cure costs less than the disease.
Benefit film
Ask an engineering manager where the team's time goes and the answer is rarely new features.
Benefit film
By published estimates, most software in service is legacy, and in banking and healthcare systems written decades ago still carry the transactions and the patient…
