CSRD Sustainability Reporting Software Problems: The 5 That Fail Assurance, and How to Avoid Them

Why does the datapoint register get scoped as a checklist?

Because the standard looks like a list, so somebody exports it into a spreadsheet, marks the rows in scope, and hands it to a developer as the requirement. The register becomes a static set of fields to collect, and the reason each field is there is left behind in a slide deck.

Your reporting obligation is not the full standard. It is the subset that survives your double materiality assessment, plus whatever is mandatory regardless, plus your phase in position. That subset is company specific, it is the output of a documented process, and every inclusion and exclusion has to be traceable back to the impacts, risks and opportunities that justified it. When the auditor asks why a topic was excluded, the deck and the checklist do not reconcile, because nothing ever connected them.

Hold the materiality assessment and the datapoint register as connected data instead. Each datapoint records why it is in scope, which topic and which identified impact or risk it serves, which entities must report it, at what frequency, in what unit, under what definition and with which owner. When next year's assessment changes a conclusion, the register changes with a version history and you can show the derivation.

One caveat that belongs in every scoping conversation. The scope, timing and datapoint set of European sustainability reporting have been through legislative revision, including simplification proposals, and may change again. Confirm your obligation and your reporting year with your auditor and legal advisers rather than with any software vendor. What does not change is the operational requirement underneath, which is collecting defensible data from operating entities and locking it under review.

What goes wrong when definitions drift between entities?

Everything downstream, and quietly. Headcount includes contractors in one country and not another. Energy is reported as purchased at one site and consumed at another. Water is metered here and estimated there. Waste follows local regulatory classifications that do not map to the group set. Each entity is internally consistent and the consolidation is not.

Spreadsheet packs cannot prevent this because a cell accepts anything. Packaged platforms only prevent it if someone configured definitions and validations carefully, which usually happens after the first painful year rather than before it.

Attach the definition, unit, boundary and calculation basis to the datapoint itself, and present it inline where the preparer types the number rather than in a guidance document nobody opens. Validate on entry. Add plausibility checks against prior periods and against related datapoints, for example energy against floor area or headcount, so an outlier is challenged while the only person who can still explain it is looking at the form. In our experience validation at entry does more for data quality than any amount of training.

Then plan for the correction, because there will be one. Restating a prior period is not an edit. It is a controlled event with its own approval, a reason, and a visible effect on comparatives. Systems that allow a quiet edit to a locked period will eventually produce a published figure that no longer matches the working papers, which is the version of this problem that reaches the audit committee.

Why do source system integrations break after launch?

Because they were scoped as connections and they are actually translations. Pulling energy from a building management system, safety incidents from an environment, health and safety platform or headcount from a human resources (HR) system beats manual entry, and each connection carries an assumption about what the source means that has to be checked against your definition.

The failures are specific and undramatic. A building management system reports at meter level and a site is added without anyone mapping the new meter, so consumption silently drops. A human resources system changes how it classifies a contractor category, and your headcount moves for a reason that has nothing to do with the business. A safety platform reports incidents by date reported while your disclosure needs date occurred. A site is divested and the feed keeps sending.

Three habits prevent most of this. Reconcile every automated datapoint against a manual figure for at least one period before trusting it, and keep that reconciliation as a periodic control rather than a one off test. Alert on absence, not only on error, because a feed that stops sending looks like a low number rather than a failure. And require an owner on the source side who is told when the mapping changes, because the change that breaks you will be made by someone who has never heard of your reporting obligation.

The sequencing advice is simpler. Run the first cycle with manual entry for everything, then automate the ten datapoints that hurt most. You cannot know which ones those are until you have collected them once.

What happens when sign off and audit trail are not properly covered?

Assurance takes longer, costs more, and eventually produces findings, because assurance depends on someone being accountable for each number and that accountability has to be evidenced rather than asserted.

The gap usually looks like this. The system has a submit button and a status of complete. There is no distinction between the person who prepared a figure, the person at the entity who reviewed it, and the group topic owner who is accountable for it. Comments live in email. Changes after review are invisible. Once the period closes, someone with administrative rights can still edit a number, so the lock is a convention rather than a control.

