Skip to content
All insights AI financial modeling & automation

Pulling structured ESG metrics out of unstructured reports

ESG numbers live in PDFs written by people who disagree on definitions. Here is how we extract, normalise and validate them without inventing precision that is not there.

3 min read #modeling#esg#extraction
Financial services professionals working through an AI initiative

The raw material for ESG scoring is mostly prose. A company discloses its Scope 1 emissions in a 140-page sustainability report, buried in a paragraph next to a footnote that quietly changes the boundary of what was measured. The next issuer reports the same metric in a table, in different units, with a different base year. Multiply that across a few thousand filers and you have the actual problem ESG data extraction has to solve: the information exists, but not in any form a model can score directly.

This is where teams underestimate the work. The hard part is not reading the number off the page. It is knowing whether two numbers from two issuers mean the same thing, and being able to show your work when someone asks.

The extraction pipeline

The shape that holds up here is an LLM paired with retrieval over the source documents. Research systems like ESGReveal describe a useful split, and it maps well to production. There is a metadata module that encodes the criteria you are extracting against: what counts as Scope 2, which framework’s definition applies, what units are acceptable. There is a preprocessing module that turns the messy report corpus into a queryable database. And there is an extraction agent that retrieves the relevant passages and pulls out the structured value.

A RAG ESG setup matters for a specific reason. You do not want the model answering from its training data, because its training data does not know what a particular company disclosed last quarter. You want it answering from the actual sustainability reports, with the retrieved passage attached to every value it returns. That attachment is not a nicety. It is what makes the next two steps possible.

A workable pipeline tends to include:

  • Document preprocessing that preserves page and table structure, so a retrieved figure carries its location, not just its text
  • Criteria metadata that pins each target metric to a definition and an expected unit before extraction runs
  • Retrieval scoped to the right filing, so the value comes from the issuer and period you actually asked about
  • An extraction step that returns the value together with the passage it came from, every time

Normalising across issuers

Once values are extracted, they are not yet comparable, and pretending otherwise is how bad ESG scoring happens. Definitions drift between issuers and between reporting years. One company’s water-use figure includes recycled water; the next one’s does not. Reporting boundaries shift after an acquisition. Units arrive in tonnes, kilotonnes and short tons in the same dataset.

Normalisation is where the consultancy work lives. You build the mapping from each issuer’s local definition to a common one, you record the conversions, and you keep the lineage from the normalised value back to the raw extraction and the source passage. This is the same entity-resolution and reconciliation discipline that financial data demands, applied to disclosures instead of prices. When a scored value moves between quarters, you should be able to tell whether the company changed its behaviour or merely changed its definition. Without that, an ESG score is measuring reporting style as much as performance.

Validation, and honesty about the data

Every extracted value should be checkable against its citation. If the pipeline says a company’s emissions are X, a reviewer should be able to click through to the page and confirm it, the same way you would walk a model output back to a source record. Build the eval set from passages a human has already labelled, and treat extraction accuracy as a number you track over time rather than a thing you assume. Reports change format year to year, and a pipeline that worked on last year’s templates will drift quietly on this year’s.

The harder honesty is about the data itself. A large share of ESG disclosure is self-reported and unaudited. Some of it is estimated, some is framed generously, and some metrics simply are not disclosed, leaving gaps you can impute but should not disguise. Good extraction makes this visible instead of smoothing it over. We would rather hand back a value with a flag that says “self-reported, boundary unclear, low confidence” than a clean number that implies a precision the source never had.

That posture is the whole point. The pipeline’s job is not to make ESG data look solid. It is to make it usable while being clear about exactly how solid each value is, so the scoring on top of it is defensible to the person who has to act on it.

Working on something similar?

Tell us about your data and the workflow around it, and we will give you a straight read.

Book a 30-min intro call