Buy the ESG Platform. Build the Data Layer Underneath.

Most ESG platforms will tell you they handle everything. They do not. They handle reporting. The data collection, normalisation, lineage tracking, and auditability that sit underneath good reporting — that is your problem to solve, and no SaaS vendor is going to solve it for you.

This post is about that gap. Specifically, how to think about what to buy versus what to build, and what the data layer you build needs to actually do.

What Does an ESG Platform Actually Give You?

The major platforms — Workiva, Watershed, Persefoni, Sweep — are genuinely good at a narrow set of things. They offer pre-built reporting templates for GRI, TCFD, CSRD, and SEC climate disclosure. They have workflow tools for gathering inputs from business units. They have dashboards that translate numbers into narrative text. Some have calculation engines for Scope 1, 2, and 3 emissions.

What they assume is that clean, structured, reliable data will arrive at their API or import boundary. That assumption breaks almost immediately in a real enterprise.

Your energy consumption data lives in a SCADA system or a BMS that outputs CSV over FTP. Your fleet telemetry is in a third-party telematics platform with its own schema. Your supply chain emissions factors need to be matched to spend data from an ERP that was last meaningfully updated in 2019. None of this arrives clean.

The platform cannot fix this. You have to fix this before the platform ever sees it.

Why the Data Layer Is the Hard Part

The GHG Protocol defines Scope 3 across 15 categories. Getting even Category 1 (purchased goods and services) right requires matching your procurement spend to an emissions factor database like Ecoinvent or the EPA's EEIO factors, at the right granularity, in the right geography, for the right year. That matching logic is bespoke to your data model. No off-the-shelf tool handles it without significant configuration, and "significant configuration" usually means custom code.

Beyond emissions, CSRD's double materiality assessment requires you to track both financial impact on the company and impact on society and environment. The data for those two views comes from completely different sources and needs to be reconciled in a structure your ESG platform almost certainly did not design for.

A few specific problems you will hit:

• Unit normalisation. Energy data arrives in kWh, MWh, GJ, MMBtu, therms, and occasionally in currency spend that needs to be converted using grid intensity and commodity price data. Building a unit conversion and validation layer is not glamorous, but getting this wrong invalidates every downstream calculation.
• Temporal alignment. Your fiscal year, your reporting year, and your grid emissions factor vintage rarely align. The IEA's emission factors are released annually with roughly a 12-month lag. Automating the right vintage selection matters for accuracy and for audit defence.
• Chain of custody. When a regulator or auditor asks why your Scope 2 figure changed between Q2 and Q3, you need to trace that to a specific data source change, a methodology update, or a corrected input file. That requires immutable lineage, not a figure in a dashboard.

What Should You Actually Build?

The short answer: build the ingestion, transformation, lineage, and validation layers. Buy the reporting and workflow layers.

Here is a comparison that reflects the decision most engineering teams face:

Layer	Build	Buy
Raw data ingestion (APIs, FTP, SFTP, ERP connectors)	Yes	Only if vendor connectors match your exact sources
Unit normalisation and conversion	Yes	Rarely handled well off-the-shelf
Emissions factor management and versioning	Yes	Some platforms support custom factor libraries
Data lineage and audit trail	Yes	Most platforms offer limited lineage depth
Double materiality data reconciliation	Yes	Not a standard platform feature
GRI / CSRD / TCFD report generation	No	This is what you're paying for
Workflow for collecting business-unit inputs	No	Mature in most enterprise platforms
Scenario modelling and target tracking	Depends	Worth evaluating per platform

The engineering work for the build column is substantial but well-understood. You are building a data pipeline with stricter-than-average lineage requirements. The technology choices are not exotic: Apache Airflow or Prefect for orchestration, dbt for transformation and documentation, a lakehouse architecture on Delta Lake or Apache Iceberg for the immutable storage layer, and a PostgreSQL or BigQuery warehouse as the reporting surface your ESG platform reads from.

On Lineage Specifically

OpenLineage is the standard to adopt here. It is vendor-neutral, integrates with Airflow, Spark, and dbt, and produces lineage graphs that can be exported for auditor review. If you are building in 2024 and not using OpenLineage, you are creating a future problem for yourself.

