Carbon Accounting Across Multiple Entities and Countries

If you run across several entities and countries, you already know the footprint isn't the sum of the subsidiaries: each is its own boundary, calculated with its own jurisdiction's factors, then consolidated. That part is well understood. The hard part, where most of the work and risk live, is everything underneath it: getting comparable, complete data out of every entity, and resolving the messy middle before any of it can be added up.

This is about the method for a group, whatever system each entity runs. For the spend-based vs activity-based choice, see spend-based vs activity-based accounting; for the scopes, a scope review for the GHG Protocol. If every entity runs NetSuite OneWorld, there's a system-specific version in consolidating carbon across subsidiaries.

Where multi-entity groups actually get stuck

None of this is the theory. Every team running a group knows you calculate each entity on its own boundary, with its own factors, then consolidate: that part is settled. Groups get stuck upstream of the method, on getting comparable, complete data out of every entity. Pull a group together and the data never arrives evenly: the parent is well covered, newer or smaller entities come in patchy (some with barely any structured data), and the value-chain sources are thinnest of all, everywhere. The factors are the easy bit; the raw material is the problem.

Illustrative: the point is the pattern, not the numbers. A readiness matrix like this is the first thing worth building, because it shows where the work is.

Ground on the ledger, then work outward

The general ledger is the one system every entity has, so it is the spine to build from. Scope 1, 2 and 3 source documents (vendor bills, utility invoices, fuel and fleet records, freight bills) are pulled from whatever ERP each entity runs, or exported where a system doesn't connect, then reconciled against the ledger so nothing material is quietly missed. That completeness check turns a pile of documents into a defensible group total. From there, the work moves outward into the activity data the ledger can't resolve on its own.

These documents already cover a surprising amount of the footprint, across all three scopes. Worth seeing what comes out of the ledger before deciding what still has to be chased:

The messy middle: what the Analyst handles

The documents rarely arrive ready to calculate from. Units differ between entities, bills cover space you don't solely occupy, freight is priced with no distance behind it, and half of it lands as PDFs in local formats. Our AI Sustainability Analyst is built for this middle layer: it reads each document, normalises it, picks a defensible method, and, crucially, flags every judgement call rather than burying it. A few examples of what it does with the mess:

Calculate per entity, consolidate like your financials

With each entity calculated on its own local factors, the group total consolidates by operational control, financial control or equity share: the three GHG Protocol approaches, which mirror the logic of your financial consolidation (though the Protocol notes the evaluation is not identical).

Because the ASRS, the UK SRS and New Zealand's Climate Standards all build on the ISSB's IFRS S1/S2 baseline, a group can assemble one IFRS S2-aligned core and reuse most of it. But no regime takes it unchanged: each layers on its own modifications, spanning not just thresholds and timing but what sits in scope and the legal framing.

The whole sequence, end to end, is the same for every entity no matter how its data arrives, which is what makes it a repeatable process across the group rather than a fresh scramble each year: