Sustainability reporting stopped being a corporate-affairs exercise somewhere around the first CSRD-aligned filing season. Once emissions numbers sit next to financial numbers in the same annual report, subject to the same assurance expectations, finance inherits the problem — and finance notices immediately that the data arrives as a folder of supplier spreadsheets, utility PDFs, and a consultant's model nobody can re-run.
That is a planning problem, not a reporting problem, and it looks remarkably like the ones Anaplan already solves. You have a sparse transaction set (activity data), a set of conversion factors that change by year and geography, an entity hierarchy that already exists in your consolidation model, and a forward-looking plan — the decarbonization trajectory — that has to be reforecast quarterly and tied back to capex and opex.
This tutorial walks the build of a carbon and ESG planning model in Anaplan: inventory, forecast, abatement levers, internal carbon pricing, and a disclosure output that an auditor can trace. It assumes working familiarity with lists, subsidiary views, SUM/LOOKUP, and time ranges.
What the model has to do
Write the jobs down before you create a single list. Four of them:
- Inventory — collect activity data and convert it to tCO2e across Scope 1, Scope 2 (location and market based), and the Scope 3 categories that are material to you.
- Baseline and target — fix a base year, restate it when the group changes shape, and carry a target trajectory against it.
- Plan — model abatement initiatives with a cost, a timing profile, and an emissions effect, and roll them into a forecast.
- Disclose — produce auditable outputs with factor provenance, restatement history, and a variance story.
Anything that does not serve one of these four is scope creep. ESG models attract scope creep the way data hubs attract orphan lists.
Dimensions: borrow, do not invent
The single biggest failure mode in an ESG build is creating a parallel universe of entities. Your carbon model must consolidate on the same legal-entity and management hierarchies as your financial model, or the first question from the assurance provider — "why does this cover 94% of revenue?" — has no answer.
Reuse from the data hub:
- Entity — the same consolidation hierarchy used in the three-statement model, with an ownership percentage property so you can switch between operational control and equity-share boundaries.
- Time — monthly actuals, annual plan out to 2050. Use separate time ranges. A 2050 horizon at monthly granularity is a classic way to turn a 2 GB model into a 40 GB one for no analytical gain.
- Geography — needed because grid emission factors are regional, not global.
Create new:
- Emission Source — a flat list of activity types (natural gas combustion, diesel fleet, purchased electricity, business air travel, purchased goods by spend category, upstream transport, use of sold products). Property: scope, category, default unit, default calculation method.
- Scope / Category — a small hierarchy, Scope 1 / Scope 2 / Scope 3 with the fifteen GHG Protocol categories beneath Scope 3. Only build the categories you will actually populate.
- Factor Set — the versioned library of emission factors. This is the list most teams forget, and it is the one assurance cares about most.
- Initiative — the abatement project list, the sustainability equivalent of a capex request.
Module 1: the activity data spine
DAT01 Activity Data dimensioned by Entity × Emission Source × Time (monthly), holding quantity, unit, data quality flag, and source system. One module, one grain, no derived values.
Data quality is a line item, not a comment. Use a three-level list — metered, invoiced, estimated — because your disclosure has to state how much of the inventory is primary data, and because the auditor will sample the estimated rows first. A boolean "restated" flag belongs here too.
Resist the urge to let business units type emissions in tCO2e directly. The moment someone can enter a converted number, factor provenance is gone and the inventory cannot be recalculated when a factor is revised.
Module 2: factors, versioned properly
DAT02 Emission Factors dimensioned by Factor Set × Emission Source × Geography × Time (annual), holding factor value, unit, source reference, and publication year.
Why Factor Set rather than a single current factor? Because factor libraries are revised annually and retroactively, and because market-based Scope 2 needs a different factor to location-based Scope 2 for the same kilowatt-hour. A Factor Set dimension lets you:
- recalculate the entire history on a new library and quantify the restatement, rather than discovering it line by line;
- keep "as-reported" and "as-restated" views side by side, which is exactly the comparative the standard asks for;
- run location- and market-based Scope 2 as two members instead of two modules.
Factor lookups are a sparsity trap. Dimensioning the factor module by Entity because the formula is easier to write will multiply cell count by the size of your entity list for no information gain. Keep factors at Geography grain and LOOKUP across.
Module 3: the inventory calculation
CAL01 Emissions Inventory, same grain as activity data, with the factor applied:
Gross tCO2e = DAT01.Quantity
* DAT02.Factor[LOOKUP: Source Geography, LOOKUP: Selected Factor Set]
* Unit Conversion
Then, in separate line items, the consolidation treatments: ownership share, boundary inclusion flag, and finally net reported tCO2e. Keep purchased instruments — renewable energy certificates, PPAs — in their own line item applied only to the market-based Scope 2 member. Netting them invisibly into the gross number is the fastest way to fail an assurance review.
Add a Spend-Based Fallback line item for Scope 3 categories where supplier-specific data does not exist yet, driven off procurement spend from the financial data hub times a spend-based factor. Flag every cell that used it. Year over year, the share of Scope 3 on spend-based estimation should fall, and that ratio is itself a reportable metric.
Module 4: baseline, target, and restatement
CAL02 Baseline and Target dimensioned by Entity × Scope × Time (annual).
The base year is a selected member, not a hard-coded year. Recalculate the base year inventory whenever the Factor Set or the entity boundary changes, and hold both Base Year as Originally Reported and Base Year Restated so the delta is visible rather than silently absorbed. Most restatement disputes are really arguments about an acquisition that was never pushed back into the baseline.
Target trajectory: hold an absolute or intensity target percentage by target year, then interpolate the linear annual pathway between base year and target year. Intensity targets need a denominator — revenue, units produced, square metres — pulled from the financial model, not typed in.
Module 5: abatement initiatives
This is where the model earns its keep, and where it stops being a reporting tool and becomes a planning tool. DAT03 Initiative Register dimensioned by Initiative, with properties and inputs: owning entity, affected emission sources, status (proposed / approved / in flight / delivered), start period, ramp profile, annual abatement at full run rate, capex, opex delta, and expected energy cost saving.
Then CAL03 Initiative Phasing, dimensioned by Initiative × Time (annual), applying the ramp:
Abatement tCO2e = Annual Abatement at Run Rate
* Ramp Factor[LOOKUP: Ramp Profile]
* Status Weighting
Status weighting is the honest part. Proposed initiatives at 100% certainty is how companies end up with a decarbonization plan that misses by a third. Weight proposed at something like 40%, approved at 80%, in flight at 100%, and let the sustainability lead justify the weights rather than the model hiding them.
Marginal abatement cost — capex plus NPV of opex delta, divided by cumulative tCO2e avoided — belongs in this module. Sorting initiatives by MACC is the single most useful dashboard view in the entire model, and it converts the sustainability conversation into a capital allocation conversation your CFO already knows how to have.
Module 6: internal carbon price and the financial bridge
Two line items that most ESG models skip, and the two that get the model funded.
Shadow price: multiply forecast residual emissions by an internal carbon price by year, and surface the result as a memo line on the capex business case. Projects suddenly rank differently.
Actual cost exposure: where a compliance scheme bites — EU ETS allowances, CBAM certificates on imported goods — model it as a real cost with a real allowance balance. Dimension by Entity × Time, with free allocation, purchased allowances, and the price curve as explicit inputs. This flows to the P&L in the financial model like any other cost driver, and it is the line item your treasury team will ask about first.
Module 7: disclosure output
RPT01 Disclosure Pack, dimensioned by Entity × Scope/Category × Time, publishing exactly the figures that go into the filing: gross Scope 1, Scope 2 location, Scope 2 market, Scope 3 by category, intensity ratios, percentage primary data, and base-year comparatives.
Three things make this pack auditable rather than merely presentable:
- Provenance. Every reported figure should be traceable to a factor set reference and an activity data grain. Build a drill path in the UX from the disclosure number to the underlying activity rows.
- Immutability. Snapshot the filed figures into a reported-version member at filing. Live recalculation of a number already published to the market is not a feature.
- Variance narrative. A text line item per material movement, decomposed into volume effect, factor effect, boundary effect, and genuine abatement. Auditors and investors both ask the same question — "is this number down because you emitted less, or because the factor changed?" — and the model should answer it without a human reconciling anything.
Integration and cadence
Activity data arrives monthly from utility billing, fleet telematics, travel platforms, and the ERP spend ledger. Route it through the data hub with Data Orchestrator or CloudWorks on the same schedule as financial actuals — a separate pipeline for ESG data drifts out of sync within two quarters.
Factor libraries update annually: a single import, then a deliberate decision about which reporting periods to recalculate. Initiative registers update quarterly alongside the capex reforecast, because an abatement plan that is not reviewed in the same cycle as the capital plan is a plan nobody is funding.
Testing before you trust it
Run the same regression discipline you would on a financial model. Fix a period, change the Factor Set, and confirm the delta equals the factor change times the activity quantity and nothing else. Add an entity mid-year and confirm the baseline restates. Set all initiative statuses to proposed and confirm the forecast trajectory moves by exactly the weighted abatement. Reconcile total spend-based Scope 3 to the procurement ledger to the pound.
Where this usually goes wrong
Three patterns we see repeatedly on rescue engagements:
- Entity lists cloned instead of shared, so the carbon boundary and the consolidation boundary quietly diverge and nobody can reconcile coverage.
- Factors hard-coded in formulas, which turns the first annual factor revision into a two-week manual rebuild.
- Scope 3 modelled at supplier grain for forty thousand suppliers, when category-and-spend-band grain would have answered every question asked of it at a fraction of the size.
Built properly, the carbon model is not a compliance appendix. It is another driver tree hanging off the same data hub as the financial plan, with the same cadence, the same ownership, and the same scrutiny — which is the only arrangement under which the numbers ever get good.
If you are standing up ESG and carbon planning in Anaplan, or trying to get a stalled sustainability model to the point where it will survive assurance, get in touch — our consultants build these alongside the financial models they have to reconcile with.