Summaries of the draft amended ESRS note a change in the number of climate datapoints — sometimes cited from roughly sixty to a higher band (order of magnitude ~80 in some analyses). That number is not an end in itself: it reflects finer-grained disclosure requirements for climate, framed by materiality.
What is a “datapoint”?
In ESRS / EFRAG vocabulary, a datapoint is a structured unit of information expected in the report (often mapped to XBRL for the European filing). It is not the same as “one row in a spreadsheet”: several fields can feed one narrative paragraph or one consolidated indicator.
Operational load: where it hurts
A higher count of items to cover can feel overwhelming. In practice, load depends on:
- Boundary (consolidation, subsidiaries, joint ventures);
- Materiality (some topics may be omitted if not material, subject to justification);
- Systems maturity: companies that already integrate energy and procurement data in ERP will onboard climate flows faster.
For emissions from cloud services and AI APIs, the bottleneck is often upstream: no systematic logging of tokens and model ID, or emission factors that are not versioned.
Structuring the response: data governance
Leading organisations treat CSRD reporting as a data product: owners per indicator, internal controls, reconciliation between carbon tools and financial statements where required. E1 datapoints then become quality requirements on governance, not just a checklist.
Message for product / engineering teams
If climate is material for your entity, engineering teams do not “fill in” ESRS by hand: they supply reliable activity files (LLM usage, travel, purchases, etc.). The earlier these flows are automated, the lower the marginal cost of each additional datapoint in the standard.
Note. The exact datapoint count and status (mandatory vs sectoral module vs guidance) must be checked on official EFRAG / ESRS tables when you prepare your reporting period.