A logbook records who opened a file and when. That is useful, but it does not answer the question most often asked about sustainability data: how this figure came about. When the source is a spreadsheet, that difference is greater than with a system, because a spreadsheet does not enforce a fixed structure. Anyone can adjust a formula, add a row, or change a unit without leaving a trace that goes beyond a file name with a date in it.
A logbook tells you that the file "Scope1_2023_v4.xlsx" was saved on a particular day. It does not tell you which cell was changed, for what reason, and whether that change was a correction or a new assumption. For sustainability data, that distinction is relevant, because a figure often passes through several hands before it ends up in a report. Whoever can demonstrate what happened between source and report can also demonstrate why a figure is the way it is. Whoever cannot do that has only an outcome, and no path leading to it.
Between the raw data in a spreadsheet and the figure in a report, there are usually a number of operations: a unit is converted, a period is aggregated, an outlier is corrected, a result from one tab is added to a result from another tab. Each step is a moment where an assumption is made. Which operations between source and report exactly take place differs per data point and per organisation, but the steps themselves are rarely unique. They recur for practically every figure that is compiled from multiple sources.
An audit trail that only shows the end result and the last modification date misses these intermediate steps entirely. To be able to retrace a figure, it must be recorded which operation was applied at which moment, with which input, and by whom. That is a different form of recording than a logbook offers: it is source-to-report mapping, where the data point, not the file, is the starting point.
One of the operations that remains most underexposed is aggregation: adding up figures from different sources, departments, or periods into one number. Aggregation feels like a technical step, but it often contains substantive choices: which units are aligned, which periods are included, which exceptions are kept separate. How you record aggregation determines whether someone can retrace afterwards why the total is the way it is, or whether the total remains a black box that only its creator can explain, and that explanation does not hold once that person is no longer available.
An audit trail without ownership records what happened, but not who is responsible for it. With spreadsheets that is a risk, because a file can be edited by multiple people without it being clear who made the substantive choice. Recording who carried out an operation is different from recording who owns the definition of a data point: one records an action, the other records who can explain why a data point is defined the way it is. Both are needed to make an audit trail usable for someone who was not present during the process.
In addition, the distinction is relevant between who carries out an operation and who owns the underlying process. An employee may be responsible for filling in a spreadsheet, while someone else is responsible for the process in which that spreadsheet is used. An audit trail that does not make that distinction points, when a question arises, to the last person who touched something, not to who can actually explain why the process is set up the way it is.
It is possible to start this record-keeping without acquiring a system for it. That begins with naming the operations applied to a data point, recording who carries out which step, and describing the reason behind a correction at the moment it is made. How you build lineage without a tool when the source is a spreadsheet is mainly a matter of discipline in record-keeping, not of software. A tool can support that process afterwards, but a tool placed on top of a process that records nothing only produces a tidier spreadsheet with the same invisible assumptions in it.
Once the steps between source and report have been named and recorded, a second question arises: who actually carries out those steps, and which part of that is repeatable enough to hand over. Many of the operations described here, such as converting units or merging data from fixed sources, are tasks that can be broken down into steps. The [work scan from FTE TO AI](https://fte-to-ai.com) calculates per task which part of that work can be taken over by AI, based on the nature of the task rather than an assumption about what automation can do in general.
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.