CSRD Sustainability Reporting Software: How Do You Close a Non Financial Statement Like a Financial One?

Why a sustainability statement is a close process, not a report

A group controller in January is chasing eighteen subsidiaries for a workbook. Version control is by filename. One country returned energy consumption in a different unit and nobody noticed until consolidation. Another used a headcount definition that includes contractors, while the rest did not, which makes the group figure meaningless. A third sent numbers signed off by nobody. The narrative sections were drafted by the sustainability team from a previous year's text, and half the claims in them are no longer supported by anything current. In March the auditor asks who approved the water figure for the Spanish entity and on what basis, and the honest answer is that it came in an email from a plant manager.

Financial reporting solved this decades ago with a close calendar, defined owners, review controls, sign offs, consolidation rules and an audit trail. Sustainability reporting is being asked to meet a similar standard, in a much shorter time, with data that lives in operations rather than in a ledger and with a datapoint count that dwarfs a financial statement.

The market has responded and some of it is genuinely good. Workiva is the strongest option when the sustainability statement has to live inside the same controlled document as the financial statements, and its linked data and tagging model is mature. Novata and Position Green serve private markets and mid sized groups well. Greenomy is built specifically around the European taxonomy and reporting requirements. If your structure is simple and your data lands cleanly, buying is the sensible route and we will tell you so.

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

Problem one: the datapoint register is your scope, and it is not generic

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 it needs to be traceable back to the impacts, risks and opportunities that justified including or excluding each topic.

Most groups treat this as a one off exercise producing a slide deck, then start collecting data from an unconnected checklist. When the auditor asks why a topic was excluded, the deck and the register do not reconcile.

What a custom build does: hold the materiality assessment and the datapoint register as connected data. 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, with what definition and with which owner. When next year's materiality assessment changes a conclusion, the register changes with a version history, and you can show the auditor the derivation. That register is the backbone of the whole system, and every other feature hangs off it.

Problem two: definitions drift between entities and nobody notices

This is the single most common data failure in group sustainability reporting. Headcount includes contractors in one country and not another. Energy is reported as purchased rather than consumed at one site. Water is metered at one plant and estimated at another. Waste categories follow local regulatory classifications that do not map to the group set. The consolidated figure is arithmetically correct and conceptually meaningless.

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

What a custom build does: attach the definition, unit, boundary and calculation basis to the datapoint itself, present it inline where the preparer enters the number, and 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 questioned at the point of entry rather than at consolidation in week nine. In our experience validation at entry does more for data quality than any amount of training, because the person entering the number is the only person who can still explain it.

Problem three: sign off has to be real, and it has to be tiered

Assurance depends on someone being accountable for each number. In practice that means a preparer, a reviewer at entity level, and an owner at group level for each topic, with the ability to reject back down the chain and to see exactly what changed after a review.

What a custom build does: model preparer, reviewer and approver as roles per datapoint per entity per period, with status transitions logged and a full change history including who changed what and why. Comments attach to the datapoint, not to an email thread. Once a period is approved it locks, and any subsequent change is a controlled restatement with its own approval. This is unglamorous workflow engineering and it is the reason the system exists. Everything else is convenience.

Problem four: the narrative is where the real risk sits

Quantitative datapoints get attention because they are countable. The narrative disclosures carry more risk, because they contain claims about policies, targets, actions and governance that a reader may rely on and a regulator may test. Text that was true two years ago and was copied forward is a real exposure.

What a custom build does: treat each narrative disclosure as a datapoint too, with an owner, a review status and required supporting evidence, for example the approved policy document, the board minute, the target approval. Carry forward is allowed but it is explicit and must be re confirmed, never silent. A language model can genuinely help here by drafting a first version from the structured data and last year's text, and by 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 must have read it.

Problem five: consolidation scope is not your financial consolidation

Sustainability reporting boundaries do not always match the financial consolidation. Operational control, equity share, leased sites, joint arrangements and value chain estimates all create cases where a site that is out of scope financially is in scope for an environmental metric, or the reverse. If you cannot express that, you will either double count or omit.

What a custom build does: model the reporting hierarchy separately from the legal hierarchy, with an explicit basis of inclusion per entity per metric family, and consolidation rules that can differ by metric. Acquisitions and disposals mid year need proration rules that are documented once and applied consistently rather than being decided in a call each January.

What this costs and how long it takes

Across the regulated reporting work Digital Heroes has delivered, this is the honest shape. A focused first release, meaning the datapoint 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. That is enough to run a real reporting cycle.

A full platform adding consolidation rules with a separate reporting hierarchy, narrative management with evidence links, digital tagging output for the required format, restatement handling, target and action tracking, and an assurance workspace where the auditor can pull samples themselves runs $200,000 to $420,000 phased over 6 to 11 months.

What pushes cost up here specifically: the number of reporting entities and the number of languages your preparers need. Integration with source systems, since pulling energy from a building management system or safety incidents from an EHS platform beats manual entry but each connection is its own project. Digital tagging, which is fiddly and unforgiving and should be scoped explicitly rather than assumed. Value chain data, if a material share of your disclosures depends on suppliers. And parallel change, because the standards and your own materiality conclusions will move during the build, so the register must be editable without an engineer.

What keeps cost down: run the first cycle with manual entry for everything and automate the top ten highest volume datapoints in year two, once you know which ones actually hurt.

Build versus buy, and when buying is the right call

Buy, and do not call us, if you are a single entity or a small group with a modest datapoint set and no unusual structure. Greenomy and Position Green are proportionate and fast. If your sustainability statement must sit inside the same assured document as your financial statements and you want one controlled document with linked data and tagging, look hard at Workiva before considering a build, because that is precisely the problem it was engineered for.

Build when two or more of these are true. You have a large number of reporting entities with genuinely different systems, languages and local definitions. Your reporting boundary differs materially from your financial consolidation. You already run a strong financial close in a system you trust and want sustainability data to inherit the same controls and entity master rather than living in a parallel universe. You need source system integration for high volume operational data. Or you ran a cycle in a packaged tool and your controller still rebuilt the pack in Excel to get it over the line, which is the clearest signal there is.

How to choose a developer for sustainability reporting systems

Ask them how a datapoint definition changes mid cycle. If the answer does not include versioning and a clear statement of which periods are affected, they will corrupt your comparatives in year two.

Ask how the auditor will use the system. The right answer includes a read only workspace with sampling, evidence access and the full change history, not a set of exports. Auditors doing their own sampling shortens your assurance timeline more than any internal efficiency.

Ask specifically about digital tagging if it is in scope for you, and ask what they have tagged before. It is a detailed, unforgiving output format and treating it as a formatting task at the end of the project is how deadlines get missed.

Ask who owns the code and get it in writing before kickoff. You should own the repository, the infrastructure accounts and the right to hire anyone else to continue the work. At Digital Heroes the client owns the code from the first commit. This system will hold the evidence behind statements in your annual report, and both the data and the logic that produced it need to remain under your control for as long as those reports can be questioned.