ESG and Sustainability Reporting From Asset and FM Data

There is a lot of ESG content out there. Almost none of it answers the only question that matters once the strategy is signed off: where does the underlying number physically come from, and how do you prove it if an auditor asks. The framework decks talk about materiality, boundaries, and narrative. They stay well away from the plumbing. This article is the plumbing. It is written for the person who has to hand an ESG consultant a defensible figure for Scope 1 fuel, Scope 2 electricity, water, and waste, from a business that runs on physical assets.

I sit on the operational side. For 22 years I have run the systems that these numbers actually live in, the CMMS, the EAM, the fleet logs, the meter feeds, and the Power BI models that pull them together. The consultant owns the disclosure. I own the pipe that feeds it. This is how I build that pipe so the output survives scrutiny.

Where the data physically comes from

The mistake most reporting projects make is starting from the disclosure template and working backwards, treating data collection as a survey exercise: email the site managers, ask them to fill a spreadsheet, aggregate the returns. That produces a number, but it is a number with no evidence behind it and no way to reproduce it next year. When the external assurance provider pulls a sample and asks "show me the source for this refrigerant figure," a spreadsheet cell does not answer the question.

In an asset-heavy business, every material ESG figure already exists somewhere in an operational system. It was captured for an operational reason long before anyone cared about disclosure. Fuel was logged because someone paid for it. Electricity was metered because the utility billed for it. A refrigerant top-up was recorded because a technician did the work and closed a job. The reporting task is not to invent the data. It is to find the system of record that already holds it, extract it consistently, and keep a trail back to that source. Get the sourcing right and the disclosure writes itself. Get it wrong and you are estimating.

The word that matters here is auditable, and it means something specific. A number is auditable when a third party who was not present when it was captured can start from the published figure, follow it back to the raw records it was built from, and satisfy themselves that the two agree without taking your word for anything. That is a higher bar than accurate. A survey return can be accurate and still fail assurance, because there is no way to independently reconstruct it. A meter reading tied to an invoice passes, because the invoice is issued by someone with no incentive to help you inflate or deflate the figure. So the sourcing decision is not only about finding a number, it is about finding the version of that number with the strongest external corroboration attached to it.

Mapping each disclosure line to its system of record

Frameworks such as the GHG Protocol, the ISSB standards, GRI, and the CSRD-aligned ESRS all ask for broadly the same operational inputs even where the presentation differs. Portfolio benchmarks like GRESB go further and ask for asset-level intensity, energy, water, and waste per square metre per asset, which forces you to hold the data at the individual building rather than as a portfolio total. The GHG Protocol defines the scope boundaries that decide which of your systems is even in play.

Here is the mapping I start every engagement with. Each disclosure line points to the operational system that already holds the raw record, and to the field you extract from it.

Notice the pattern. Scope 2 is the easy end because electricity and district energy are billed, and invoices plus meters give you a clean, externally corroborated number. Scope 1 is harder because it is scattered: fuel across fleet and generators, refrigerant buried inside maintenance records. Water and waste sit with third-party contractors whose collection notes you have to pull in and normalise. Asset-level intensity is not a source at all, it is a join, meter reads against the asset register and gross floor area, which only works if those two datasets share a clean asset key.

The refrigerant trap that hides in your work orders

Refrigerant deserves its own section because it is the line most asset-heavy property portfolios get quietly wrong. Refrigerant gases have very high global warming potential, so a modest leak of a few kilograms can dwarf a whole fleet's fuel emissions once converted to CO2 equivalent. For a property portfolio it is often one of the largest and most material Scope 1 lines, and it is almost always the least well captured.

The reason is structural. Refrigerant leakage does not exist as a tidy meter reading. It exists only as an operational event: a chiller loses charge, a technician is dispatched, they top it up, they close the work order. In most CMMS and CAFM systems that top-up is recorded as free text in the job notes, "recharged unit, added gas," with no structured quantity and no gas type. You cannot aggregate free text. So the reporting team, unable to extract a number, falls back on an estimate, typically a flat percentage of installed charge, which is exactly the kind of unsupported assumption an assurance provider circles first.

This is the single highest-leverage change I make on these projects, and it costs nothing. The point generalises: before you build any pipeline, walk the disclosure lines and check that each one has a structured field at source. Where it does, extraction is trivial. Where it does not, a small configuration change now saves you from a full year of estimated, unauditable data.

