Somewhere in the process is a figure that no one can explain anymore. The scope 2 consumption of a site, the number of FTEs in a subsidiary, the amount of waste per production line. The figure appears in last year's report, but no one remembers which system it came from, who entered it, or whether it was aggregated or estimated. This is not an exception. It is one of the most common findings as soon as an organisation systematically reviews its sustainability data for the first time.
The question is not rhetorical. A data point without a source is not by definition wrong, but it is unproven. And unproven data that does end up in a report is a risk that only reveals itself the moment someone — an assurance provider, a regulator, a customer with their own supply chain obligations — asks further questions.
A data point register is not a reporting tool and not a dashboard. It is a list: every data point that ends up in a sustainability report, with a number of fixed fields behind it. Where does it come from. Who owns it. Which processing steps sit between the source and the report. According to which rule is its quality assessed. When was it last checked.
Without those fields, a data point is a figure that happens to appear somewhere. With those fields, it becomes a piece of data whose provenance has been recorded, and is therefore repeatably verifiable. That distinction is exactly where organisations get stuck: the report exists, the underlying structure does not.
Usually there was a source at some point. Someone once pulled a figure from an ERP system, put it in a spreadsheet, and a colleague copied it over a year later without carrying over its provenance. Or the figure is the result of a calculation — an estimate based on an average, a conversion from litres to kilograms of CO2 — whose calculation rule was never written down. That exact trajectory, which processing steps sit between source and report, is where most information gets lost. A figure that has been processed three times before reaching the report has had three chances to lose its provenance.
At organisations with multiple sites or business units, a second cause is added: the same data point exists in multiple places, in slightly different forms, and no one has ever established which version is the source data. That is a different question from the missing source, but the two intersect: if you want to know where a data point already exists across multiple business units, you often run into exactly the same blind spot.
A data point without a source is given a status in the register: unconfirmed. Not deleted, not silently assumed correct, but flagged. From that point on, there is a choice to be made, and that choice depends on what is at stake. If it is a data point assessed as minor in a materiality analysis, the source can be traced at a later point without the report waiting for it. If it is a data point that falls under assurance, the source is a requirement, not a nice-to-have.
The search itself follows a fixed route: back to the source document or source system, through every processing step, to the owner who can confirm that the figure is correct. That is exactly what source-to-report mapping entails: not checking the figure, but reconstructing the path to it. Sometimes that path turns out to be impossible to reconstruct. The conclusion then is not that the figure is wrong, but that it cannot be proven — and that is a different, and for a report equally important, outcome.
A register is not finished once every data point has a source. It is finished once every data point has an owner who can be approached, a quality rule against which it is tested, and a recorded processing history that can be walked through again without anyone having to know it by heart. What exactly that involves, and when you can stop searching for more detail, is set out at when a register is finished. For most organisations the answer is unsatisfyingly concrete: it is finished when a new colleague can reconstruct the report without help.
Tracking down and fixing a data point without a source is work that can be broken down into steps: searching source documents, tracing processing steps, approaching owners, recording answers. Part of that work — searching systems for a missing figure, consolidating submitted confirmations — is repetitive enough to have it calculated what AI can take over. The werkscan from FTE TO AI does that per task: not in general statements about automation, but in a concrete estimate of which part of this kind of search work can be left to a system and which part continues to require ownership and judgement.
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.