A log states that something happened: a file opened, a cell changed, an export made. That is useful, but it does not answer the question that matters the moment someone questions a figure in the sustainability report: how exactly did this number arise from the source, and does that path still hold.
A system log records actions. An audit trail for a data point accounts for an outcome. It is not about who pressed which button at what moment, but about which operations transformed a raw value into the number that now appears in the report. Without that accounting, every figure is a claim that no one can quickly substantiate, not even the person who supplied it.
Between the source and the report there is usually no straight line but a series of operations, and each operation is a place where something can shift without anyone noticing. Think of converting units, consolidating locations to a group level, correcting an outlier, applying an emission factor. Which operations these exactly are differs per data point and is described at which operations sit between source and report. Anyone who does not record these steps sees only the starting point and the end point, and must reconstruct the entire path again when a question arises about the figure, often based on someone's memory.
Two operations deserve attention because they most often lead to deviations. Aggregation adds up values from different sources into a total, and with every addition it must be clear which items were included and which were not. What that record looks like when the source is a spreadsheet is described at how you record aggregation when the source is a spreadsheet. Normalization rescales values to a common unit or period, and a small error in that rescaling propagates through every figure that later relies on it. The record of that process is at how you record normalization when the source is a spreadsheet. Both operations are inconspicuous in a spreadsheet and indispensable in the accounting.
Much sustainability data does not begin in a system with fixed fields and fixed rules, but in a spreadsheet that someone built according to their own judgment. A formula may have been overwritten, a column may have been moved, an intermediate step may have existed only in the mind of the person who drew it up. What source-to-report mapping means when the source is a spreadsheet is worked out at what source-to-report mapping is when the source is a spreadsheet. The core is that the mapping must not depend on the chance of a cell or tab, but must be recorded separately and repeatably, independent of the spreadsheet file itself.
Without recorded steps, the path from source to report exists only as long as the people who walked it are still there and still remember it. If something changes in the process, a new colleague arrives, or a question is asked after the reporting year has ended, the only option is to figure it out all over again. That is not an audit trail but improvisation after the fact. A tool cannot solve this problem if the underlying process has not been recorded; it then merely delivers a tidier log of a reconstruction that is just as uncertain as before.
Recording provenance and operations does not have to wait for software. How you build lineage without a tool, using the means already available, is described at how you create lineage without a tool. For spreadsheets as a source, the same principles apply as for the audit trail in general: the record concerns the same steps, applied to a source without a fixed structure, as worked out at why an audit trail is more than a log when the source is a spreadsheet. Anyone who has done this recording once for a data point can repeat it for the next one, and thereby builds a register that does not depend on a tool but on a process.
Once it is recorded which steps a figure has gone through and who carries out which operation, a different kind of question arises: which part of that work is repetitive enough to automate. Aggregating according to a fixed rule, normalizing values to a fixed unit, checking an operation against a recorded quality rule, these are tasks that can only be assessed for automatability once they exist as separate steps. FTE TO AI's work scan calculates per task which part of the work can be taken over by AI, and for that it needs precisely the kind of task-level detail that an audit trail produces.
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.