There is no shortage of software for sustainability reporting. There is, however, a shortage of organizations that know in advance what to ask of a tool. That latter point is the real problem, and it explains why so many implementations are rolled back after a year or quietly left dormant.
A tool is an instrument that carries out what you put in front of it. It asks for data points, links sources, calculates and reports. What it does not do is figure out which data points your organization actually needs, who is responsible for them, and where the figures currently come from. That work sits before the tool, not inside it.
The order is therefore not arbitrary: first know what you have and where it sits, only then choose what fits. The reverse does not work, because a tool does not impose structure on something that has no structure yet. At most, it lays an interface over the chaos. This page and the corresponding page for the installation sector explain why that chaos is in practice so scattered: across ERP, invoices, spreadsheets from the facility manager, and email exchanges with suppliers.
Anyone who first selects a tool and only then discovers what data exists internally runs into a fixed pattern. The implementation takes longer than planned, because it turns out that halfway through it is still necessary to work out who supplies which figure. The tool gets filled with whatever happens to be available, not with what is complete or verifiable. And as soon as the accountant or an auditor asks where a figure comes from, there is no answer beyond "it was in the system".
The costs of this cannot be captured in a percentage — that depends on the organization, the number of departments involved and how many data points were even in scope. What is recognizable, though, is the pattern: a second project to map out sources and ownership after all, while the tool is already running. That second project would have been necessary even without a tool, and could have happened earlier. A more detailed breakdown of this cost item is on the page about what a tool actually costs on top of an unorganized process.
The reversal is not complicated, only unusual. First you map out which data points your reporting requires, where they currently come from, who is responsible for them and which quality rules do or do not apply. That overview — a data point register with lineage from source to report — is independent of whichever tool you ultimately choose. In fact, that overview is what properly determines which requirements you can set for a tool. Without that overview, you buy a system based on a demo and a sales conversation; with that overview, you buy a system based on what your organization actually needs. How those requirements emerge from your own process is worked out on the page about functional requirements that follow from your own process.
This reasoning is not new to anyone who has already looked into the subject — the core question is addressed more broadly on the overview page about choosing a tool without regret, and the trade-off between buying first and organizing first is worked out separately on the page that sets the two orders side by side.
The Data Readiness Scan from csrdready.net is built to do precisely that first part: compiling the data point register, documenting the lineage from source to report per data point, assigning ownership and naming quality rules. Not a report, not a filled-in questionnaire — the data underneath it, in order, before any tool gets involved.
The tool is under construction. Anyone interested can sign up for the waiting list; nothing is being offered that does not yet exist, and nothing is being promised about what it delivers before it exists.
Once the data point register is in place and it is clear which steps between source and report are repeated — fetching the same figure from the same supplier, performing the same check on the same spreadsheet, sending the same email to the same department — a second question arises: which part of that work still requires a human, and which part can be automated. That question lies outside what csrdready.net does, but logically follows as the next step. FTE TO AI calculates per task which part of the work can be taken over by AI, based on the tasks as they are actually carried out — not based on an estimate made in advance.
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.