Model preparer, reviewer and approver as roles per datapoint per entity per period, with status transitions logged, rejection back down the chain, comments attached to the datapoint rather than to a thread, and a full change history recording who changed what and why. Once a period is approved it locks, and any later change is a controlled restatement carrying its own approval.

Then give the auditor a read only workspace where they can sample, follow evidence and read the change history themselves. Auditors doing their own sampling shortens your assurance timeline more than any internal efficiency, and it is a design decision rather than a feature request.

Should you build custom or configure what you already own?

If you are a single entity or a small group with a modest datapoint set and no unusual structure, configure Greenomy or Position Green and stop there. They are proportionate and fast. Novata is a reasonable answer for private markets and mid sized groups.

If your sustainability statement must sit inside the same assured document as your financial statements, with linked data and digital tagging, evaluate Workiva properly before considering anything bespoke, because that is precisely the problem it was engineered for. And if you already own one of these and the last cycle hurt, check whether the definitions and validations were ever configured, since most first year pain is unconfigured product rather than product limits.

Build when two or more of these hold. You have many reporting entities with genuinely different systems, languages and local definitions. Your reporting boundary differs materially from your financial consolidation, because operational control, equity share, leased sites and joint arrangements put sites in scope for an environmental metric that are out of scope financially. You already run a strong financial close and want sustainability data to inherit the same controls and entity master. You need source integration for high volume operational data. Or you ran a cycle in a packaged tool and your controller still rebuilt the pack in a spreadsheet to get it over the line, which is the clearest signal there is.

How do hidden costs get into the quote?

Digital tagging, if it is in scope for you. It is a detailed and unforgiving output format, and treating it as formatting work at the end of the project is how deadlines get missed. Scope it explicitly, ask what a developer has tagged before, and put it in an early phase rather than the last one.

Entities and languages, which multiply together. Each additional reporting entity brings its own systems and local practice, and each additional language touches every field label, every definition shown inline and every validation message.

Reporting hierarchy work, which sounds like configuration and is modelling. You need a hierarchy separate from the legal one, with an explicit basis of inclusion per entity per metric family, consolidation rules that can differ by metric, and documented proration for acquisitions and disposals mid year.

And parallel change, because standards, guidance and your own materiality conclusions will move during the build. If the register can only be changed by a developer, every movement becomes a change request. For calibration, in Digital Heroes delivery experience a focused first release covering the register linked to your materiality outcome, entity collection with definitions and validation at entry, tiered review and sign off and a locked audit trail runs $80,000 to $160,000 and ships in 12 to 16 weeks. Adding consolidation rules, narrative management, tagging, restatements and an assurance workspace takes it to $200,000 to $420,000 over 6 to 11 months.

What separates a build that works from one that fails here?

The ones that work treat narrative disclosures as datapoints too. Quantitative figures get attention because they are countable, but the narrative carries more risk, since it contains claims about policies, targets, actions and governance that a reader may rely on and a regulator may test. Text copied forward from two years ago quietly becomes untrue. Give each narrative disclosure an owner, a review status and required supporting evidence such as the approved policy or the board minute, and make carry forward explicit and re confirmed rather than silent.

They use language models where they genuinely help, which is drafting a first version from the structured data and flagging where a narrative claim contradicts a reported number, for example a stated target the data shows was missed. Drafting assistance with mandatory human ownership, because the person whose name is on the sign off has to have read it.

They ask a developer how a datapoint definition changes mid cycle. If the answer does not include versioning and a clear statement of which periods are affected, your comparatives will be corrupted in year two.

And they settle ownership before kickoff. You should hold the repository, the infrastructure accounts and the right to hire anyone else to continue. At Digital Heroes the client owns the code from the first commit. This system holds the evidence behind statements published in your annual report, and both the data and the logic that produced it need to stay under your control for as long as those reports can be questioned.