A figure in a sustainability report is almost never the same figure as the one in the source system. Between the moment an employee enters an energy invoice or a sensor registers a meter reading, and the moment that number appears in a report table, something happens. It gets converted, added up, corrected, merged with other sources. Source-to-report mapping is recording that journey: every step the data goes through between source and report, in the order in which it occurs.
The outcome of a calculation says nothing about its reliability if no one can reconstruct how that outcome came about. An emissions figure may be correct because the underlying steps were correct, or it may merely appear correct because an error in one step happened to cancel out an error in another. Without mapping, that difference cannot be seen. With mapping it can: each step stands on its own, with its own source, its own processing and its own outcome that can be checked.
That journey usually consists of more steps than people expect. Between the raw source data and the report figure there are often several processing steps in succession: units that get converted, values that get merged, exceptions that get corrected manually. Which processing steps sit between source and report differs per data point, but the structure is always the same: a series of steps that each add or change something in the data, and that each need to be recorded separately in order to follow the whole.
Two types of operations deserve separate attention, because they occur most often and most easily introduce errors unnoticed.
The first is aggregation: combining figures from multiple sources or multiple periods into a single number. Recording exactly how that addition takes place, which items are and are not included, prevents a report figure from becoming a black box. How you record aggregation determines whether anyone can afterwards still retrace how you record aggregation in a way that remains traceable back to the underlying items.
The second is normalisation: reducing diverse source data to a common unit or definition, so that figures from different systems become comparable. A litre of diesel and a kilowatt-hour of electricity only become comparable after a conversion, and that conversion contains assumptions. Recording how you record normalisation means recording what those assumptions are, so that another party can follow the same assumption or challenge it.
It is tempting to confuse mapping with an activity log: a list of who changed what and when. That is one part of it, but not the whole. An audit trail that only registers changes does not tell you why an operation was applied or what rule was behind it. Why an audit trail is more than a log has to do with the question every reviewer ultimately asks: not just what was changed, but on the basis of which logic and which source.
Source-to-report mapping is often confused with software. There are tools that display lineage automatically, but those tools only register what has already been delivered in a structured way. An organisation that still works with spreadsheets and manual handovers can record the journey just as well, only with different means: a fixed documentation format per step, a fixed place where source files are kept, a fixed way of noting changes. How you organise this without a tool is described under how you create lineage without a tool. The discipline lies not in the software, but in the repeatability of the recording.
That discipline is especially important when the source itself is already a spreadsheet. A cell in a worksheet has no built-in provenance: no one automatically sees who entered a value or on the basis of which document. What source-to-report mapping means if the source is a spreadsheet is that that provenance has to be organised manually alongside it, with the same precision as with an automated system.
In practice, mapping comes down to a question that is repeated for every data point: where does this value come from, what was done to it before it ended up in the report, and who carried out or approved that step. Asking that question for hundreds of data points is labour-intensive, and that is precisely what makes it tempting to skip. But a report built on a non-traceable basis remains vulnerable to questions that no one can answer at the moment they are asked.
Mapping out these steps, per data point and across multiple sources, is repetitive work with a fixed structure: identify the source, describe the operation, establish the owner, repeat for the next data point. Work with a fixed structure is exactly the kind of work of which part can be taken over by AI. The work scan from FTE TO AI calculates per task which part of that work lends itself to this, so that it becomes clear where people remain needed for judgement and where repetition can be automated.
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.