A figure in a sustainability report is almost never a figure straight from a source. It is usually the result of adding, averaging, weighting, or redistributing across locations, periods, or units. This step is called aggregation, and of all the operations between source and report, this is often the least visible. A formula in a spreadsheet adds up twelve monthly figures into an annual figure, or a calculation sheet averages emission factors across multiple suppliers. Nobody writes down which assumption is built into it.
Between the raw measurement and the published figure lie several steps. First data is collected from systems or spreadsheets, then converted to a common unit, then combined into a level that fits the report — business unit, country, or total. Each step can contain a choice that changes the final figure: do you count a merger from the acquisition date or for the full year, do you weight the average by revenue or by number of employees, do you round per source or only on the total. Which operations exactly sit between source and report depends on the indicator and the structure of the organization, and on which operations sit between source and report when the source has multiple sources, that list grows longer than most organizations expect.
Aggregation is a choice, and choices that are not recorded get made again at the next reporting round — often by someone else, with a different assumption. The result is that a figure from last year can no longer be traced back to the same logic, and that a controller or auditor cannot determine whether a change in the figure is a real change or a change in the calculation method. Recording here does not mean: describing a process in general terms. It means: for each reporting point, recording which sources were included, with which weighting, over which period, and who made that choice.
Aggregation is often confused with normalization, but they are two separate steps. Normalization makes data comparable — for example by converting different energy units to one standard. Aggregation then combines that comparable data into a higher level. An error in normalization carries through into every aggregation that follows it, which means the two steps need to be checked separately. How you do that is described on how do you record normalization.
Most organizations do not have source data that comes neatly out of a single system. Part of the sustainability data sits in invoices, part in a spreadsheet an energy supplier sent by email, part in an export from an ERP system. Aggregation across those sources means you have to manually determine which row belongs to which period and which row has been counted twice. What is source-to-report mapping when the source is a spreadsheet describes how you map that link between raw source and reporting point, and how do you record aggregation when the source is a spreadsheet describes specifically how you document that spreadsheet step so the aggregation itself becomes reproducible, even without the person who originally built the formula.
Recording aggregation does not require software. It requires discipline: noting for each calculation step what went in, which rule was applied, and what came out. That can be done in a register alongside the existing spreadsheets, before any system is ever purchased. What that looks like without tooling is described on how do you build lineage without a tool. Anyone who skips this step and immediately purchases a software package for reporting is laying a tidier layer over the same unclear aggregation — the report looks better, but the question of whether the figure is correct remains unanswered.
An aggregation rule that has not been recorded is also a missing control point. During an external audit or an internal review, someone must be able to demonstrate why a figure was put together the way it was, not just that the figure matches the calculator. That distinction — between a figure that is correct and a figure that can be accounted for — is exactly what an audit trail is for, and why it involves more than a simple log of changes, as explained on why an audit trail is more than a logbook.
Once aggregation rules have been recorded — which sources, which weighting, which period, who made the choice — a basis emerges for determining which part of that work is repeatable and therefore suitable for handing over to a system. That is a different question from whether the rules are correct; it is the question of how much of applying those rules still needs to remain human work. The work scan from FTE TO AI calculates per task which part of the work can be taken over by AI, and aggregation — with its fixed steps of adding, weighting, and combining — is exactly the type of task where that outcome is often surprising.
The Data Readiness Scan from csrdready.net is under development. Anyone who wants to bring order to the data point register and the associated aggregation rules now can sign up for the waiting list and will be informed as soon as the scan becomes available.
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.