Most sustainability data doesn't begin in a system with an audit trail. It begins in a spreadsheet that someone in the facilities department maintains, in an export from an energy supplier that gets typed in by hand, or in a tab that a different colleague fills in three times a year. That's not a problem that a tool solves. It's a matter of recording what happens between that spreadsheet and the figure in the report, with or without software.
Lineage is nothing more than the answer to the question: where does this number come from and what has been done to it along the way. In an automated system, the software records part of that. With a spreadsheet, nobody does that automatically, so it has to be done manually. That doesn't mean it's more complicated, only that it has to be made explicit. The same logic applies to what source-to-report mapping actually involves for a spreadsheet as for an ERP system: every step between source and report figure is named, even if that step consists of a manual calculation in a cell.
Between the raw spreadsheet and the figure that ends up in the report, there are usually several operations. A raw energy invoice is converted into consumption per period. That consumption is multiplied by an emission factor. The result is added to figures from other locations. Somewhere a unit is converted, an estimate is entered for a missing month, or a correction is applied because an earlier entry turned out to be wrong. Each of these steps is an operation that changes the figure, and which operations sit between source and report is precisely what needs to be recorded before anyone can check the figure.
With a spreadsheet, the risk is that these steps are hidden in formulas that nobody reviews anymore. A cell contains a calculation that was set up three years ago by someone who has since moved to a different role. Nobody remembers anymore why the formula is built the way it is, and nobody dares to change it. That's not a lineage problem that disappears as soon as a tool is purchased. The problem lies in the absence of a recorded description of what that formula does, independent of the system it sits in.
Two operations occur almost without exception and deserve separate attention. The first is aggregation: figures from multiple locations, departments or periods are combined into a single number. How aggregation is recorded determines whether anyone can later see which sources were included and which were not. In a spreadsheet, aggregation is often done with a simple SUM formula across a series of tabs, but the question of which tabs are included and which are deliberately excluded is rarely documented anywhere.
The second is normalization: figures from different sources are made comparable, for example by converting units or by aligning different reporting periods. How normalization is recorded is just as relevant for a manual process as for an automated system. A spreadsheet with columns in different units, where the conversion is embedded somewhere halfway through a formula, is a normalization step that nobody recognizes as such until a question is asked about it.
Recording the steps between source and report has little value if nobody knows who is responsible for the accuracy of each step. Two questions belong alongside it. The first is who owns the definition of a data point: who determines exactly what is meant by a particular figure, and who is consulted when that definition changes. The second is who owns the underlying process: who is responsible for the spreadsheet itself, for maintaining it, and for flagging when the source changes or disappears.
Without those two answers, lineage remains a snapshot. Someone records today how the figure is calculated, but six months later the spreadsheet changes, the responsible employee moves on, or a tab is replaced by a new export with a different column order. If ownership hasn't been assigned, nobody notices that the lineage no longer matches reality.
A tool applied to a disorganized process records the same ambiguities, just in a tidier interface. If nobody knows which operations sit between source and report, who owns the definition and who manages the process underneath it, then automation mainly delivers faster uncertainty. The order is: first record the steps, the owners and the rules, only then look at which part of that can be automated.
Once that recording is in place, it also becomes clear which part of the manual work — retyping invoices, maintaining tabs, checking formulas — can be supported with AI. Anyone who wants to know which part of that work qualifies can use the werkscan from FTE TO AI. It calculates, per task, which part of the work can be taken over by AI, based on the tasks as they are currently performed.
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.