ESG reporting has quietly become one of the heaviest lifts in the finance function. Between CSRD, ISSB, and a growing stack of investor questionnaires, a typical mid-market controller now spends weeks each cycle chasing emissions data from operations, reconciling Scope 1 and 2 figures against utility bills and fleet records, mapping disclosures to framework requirements, and rebuilding the same evidence pack for the third time because an auditor asked a slightly different question. The work is repetitive, detail-heavy, and unforgiving of inconsistency — exactly the profile of task that consumes senior time without using senior judgment.
The deeper problem is fragmentation. ESG data lives in spreadsheets owned by facilities, PDFs from energy suppliers, email threads with procurement, and a sustainability consultant’s slide deck. The narrative sits in a Word document that drifts out of sync with the numbers the moment anything changes. Controls documentation — the audit trail that proves a figure is reliable — is usually the first thing sacrificed when deadlines tighten, which is precisely when it matters most.
Claude Code changes the economics of this work. Because it operates directly on files in a working directory — reading spreadsheets, PDFs, markdown standards, and prior-year reports — it can act as a persistent reporting analyst rather than a one-shot chatbot. You give it your data files, your framework mapping, and your house style, and it drafts, reconciles, flags gaps, and maintains the audit trail across the whole cycle. The controller stays in control; the mechanical assembly gets automated.
Setting up the working directory
Before prompting, structure a project folder: a data subfolder for raw extracts (energy invoices, fleet logs, HR headcount files), a framework subfolder containing the relevant standard as markdown (CSRD ESRS E1, for example, or your investor questionnaire), a prior-year folder with last cycle’s published report, and a context.md file capturing materiality thresholds, organizational boundaries, reporting period, and the tone your board expects. Claude Code reads all of this before writing a single line of the report.
The first prompt below builds the data reconciliation and gap analysis — the foundation everything else depends on. It forces Claude to ask questions before executing, which surfaces boundary and unit ambiguities early rather than after the draft is written.
First, read these files completely before responding:
context.md — our reporting period, organizational boundary, materiality thresholds, and unit conventions
framework/esrs-e1.md — the climate disclosure standard we must comply with
prior-year/esg-report-2025.md — last year’s published figures and methodology notes
data/ — all raw extracts: energy invoices, fleet logs, refrigerant records, headcount
Here is a reference for what I want to achieve:
[Upload last year’s internal data reconciliation workbook exported as markdown, or describe its structure]
Here’s what makes this reference work:
Every datapoint has a source file, a calculation method, a unit, and a named owner. Gaps are listed separately with a status column, never buried in footnotes. Units are normalized to a single convention at the top of the sheet. Variance against prior year is shown with a one-line explanation for anything above [X]%.
Here’s what I need for my version / SUCCESS BRIEF:
Type of output + length: A markdown reconciliation table covering every datapoint required by the framework, plus a separate gap register
Recipient’s reaction: Our external assurance provider should be able to trace any figure to its source in under two minutes and conclude the process is controlled
Does NOT sound like: A consultant’s summary that glosses over missing data or rounds away inconvenient variances
Success means: Zero required datapoints without a status, and every gap assigned to a named owner with a remediation date
My context file contains my standards, constraints, audience. Read it fully before starting.
DO NOT start executing yet. Ask clarifying questions first.
Give me your execution plan (5 steps max) before you begin.
From reconciled data to board-ready narrative
Once the numbers are locked, the second bottleneck appears: translating them into disclosure narrative that satisfies the framework’s prescribed structure while remaining readable for the audit committee. This is where most teams either over-lawyer the language into impenetrability or drift into marketing prose that assurance providers reject. The prompt below anchors the draft to the prior-year report’s structure and your house style, with explicit instructions on what the output must not sound like.
First, read these files completely before responding:
context.md — our audience, tone standards, and approved terminology
framework/esrs-e1.md — the exact disclosure requirements and prescribed datapoints
reconciliation/reconciled-data.md — the final locked figures from our reconciliation
prior-year/esg-report-2025.md — last year’s narrative, structure, and methodology language
Here is a reference for what I want to achieve:
[Upload a section of a peer company’s ESG report you consider best-in-class, as markdown]
Here’s what makes this reference work:
Each required disclosure opens with the headline figure, then explains methodology in plain language, then states limitations honestly. Targets are separated clearly from performance. Forward-looking statements are labeled as such. No claim appears without a number or a cross-reference behind it.
Here’s what I need for my version / SUCCESS BRIEF:
Type of output + length: [X] words of disclosure narrative organized under the framework’s prescribed headings, with a compliance checklist mapping each paragraph to its requirement
Recipient’s reaction: The audit committee should trust the numbers and understand the methodology without needing a briefing call
Does NOT sound like: Marketing copy, greenwashing, or boilerplate lifted verbatim from the standard itself
Success means: Every prescriptive datapoint addressed, zero unsupported claims, and the assurance provider raises no narrative-level findings
My context file contains my standards, constraints, audience. Read it fully before starting.
DO NOT start executing yet. Ask clarifying questions first.
Give me your execution plan (5 steps max) before you begin.
A practical tip: run both prompts at the start of the cycle, not the end. The reconciliation prompt doubles as a gap register you can work against for months, and the narrative prompt reveals missing methodology documentation while there is still time to fix it. Keep your context.md updated after each board meeting — materiality thresholds and boundaries shift, and Claude will hold you to whatever the file says.
What to try next: extend the pattern to your social and governance disclosures (ESRS S1 and G1), then build a third prompt that diffs this year’s draft against last year’s published report to catch unexplained changes before the assurance provider does. The same directory structure and context file carry over unchanged.
Published on 24 October 2026 on growwithgpt.com