A spreadsheet with energy consumption per site is not a problem in itself. The problem arises in the next step: how those rows are combined into the number that appears in the report. That step often happens in a formula, a pivot table, or, worse, in the head of whoever updates the spreadsheet each year. No one else knows exactly which rows were included, which were excluded, and why.
Aggregating sounds like calculation, but it is a series of choices. Do you include sites that were closed for part of the year? Do you include leased locations or only owned ones? Do you calculate by calendar year or fiscal year? Each choice changes the final figure, and in a spreadsheet these choices are usually not recorded separately. They are embedded in a formula that refers to cells, without a readable line stating: this is the aggregation rule, and this is why.
As soon as someone takes over the spreadsheet, or a controller wants to reproduce a comparable figure a year later, that explanation is missing. The formula still works, but no one can assess anymore whether it is still correct for this year's situation.
Between the raw row in the spreadsheet and the number in the report there are usually several steps: selection of the relevant rows, conversion to a unit, addition or weighted average, and sometimes a correction for missing months or locations. Each step can have its own rule, and each rule can change without that being recorded anywhere.
The question that then matters: if a controller asks how this figure was built up, can you point to the steps one by one? Not reconstruct the outcome by working backward through the formula, but show the rules themselves.
An aggregation rule that only exists in a formula is neither verifiable nor transferable. Recording means: noting separately from the spreadsheet which aggregation was applied, to which selection, with which exceptions, and who established that rule. That is not an extra document alongside the spreadsheet; it is the explanation that makes the spreadsheet usable as a source for a reporting point in the first place.
Without that explanation, an aggregation rule changes unnoticed. Someone adds a site to the list, adjusts the formula, and this year's figure is no longer comparable to last year's. Not because the underlying data has changed, but because the way of adding up has quietly been adjusted.
Aggregation is one of the places where spreadsheets hide aggregation errors, but not the only one. Similar questions apply to units and definitions: see how you record normalization when the source is a spreadsheet for the step that often comes before aggregation. And to map the full path from raw row to report figure, even without specialized software, there is how you create lineage without a tool when the source is a spreadsheet. Both connect to the broader question of what source-to-report mapping precisely involves, in which aggregation is one of the steps that is documented.
An aggregation rule, like a data point, needs someone responsible for the choice behind it. Not the person who happened to write the formula, but the person who can explain why this selection and this calculation method were chosen, and who approves a change before it is implemented. This question relates to who owns the definition of a data point: the definition determines what is measured, the aggregation rule determines how measurements are combined into a reporting figure. Both belong to someone with a name, not to a spreadsheet passed from hand to hand.
Recording aggregation rules is not a one-time exercise. It is a question that keeps coming back as soon as the organization changes: a new site, a new unit, a merger. That is why it is not enough to document this once; there must be a process that repeats the recording with every change. Who oversees that process and when an aggregation rule is revised is a question that touches on who owns the process underneath, separate from who supplies the individual figures.
This page describes what is needed to make aggregation transparent. The Data Readiness Scan is the tool that helps record this for your data points: the register, the source-to-report lineage per point, and the ownership rules. That tool is under construction. Anyone who wants to start with this now can sign up for the waiting list.
Once aggregation rules have been recorded, with an owner and a reason, a different kind of work arises: carrying out and checking those same steps, year after year. Much of that execution work, from selecting rows to adding up numbers according to a fixed rule, is the kind of task for which a work scan from FTE TO AI can calculate which part can be taken over by AI, per task, based on exactly what the work involves.
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.