Kennisbank

What is a valid value — and who notices when it goes wrong?

A figure in a sustainability report comes from somewhere: a meter, an invoice, an estimate, an export from a system. At the moment that figure is entered, copied, or taken over, there is usually no one who checks whether it is correct. Not because no one wants to, but because no rule has been established that states what a valid value actually is for that specific data point.

A valid value is not an opinion

"Is this number correct" is not a question that anyone can answer by feel, certainly not with hundreds of data points spread across spreadsheets and systems. A valid value is something defined in advance: a range, a unit, a ratio to another data point, an expected direction relative to last year. Without that definition, every value is in principle valid, and that is precisely the problem. A consumption figure that is ten times too high because the unit was copied incorrectly then goes unnoticed — it simply sits there, like all the other numbers.

Establishing what is valid is one of the building blocks alongside the data point register and the source data: which controls belong to a data point and who has oversight of them. This is not a matter of stricter Excel formulas, but of establishing per data point what is and is not acceptable, and why.

A signal is not the same as an error

Not every deviation is an error, and not every error triggers a signal. A value can fall outside the expected range without being incorrect — a factory that is temporarily shut down, a merger that disrupts the figures. Conversely, a value can look perfectly normal and still be wrong, for example because two parts of the organization apply a different starting point for what they measure. A signal, then, is not a judgment; it is an indication that someone needs to look at it.

The question then is: under what condition does such a signal trigger, and how sensitively is it set. Set too loosely, and deviations slip through. Set too tightly, and everyone ignores the alert because there are too many. How that threshold is determined per data point depends on the data point itself and on what can plausibly fluctuate. That subject is covered separately in how you set a signal deviation and who then looks at it.

Who notices — and is that a matter of chance

The core question of this page is not only what a valid value is, but who notices when a value is not. In many organizations, the answer is: no one, until an external party raises a question during the assurance of the report. By that point it is already late, and the preparer has to go back to the source to reconstruct what happened.

A quality rule without an owner is not a rule, it is an observation. Each data point therefore needs not only a threshold, but also a name: who receives the alert, who assesses whether it is an error or an explainable exception, and who records that explanation so that the next person using the data point does not have to figure it out again. Without that assignment, it is down to chance whether anyone sees the signal before the figure moves further down the chain.

This assignment is directly connected to another problem that often appears alongside quality rules: teams that interpret the same concept differently. What is a valid value for one part of the organization may trigger a signal for another, simply because the definition differs. That relates to the question of what you do with definitions that differ per part of the organization. Without a unambiguous definition, a quality rule is at best a guess.

Why this does not start with a tool

It is tempting to solve this question by purchasing a tool that flags automatically. But a tool can only flag based on rules that have been entered, and those rules represent knowledge that currently often exists only in someone's head — the colleague who knows that this figure usually lies between two limits, or that that other value is always checked by a specific person. Recording that knowledge first, per data point, is different work from selecting a system. The order in which that is best done is described in buying a tool first or setting up the process first.

From quality rules to workload

Once it has been established per data point what a valid value is, who assesses a signal, and who explains a deviation, a picture emerges of the work that actually takes place around the data — checking, comparing, following up, recording. That picture is useful for another question: which part of those tasks repeats in a way that lends itself to automation, and which part requires judgment that belongs with a human. The work scan from FTE TO AI calculates, per task, what portion of the work can be taken over by AI, based on how that work is currently organized — not based on an upfront estimate.