The collection architecture: evidence store beside the model

Once every line has a real source, the architecture has one job that ordinary BI does not: it must keep the evidence, not just the answer. A standard reporting model transforms raw data and discards the intermediate. An auditable ESG model has to hold the raw extract, unchanged, alongside the transformed figures, so that any published number can be traced back to the exact source rows and files it was built from.

I build it as two parallel destinations fed from one ingestion layer. The reporting model is the fast, aggregated layer that Power BI reads. The audit-evidence store is a separate, append-only layer that keeps every raw extract, every source invoice or collection note, and a calculation log recording which emission factors and conversions were applied and when. Both are populated by the same pipeline run, so they can never drift apart.

The dashed "trace" line is the point of the whole diagram. Every figure the reporting model publishes can be walked back to the raw rows in the evidence store, and from there to the original invoice, meter export, or work order. When an assurance sample lands, you are not scrambling through inboxes, you are clicking through from the dashboard number to the source document. That is what auditable means in practice, and it is the difference between a report that passes review and one that gets qualified.

In practice I run the ingestion on a scheduled refresh, and each run stamps every extracted row with a batch identifier, the source file name, and the timestamp it landed. That stamp is what makes the evidence store useful rather than just large. When a figure is questioned six months later, the batch identifier is the thread you pull: it tells you which run produced the number, which source files fed that run, and which emission factors were in force at the time. Nothing is overwritten. If a utility issues a corrected invoice, the correction lands as a new batch and the original stays in place, so the history of what you reported and why is preserved rather than quietly rewritten. Assurance providers care as much about that immutability as they do about the numbers themselves.

The mechanics of building this in Power BI are the same as any well-structured model: a fact table per metric, conformed date and asset dimensions, and measures that apply emission factors as a separate, versioned step rather than baking them into the raw data. Keeping the factors in their own table matters more than it looks. Factors are revised, and when a published factor changes you want to be able to say precisely which one you applied to last year's figure, not silently restate the past. If you want the modelling discipline behind that, I cover the structure of a metric hierarchy in building a KPI tree, and where the source data commonly comes from on the finance side in connecting Business Central to Power BI. The ESG twist is only the evidence store running in parallel.

The data-quality scorecard visual

The second thing an auditable model needs that ordinary BI skips is a visible measure of how good the underlying data actually is. Not every figure in an ESG report is equal. Some lines are metered and invoiced, corroborated by a third party. Some are structured system records. Some are still estimates. The report should say which is which, and the way I surface that is a data-quality scorecard, a small visual that grades every disclosure line on the confidence of its source.

It is a simple matrix, one row per line, coloured by the strength of the evidence behind it. Metered and invoiced data scores highest. Structured operational records score in the middle. Anything estimated or manually keyed scores lowest and is flagged for remediation. Here is the shape of it.

This visual does two jobs. For the internal team it is a work list, the low-confidence rows are exactly where next year's effort goes, and you can watch refrigerant climb from low to high as the new work-order field accumulates real records. For the assurance provider it is a statement of honesty: you are not pretending every number is metered, you are showing which lines are strong and which are still maturing. Auditors trust a report that grades its own confidence far more than one that presents everything as equally certain. Tracking whether the operational teams actually use the new fields, rather than assuming they do, is its own discipline, and I approach it the way I describe in measuring BI adoption from usage data.

Independence, and what this article is not

A necessary boundary. I build the data pipeline. I do not provide assurance, and nothing here is regulatory or reporting advice. Which figures are material for your organisation, how your boundaries are drawn, which framework applies, and whether a given calculation is compliant are decisions for your ESG consultant, your reporting lead, and above all your external auditor. My role is upstream of theirs: to make sure that whatever they decide to disclose, the number behind it is sourced from a real system of record and can be traced back to it.

Conclusion

The strategy decks stop where the real work starts. Every material ESG figure in an asset-heavy business already exists in an operational system, fuel in fleet and generator logs, electricity in meters and invoices, water and waste with your contractors, and refrigerant hidden in maintenance work orders. The job is not to invent those numbers, it is to source them from the system that holds them, keep the raw evidence beside the aggregated model, and grade the confidence of each line honestly. Do that and your ESG consultant's deliverable rests on something an auditor can follow all the way back to a technician closing a job. That is the operational plumbing, and it is where I work.