Almost every organisation that starts working with sustainability data starts with CO2. Not because a directive prescribes that order, but because CO2 is the topic for which the most ready-made calculation methods exist, the most external benchmarks are available, and the most software vendors already have a dashboard ready. Energy consumption, fuel, vehicle fleet, these are figures that are often already recorded somewhere for another purpose, usually invoicing. They are reused, not collected.
That makes CO2 the easiest topic to show, not the most complete one. Social data, supply chain information and biodiversity indicators rarely have comparable infrastructure. There is no invoice there that already contains the answer. Anyone who looks only at CO2 therefore sees a fraction of the data landscape, and sometimes concludes from that that the rest will also fall into place. That has not been established, it has been assumed.
A CO2 figure that matches an external benchmark is not proof that the underlying data is verifiable. The figure may come from a spreadsheet managed by one person, with a conversion factor that no one can trace back to the source anymore. It is correct, until that person is on holiday or leaves. That is a different problem from the figure itself: it is a question of ownership and provenance, not of arithmetic. How that ownership is recorded as standard is described in who reads your data point register once you're gone.
The scan we are building is not about the CO2 figure itself. It is about the question of where that figure comes from, who supplies it, what processing it undergoes before it ends up in a report, and what control exists over that. We call that lineage: the route from source system to report line, per data point. For CO2 that route can often still be reconstructed, because the source is usually an invoice or a meter reading. For other topics that route is more often unclear, and that is precisely where the risks lie that a CO2 dashboard does not show.
The assumption that a CO2 approach can be copied to other topics is partly correct. The structure — data point register, provenance, ownership, quality rule — is the same for every topic. But the data sources are not. An employee survey has a different error sensitivity than an energy invoice. A supplier questionnaire has a different update frequency than a meter reading. Anyone who copies the CO2 process one-to-one to social or supply chain indicators runs into gaps that did not exist for CO2, simply because there is no comparable source there.
This is also why a tool set up for CO2 reporting does not automatically work for the rest of the topic. Whether an organisation is ready for that does not depend on the tool but on how much has already been recorded about sources, owners and control points. How to measure that readiness is worked out in what is data maturity and how do you measure it. For those who think spreadsheets are the core of the problem: that is a misconception addressed separately in why spreadsheets are not the problem, because the problem rarely lies in the file format and more often in the absence of a recorded provenance.
As soon as an accountant or assurance provider comes on board, the difference between a good CO2 dashboard and a good data point register becomes immediately visible. Assurance does not ask about the final figure, but about the route to it: which source, which processing, which control. A CO2 figure that is correct but cannot be traced is just as problematic for assurance as a figure that is not yet correct. How that verifiability per data point is built up is described in how do you make esg data verifiable for assurance. For CO2 that work has often already been partly done, precisely because infrastructure already existed. For the rest of the reporting, it usually still has to begin.
This way of working does not determine which topic an organisation should address first, and says nothing about whether CO2 is substantively the most important topic. That is a different choice, with different considerations. What the scan does do is provide clarity about the state of the data behind each topic separately, so that a choice of order is based on what is already in place and not on what was easiest to show. Anyone considering that route can sign up for the waiting list; the scan is under development and is not yet offered as a finished product. What changes once the lineage for a topic has been recorded is described in what changes once the lineage is in place.
Mapping data points, sources and ownership is partly manual work, and partly work that can be accelerated once the structure is in place: recognising patterns in sources, filling in standard fields, flagging missing links. Which part of that work can be handed over to AI and which part remains human work is precisely what the work scan from FTE TO AI answers, calculated per task.
Vraag maar waar een datapunt vandaan komt. Dat is meestal de hele vraag.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.