If you run NetSuite OneWorld, your group is already made up of several subsidiaries sitting across different countries and currencies, and a carbon footprint has to follow that same structure, calculated separately for each entity with the right factors for its jurisdiction and only then consolidated into a single group figure. That is a harder problem than a single-entity footprint, but it maps closely onto the data OneWorld already holds, which is what makes NetSuite a sensible place to build the footprint from in the first place.
For the underlying method, turning ERP spend and activity into emissions, see carbon accounting for NetSuite users. This piece is narrower: the multi-entity, multi-jurisdiction consolidation problem that OneWorld groups run into, and how to solve it without a parallel spreadsheet per subsidiary.
Why multi-entity carbon is a different problem
You cannot simply add your subsidiaries together, because each entity is its own reporting boundary and entities in different countries sit on different electricity grids, buy from different supply chains and, most importantly, carry different emission factors, so that a kilowatt-hour of grid electricity in the United Kingdom, Australia and Singapore each converts to a different quantity of CO2e. A group total assembled by applying one global factor to everyone's spend is therefore wrong for almost every entity at the same time, and the only reliable way to avoid that is to calculate each subsidiary on its own terms first and consolidate the finished results afterwards rather than the other way around.
Calculate per entity, with the right local factors
Each subsidiary's procurement and activity data is mapped with the emission factors for its own jurisdiction, so that the UK entity is calculated with UK grid and DESNZ conversion factors, the New Zealand entity with the Ministry for the Environment set, the Australian entity with the National Greenhouse Accounts factors, and so on for every country the group operates in. The figure for each subsidiary is built entirely from its own factors before anything is rolled up to the group, which is the step that single-jurisdiction tools skip when they apply one factor set across the whole group and end up misstating every entity whose grid and supply chain do not happen to match that single set.
“Because each subsidiary sits on a different grid and buys from a different supply chain, a group footprint assembled from a single global factor will misstate most of the entities inside it, which is why the factors have to be resolved entity by entity before the group total is ever put together.”
Why per-entity factors come firstConsolidate the way your financials already do
Once each entity has been calculated, the group total is consolidated using operational control, financial control or equity share, which are the three approaches defined in the GHG Protocol Corporate Standard and the same choice you already make when you consolidate your financial statements. Because OneWorld already models your subsidiary hierarchy, ownership percentages and eliminations, a connector can read that structure directly, so that every line arrives tagged with the entity it belongs to, the roll-up applies whichever consolidation approach you have chosen using the ownership data already held in NetSuite, and multi-currency lines fold into a parent-currency total in the same way your financials already do. The effect is that your carbon consolidation stays aligned with your financial consolidation instead of diverging from it in a separate workbook that nobody can reconcile once year-end arrives.
One disclosure, many jurisdictions
A OneWorld group often has to report under more than one regime at the same time, such as the ASRS in Australia, the UK SRS in Britain, the Climate Standards in New Zealand, and the SEC and state rules in the United States, and because these are all built on the ISSB's IFRS S1 and S2 baseline, the group can produce a single IFRS S2-aligned disclosure that satisfies each local variant instead of running a separate reporting exercise country by country. What actually differs between jurisdictions is mostly the reporting thresholds, the phase-in timing and the local factor sets rather than the structure of the disclosure itself, so the parts of the process that have to be jurisdiction-aware are the factors and the consolidation, while the disclosure carries across markets largely unchanged.
Keeping it defensible across a group
With many entities feeding into a single number the audit trail becomes more important rather than less, because every figure in the group total has to trace back to the subsidiary it came from and the transaction that produced it, so that an assurer or your own finance team can move from the group total down to an individual entity and from that entity down to the underlying purchase order or invoice. When that trail is captured as the data is read out of NetSuite rather than reconstructed months afterwards, following any number back to its source stays a matter of a few clicks even across a group of a dozen or more subsidiaries.
Consolidation that matches your books. How our AI Sustainability Analyst handles NetSuite OneWorld:
Related reading
The accounting method behind the numbers: carbon accounting for NetSuite users. How a carbon tool connects to NetSuite: choosing a NetSuite carbon integration. Getting the source basis right per entity: spend-based vs activity-based accounting.
Consolidate carbon across every entity, on one disclosure
Our AI Sustainability Analyst reads your OneWorld structure, calculates each subsidiary with its own local factors, and rolls the group up the same way your financials already consolidate, keeping the source transaction behind every figure it produces.
See the NetSuite integration