ESG and Sustainability Reporting Software Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does collection keep getting scoped as a survey module?

Because it demos beautifully and because the vendor market normalised it. You define a questionnaire, you send it to forty two sites, you chase the eleven that did not respond. Surveys work when the question is simple and the respondent is motivated, and they fail precisely where your data is hardest: the site with three electricity accounts, one closed mid year, and a landlord invoice that bundles water into a service charge.

The people answering are not sustainability staff. They are a facilities manager finding a waste transfer note, a fleet supervisor exporting fuel card data, a human resources (HR) partner pulling headcount by contract type. None of them report to you, none are measured on this, and all are being asked in the same fortnight as the financial close.

Treat collection as a workflow rather than a form. Named owners rather than a shared mailbox, due dates, escalation to the site's manager, and guidance written for your actual estate rather than for a generic one. Then remove the human wherever possible: utility data from supplier portals or invoice feeds, fuel from the card provider, travel from the corporate booking tool, fleet mileage from telematics. Where a document is unavoidable, extraction reads the consumption quantity, unit, period and account number and flags a period that does not join to the previous one, which is how you catch an eleven month year before your auditor does. The success measure is boring and honest: the share of data that arrives without anyone typing it.

What goes wrong when you migrate prior year figures and restate a base year?

The figures migrate. The reasoning does not. A workbook holds the number and not the estimation method, so the Spanish site whose landlord would not break out electricity comes across as a value with no record that it was derived from floor area, and the cell comment explaining it was deleted two reorganisations ago. Load prior periods as figures with an explicit method and evidence status rather than as clean data, and mark what you cannot substantiate. It is uncomfortable and it is far better than discovering it during an engagement.

Base year recalculation is the harder half. You publish a baseline and a target against it, then acquire a business with eleven sites, divest a division and change the consolidation approach for a joint venture. Every published figure now sits on a different perimeter, and restating requires knowing exactly which entities were in scope in which period, at what ownership percentage, under which consolidation approach.

The design that solves it is an effective dated entity and site register carrying ownership, consolidation approach and operational control over time, so any period can be reported as published or restated on the current perimeter. Controllers already run this discipline for financial consolidation. Sustainability numbers lack it because a workbook has no concept of time varying structure. Build that register first, and expect assembling it to be a genuine workstream with finance rather than a data entry task.

Why do utility, fuel card, travel and telematics feeds break after launch?

Utility feeds break on account lifecycle rather than on technology. A meter is replaced and the new account starts a different billing period. A site changes supplier and the old account goes quiet without erroring. A landlord takes over a supply. In each case the feed keeps working and simply stops covering part of your estate, which produces a total that looks plausible and is short.

Guard it on continuity rather than on errors. For every account you expect data from, check that consecutive periods join with no gap and no overlap, and raise the exception when they do not. A site that reported eleven months should be an alert in month twelve, not a finding in the following autumn. Do the same for absence: an account that has sent nothing for two billing cycles deserves a message.

Fuel card, travel and telematics feeds break on classification. A new vehicle class appears, a booking tool adds a rail product, a card is issued to a subcontractor. The volume arrives but lands in an unmapped bucket, and unmapped usually means excluded. Report the unmapped remainder on every run rather than dropping it. Each of these is a small project in its own right, so name them individually in scope rather than accepting one line reading system integrations.

What happens when the evidence chain from invoice to disclosure is not covered?

Assurance is a traceability exercise. Somebody selects a disclosed number and asks which sites contributed, which readings, which document, who approved it and what changed since the last version. In most organisations that walk stops at a workbook with no version history and an email thread, and once it stops the sample size grows.

What you need is unremarkable and specific. The uploaded source document stored, hashed and linked to the data point it supports. An append only edit record where every change carries an author and a reason. Approvals captured as sign offs at site, function and group level, so the chain of responsibility is visible rather than remembered. The disclosure references the aggregation, so opening a figure in the draft statement shows the contributing records and their evidence.

The other half of the same problem is factors. Emission factors are versioned data, not constants: they change annually by publisher and country, grid intensities get restated, and market based and location based treatments need different inputs. Store the factor identity, version, publisher, conversion path and code version alongside every result, and make recalculation an explicit logged operation producing a comparison rather than an overwrite. Then when a figure moves you can separate better activity data from a factor revision, which mean entirely different things to a reader.

Should you build custom or configure what you already own?

If you are a single entity in one country with a handful of utility accounts, do not build. A competent adviser and a well built workbook will get you through, and software would be theatre. If your primary need is the disclosure document itself with strong drafting and sign off controls, Workiva does that job well and rebuilding it is a poor use of money. If carbon accounting methodology is your gap and your estate is simple, Persefoni or Watershed will get you further faster than a bespoke engine, and Sphera is the stronger fit where operational health, safety and environment depth is the requirement.

Before commissioning anything, look honestly at the platform you already licence. A large share of what gets reported as a limitation is unconfigured: site hierarchies never set up properly, workflow and reminders switched off, integrations bought and never connected. If your team runs the real process in a spreadsheet and uses the platform as a place to put the answer, find out which of those two things is true before you spend.

Build when two or more hold. You collect from more than roughly twenty five sites or entities and response rate is the bottleneck. Your group structure changes often enough that restatement is recurring. You report under several frameworks and collect the same data more than once. Or your assurance provider has already raised traceability as a finding. Our position is that the calculation engine is the commodity and the collection layer is the differentiator, because anyone can multiply an activity figure by a factor.

How do hidden costs get into the quote?

Country count is the first, and it moves the number more than site count does. Units, invoice formats, local reporting obligations and language all vary, and a quote priced against three countries and delivered against nine is not a small overrun.

Framework count is the second. A group filing in Europe, answering a state level regime and responding to investor questionnaires needs one data model mapped several ways, and that mapping work is usually presented as configuration. Requirements in this area continue to change, so have your advisers confirm which standards and timing apply to you rather than relying on any vendor matrix.

The entity register is the third and it is where the hidden effort actually lives. Assembling the complete list of legal entities, sites, meters and leases with their effective dates is your work, it involves finance and legal, and it is the most common reason these projects run long. Fourth is integrations, each of which is a small project. Fifth is document extraction review, because somebody has to check flagged exceptions and a build without a reviewer has no control. Sixth is the parallel run: you should collect one full cycle in both the old and new way, and that duplicated effort belongs in your business case even though nobody quotes it.

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

The ones that work start with scope 1 and 2 across the largest twenty sites, which is usually most of the operational footprint, and ship a system those sites actually use in the next cycle. Value chain categories follow once the collection habit exists. The ones that fail try to cover every category and every framework at once, and deliver a platform that the team uses as a place to store answers they still assembled in a spreadsheet.

Start at least one full cycle before the period you intend to report on, so a parallel run is possible. Sustainability reporting has one date a year that matters and no capacity to absorb a rough first attempt in the wrong month.

Ask a developer how they store a calculation. If the answer does not include the factor version, the publisher, the conversion path and the code version alongside the result, they will build something that cannot survive a restatement, and restatement is certain. Ask them to model a joint venture consolidated financially but not under operational control across a year in which your ownership percentage changed. If they shrug at effective dating, walk.

Weight financial systems experience above sustainability marketing experience. The requirement here is an evidence chain and segregation of approval, which is familiar territory to anyone who has built for a controller.

Settle ownership before kickoff: the repository, the cloud accounts and the full document archive. At Digital Heroes the client owns everything from the first commit. The evidence behind a figure you publish this year may be requested several years from now, so the archive has to outlive your vendor and probably your current framework. Test a complete export during the build rather than when you need it.