A large part of sustainability data does not come from a system with fixed fields and fixed units, but from a spreadsheet compiled by an employee. Energy consumption in kWh alongside liters of fuel, waste figures per site in different units, employee numbers counted on different reference dates. Before such a figure fits into a report, it has been normalized: converted to a common unit, corrected for period, aggregated to an organizational level. That normalization often happens in the same spreadsheet, with a formula that nobody outside the person who drew it up knows.
The problem is not that normalization takes place. The problem is that the step is invisible. A formula in a cell shows an outcome, not the assumption behind it. If someone else opens the file, they see a number, not a reasoning.
Between the raw spreadsheet and the published figure there are usually several steps: converting units, estimating or skipping missing values, adding up figures from multiple sites, applying a correction factor for a known deviation. Each step changes the number, and each step is a choice. Which conversion factor was used, over which period was it aggregated, why was an outlier included or not. Without documentation, those choices exist only in the head of whoever made the spreadsheet. An overview of which operations sit between source and report shows that normalization is rarely a single step, but a chain in which every link must be individually verifiable.
Recording normalization is not the same as writing an explanation after the report is finished. It is about the moment the operation takes place: which formula, with which parameters, applied to which raw value. That is the difference between an audit trail and a logbook. A logbook records that something happened; an audit trail makes clear what happened and why that operation was the right one at that moment. That distinction is worked out in why an audit trail is more than a logbook when the source is a spreadsheet. Anyone who documents normalization only afterward risks that the original choice can no longer be reconstructed, especially if the person who drew up the spreadsheet has since moved to a different role or left the organization.
A common assumption is that lineage — tracing a figure from source to report — requires a system that tracks this automatically. That is not necessary. Even with spreadsheets as the source, it is possible to record per data point which source value was used, which operation was applied to it, and who approved that operation. That requires discipline rather than software. What that looks like in practice is described in how do you create lineage without a tool when the source is a spreadsheet. The core is a fixed structure: per data point the source table, the applied formula, and a reference to who established that formula. That is more a format than a system, and it can be applied before a tool is even considered.
A normalization rule — for example the conversion factor from a fuel type to CO2 equivalent — is itself a data point that needs an owner. Not the owner of the final figure, but the owner of the rule: who decides that this factor is the right one, and who adjusts it if the standard changes. Without that assignment, responsibility shifts implicitly to whoever happened to build the spreadsheet. The question who owns the definition of a data point addresses this: a definition and a calculation rule need an owner separate from whoever enters the data. That is one of the components of source-to-report mapping, explained in what is source-to-report mapping: not just where a figure comes from, but also who is responsible for each step in between.
There are tools that automate normalization and show lineage. Those tools solve nothing if the process underneath is not set up: if nobody has recorded which rule applies to which data point, the tool merely displays a figure faster whose origin is still unclear. Process first, then the tool. Who decides on that setup is a question that goes beyond normalization alone; it is addressed in who owns the process underneath.
Once it is clear which normalization steps exist, who carries them out, and on the basis of which rule, a second question arises: which part of that manual work in the spreadsheet can be transferred to AI. FTE TO AI's work scan calculates per task which part of the work can be taken over, and is usable as soon as normalization steps are described as separate, recognizable tasks rather than hidden inside a formula.
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.