Key takeaways
• Multi-level approval is usually a symptom of unclear data ownership, not a control for it.
• Give final approval authority to the person closest to the data point, and let automated validation catch unit errors, outliers and typos.
• Trace every metric to its origin before designing collection. Energy data is often already held centrally in an ERP or utility invoicing system.
• Collect each data point once into a central repository, then generate every questionnaire, disclosure and audit response from it.
• Map every data point, collector, owner and supporting document before migrating off spreadsheets.
The Best Sustainability Data Practices
Aren't in the Software.
They're in the Questions It Forces You to Ask
Ask any sustainability team lead what their biggest headache is, and you'll rarely hear
"we need a fancier dashboard." You'll hear about the spreadsheet that only one person understands. The approval chain that takes six weeks. The site manager who submitted electricity data in kWh when the template asked for MWh, and nobody caught it until the auditor did.
Why software implementation surfaces problems software can't fix
Here's what we've noticed after helping dozens of companies move from Excel-based reporting to structured data management software: the software itself is rarely the interesting part of the story. What's interesting — and what actually changes how a company reports — is what happens during the move.
The moment a company has to decide how many user seats to buy, how to structure its entities and sites in a system, and who gets to approve what, it's forced to answer questions it's spent years avoiding. Where does this data point actually come from? Who really owns it? Do we even need to be collecting it this way?
That process of forced clarity — call it a cleansing process — is often worth more than any feature in the tool. Here are three real (anonymized) examples of what that looked like in practice, and the best practices that came out of them.
Story 1: When Nobody Trusts the Data, Everybody Approves Everything
The practice: Multi-level approval is often a symptom of unclear ownership, not a solution to it. Before adding another layer of sign-off, map who is actually closest to each data point and best equipped to verify it — then give that person real authority, and let automated validation catch the mechanical errors so human reviewers can focus on judgment calls instead of typos.
Why multi-level approval usually signals unclear ownership
A large, international industrial manufacturing group came to us with a reporting process that looked robust on paper: multi-level approval, sign-off at the site level, sign-off at the team level, and then a final review before anything went into the report. In reality,
it was a bottleneck. Data lived in hundreds of separate Excel files scattered across sites and business units, and the central sustainability team had learned — the hard way — not to trust any of it. So they checked everything. Every single data point got personally reviewed by the reporting team before it was accepted, regardless of who had already signed off on it upstream.
This wasn't a software problem. It was a trust problem wearing a process costume.
As part of implementation, we ran a series of workshops with the company to map out exactly who collected each type of data, who was best positioned to own and verify it,
and where the supporting documentation actually lived. That mapping exercise surfaced something the team already half-knew but had never addressed directly:
the micromanagement wasn't protecting data quality, it was compensating for the absence of a real ownership model.
The company used the implementation as a forcing function for a harder, more human conversation — including internal debate and training — about empowering specific people at the team and site level to be genuine data owners with final approval authority, rather than routing everything up to one overworked, overly cautious central team. That handoff was only possible because the new system could catch the kind of error that used to require
a human triple-check: wrong unit of measurement, a stray extra zero, an implausible
year-over-year jump. Automatic validation didn't replace human judgment — it replaced the need for redundant human judgment, which is what let the company finally decentralize approval without losing confidence in the numbers.
Story 2: The Data You Assume You Need to Collect Locally
The practice: Before setting up a data collection structure, trace each metric back to its origin. Don't assume you need site-level collection just because that's the traditional model — check whether the information already exists centrally (in an ERP, a utility platform, a shared invoicing system) and can be pulled in rather than re-keyed dozens of times over.
Should ESG data be collected site by site or centrally?
A large public-sector organization came to us starting its CSRD reporting essentially from zero. They'd taken some introductory courses to get their bearings, and once they brought in the software, we moved into implementation workshops together. Like a lot of organizations at the start of this journey, their working assumption was that granular environmental data
— energy consumption, in this case — had to be collected site by site, because that's simply how it had always been described to them: one site, one data collector, one number.
It was only during the implementation workshops, when the team was asked to actually trace where each data point originated and what documentation backed it up, that a much simpler answer emerged. The organization's energy consumption was already tracked centrally through their ERP system, sourced from utility invoices that covered multiple sites at once. There was no operational reason to ask dozens of site coordinators to re-enter numbers that already existed, cleanly and centrally, one layer up. The flexible data input options and API connections in the new system meant this centralized data could simply be pulled in directly, cutting out an entire layer of manual collection, chasing, and reconciliation.
This is the pattern we see constantly: organizations default to collecting data at the most granular level possible, not because it's necessary, but because nobody had previously stopped to ask "where does this number actually come from, and is there already a single source of truth for it further upstream?"
Story 3: Collect It Once, Use It Everywhere
The practice: If you're facing multiple, overlapping external data requests, separate the collection of underlying data from the packaging of it for each recipient. Build one clean, well-documented source of truth once, and reuse it across every questionnaire, disclosure, or audit that draws on it.
How to handle overlapping supplier sustainability questionnaires
A mid-sized manufacturer in the industrial components sector isn't currently subject to CSRD, but that didn't mean their reporting burden was light. Their real pain point was the flood of individual sustainability questionnaires arriving from different business partners
— each one with its own format, its own questions, and its own deadline, often asking for largely overlapping information.
Rather than answering each questionnaire from scratch, the company used the software to build what we'd call a "data universe": a structured, central repository of the underlying data and supporting documents, organized so that it could be sliced into different "projects" corresponding to each partner's specific questionnaire. Data providers at each site only had to submit their numbers once. From there, the sustainability team could generate the tailored outputs each partner needed and manage all the underlying evidence centrally, instead of hunting down the same invoice or certificate five separate times for five separate requests.
The Common Thread
None of these breakthroughs came from a product feature in the traditional sense.
They came from being forced to answer basic structural questions — who owns this data, where does it come from, do we already have it somewhere else, do we need to collect it at all — that most organizations simply never get around to asking when everything lives in a folder of Excel files.
Sustainability data management checklist
A few practices worth carrying into your own process, regardless of what tools you use:
- Map before you migrate. Identify every data point, its collector, its owner, and its supporting documentation before you decide how to structure approvals or system access.
- Match authority to proximity. The person closest to a data point is usually best placed to verify it — don't default to central micromanagement as a substitute for a real ownership model.
- Automate the mechanical, not the judgment. Let validation rules catch unit errors, outliers, and typos, so human reviewers can spend their attention on the things that actually require expertise.
- Trace before you collect. Don't assume granular collection is necessary just because it's traditional. Check whether a centralized source already exists.
- Collect once, reuse often. If the same underlying data feeds multiple disclosures or questionnaires, build one central, well-documented source rather than answering each request from scratch.
The best sustainability data management processes aren't the ones with the most approval steps or the most detailed spreadsheets — they're the ones built on a genuine understanding of where the data comes from and who's accountable for it.
Software can't do that thinking for you. But going through the process of choosing and implementing the right system is often exactly the occasion that finally makes a team sit down and do it.
.png)