A Tool on Top of a Broken Process Just Gives You Neater Reports of the Same Unreliable Numbers

Build a datapoint register first, then design a source-to-report process per datapoint with consistent definitions across units, rather than letting each unit develop its own collection approach independently. Inconsistent definitions between units are usually invisible until someone tries to add the numbers together at group level, at which point the resulting total quietly combines figures that were never actually measuring the same thing.

Fix the process, ownership, definitions, controls, before introducing any tool; a tool on a broken process just produces neater unreliable reports that look more credible than they actually are. Spreadsheets aren't really the problem; the absence of clear ownership, consistent definitions, and any control over what counts as a valid figure is the problem, and no software purchase resolves that on its own.

Design each collection process with controls, aggregation, normalisation, calculation, and standardisation, so every figure traces back to a source rather than arriving in the final report as an unexplained number nobody can defend under questioning. An auditable process looks a lot like how finance already handles financial data, the same discipline simply hasn't traditionally been applied to sustainability figures, which is exactly the gap this approach closes.

Documenting, per datapoint, where it originates, what processing it undergoes, and where it lands in the final report, so the entire journey from raw source to published figure is explicit and checkable rather than something only one person in the organisation actually understands. Without this mapping, a figure in the final report is effectively a black box that nobody can independently verify or reconstruct if questioned.

Assign a RACI per datapoint and process, definition ownership with sustainability, process and control ownership with finance, rather than leaving ownership implicit and assuming someone will naturally take responsibility. Sustainability data has a specific tendency to end up owned by nobody, since it sits between departments that each assume the other is responsible, which is precisely what an explicit RACI is designed to prevent.

Determine which datapoints are actually required by your material topics and the reporting standard, and record what already exists versus what needs to be built, rather than trying to collect every conceivable datapoint the standard theoretically allows for. A register scoped to what's genuinely required, based on your specific material topics, is a fraction of the size of one built by attempting to cover every possible disclosure regardless of relevance.

Standardise the definition at the datapoint-register stage, before any collection process is designed, since trying to reconcile inconsistent definitions after each unit has already built its own process is considerably more disruptive. Getting agreement on a shared definition early, even if it takes longer upfront, avoids the much larger cost of unwinding incompatible processes later.

Define what a valid value looks like per datapoint and what deviation triggers a flag, the same discipline financial data already has, extended to sustainability figures that have historically been collected with far less rigour. A control framework doesn't need to be elaborate to be effective; it needs to specify, for each datapoint, what a plausible range looks like and what happens when a figure falls outside it.

Ensure every figure has a traceable source and a named owner from day one, reconstructing this after the fact is far more expensive, particularly once the person who originally compiled a figure has moved roles or left the organisation entirely. Assurance providers specifically look for this kind of traceability, and its absence is one of the most common reasons a sustainability report fails to achieve a clean assurance opinion.

Fix the process first. Functional requirements for a tool should come from the designed process, not the other way around, since selecting software before the process exists means guessing at requirements rather than defining them from an actual, tested workflow. Tools chosen this way frequently turn out to be missing capabilities the process genuinely needs, or include a long list of features the process never actually uses.

Define functional requirements based on your designed collection process, then run selection, never before the process exists, because a vendor demo is far more persuasive than a clear-eyed assessment of what your specific data collection actually requires. Requirements defined from a real process tend to be more specific and more useful during vendor evaluation than a generic feature checklist copied from an industry report.

Definition ownership sits with sustainability; process and control ownership sits with finance, which already has the systems and discipline for it, since finance has spent decades building the rigour that sustainability reporting now needs to match. This split avoids the common failure mode of sustainability owning both the definitions and the process, without the systems finance already has in place to run that process reliably at scale.

Use the same datapoint register and process design as a template, adapted per unit but never redefined per unit, so the group-level aggregation stays meaningful rather than becoming a patchwork of locally reinvented approaches. Adaptation for local context is fine and often necessary; redefining the underlying datapoint or its definition at the local level is what breaks group-level comparability.

Weeks for a single topic; a full group-wide rollout with governance is measured in quarters, driven mainly by the number of units and stakeholders involved rather than by the technical complexity of the data itself. The timeline scales with organisational coordination far more than with the difficulty of the underlying measurement, which is why a single-topic pilot can move so much faster than a full rollout.

Maintain the source-to-report mapping and control framework as the documentation itself, it's built to be audit-ready by design, rather than treating documentation as a separate task to complete once the process is already running. Retrofitting documentation onto an existing process after the fact tends to be both more time-consuming and less accurate than building the documentation as a natural byproduct of designing the process properly in the first place.