The lineage requirement for ESG is stricter than for most internal analytics. CSRD Article 8 requires companies to disclose how data was collected and validated. That is an audit target. Your lineage system needs to record source file, ingestion timestamp, transformation logic version, emissions factor version, and the identity of any manual overrides. All of it.

On Emissions Factor Management

Ecoinvent 3.10 (the current release as of late 2023) has over 20,000 unit processes. The EPA's USEEIO v2.0 covers 411 industry sectors. You will not use all of these, but you need a managed, versioned library that pins each calculation to a specific factor version and flags when a newer version changes a material number. This is a data management problem, not a software procurement problem.

Should You Use a Middleware Tool Instead?

There is a class of middleware that sits between raw enterprise data and ESG platforms. Salesforce Net Zero Cloud, for example, tries to absorb some of this complexity. IBM Envizi has a strong data integration layer. Both add cost and another vendor relationship, and both still require you to do the ERP and operational data integration work.

If your existing data infrastructure is mature (you already have a lakehouse, you already have dbt models for your operational data, you already have an OpenLineage-compatible orchestrator), adding a middleware layer is probably not worth it. If your data infrastructure is genuinely immature, a middleware tool buys you time but does not solve the underlying problem.

The honest trade-off: middleware reduces time-to-first-report, increases vendor lock-in, and does not reduce the eventual engineering debt. If you are reporting under CSRD from fiscal year 2025, you may not have time to do this cleanly. In that case, middleware is a reasonable pragmatic call, not a long-term architecture decision.

Conclusion

Buy the ESG platform for what it is good at: generating compliant reports, managing disclosure workflows, and keeping up with regulatory template changes as CSRD, SEC, and ISSB standards evolve. Build the data layer because no vendor will build it correctly for your specific data sources, unit systems, and audit requirements.

The first concrete step is a data inventory. Before you evaluate platforms or write a line of pipeline code, map every operational data source that contributes to your material ESG metrics, document its format, frequency, and owner, and identify where unit conversion, temporal alignment, or factor matching will be required. That inventory drives every subsequent architecture decision.

If you want a second opinion on that architecture before you commit to it, Sodio's engineering team has done this work. Get in touch.

FAQ

Do ESG platforms handle Scope 3 calculations automatically? Most platforms provide a framework for Scope 3 but rely on you to supply spend data, supplier-specific emissions factors, or activity data. Category 1 (purchased goods) and Category 11 (use of sold products) typically require custom data pipeline work before the platform can calculate anything meaningful.

Is CSRD's data lineage requirement actually enforceable in the first year? CSRD is being phased in, with large public-interest entities reporting from fiscal year 2024. The lineage and assurance requirements become stricter over time, moving from limited to reasonable assurance. Starting with weak lineage creates rework risk, but a pragmatic first-year approach that documents methodology clearly is defensible while you build the full audit trail.

Can we use our existing data warehouse as the ESG data layer? Yes, with caveats. Your existing warehouse probably lacks immutable storage semantics and fine-grained lineage. Delta Lake or Apache Iceberg on top of your existing cloud object storage gives you time travel and versioning without replacing your warehouse. The transformation layer (dbt) can sit on top of what you already have.

How long does it take to build a proper ESG data layer? For a mid-sized enterprise with four to six primary data sources, expect three to five months to production for a first version: one month for data inventory and architecture, two to three months for pipeline and lineage implementation, and one month for validation against a manually calculated baseline. Scope 3 Category 1 and Category 11 add complexity and typically require a separate workstream.

What if our emissions factor data is just spend-based and not activity-based? Spend-based factors (using EEIO or similar) are acceptable for Scope 3 under the GHG Protocol as a screening method. They are less accurate than activity-based data but significantly easier to implement. CSRD does not mandate activity-based data immediately, but it does require you to disclose the methodology and its limitations. Build your pipeline to support both approaches so you can improve over time.

Have a project in mind? Contact Sodio Technologies to discuss your requirements and explore the right technology solution for your business.