The ESG Data Bridge: Why CSRD Implementation Costs Most in the Layer No One Discusses

The €5M quote and the wrong line item

A pattern we keep seeing. A Japanese, Korean, or Thai conglomerate gets the letter — or rather, the internal memo — confirming that one of their EU subsidiaries crosses the CSRD threshold. Net turnover above €50M, more than 250 employees, listed or large enough that the Omnibus simplification of December 2025 didn’t narrow them out. The first sustainability report is due, the audit firm wants to talk, and the procurement process for "CSRD compliance software" begins.

The shortlist arrives. Workiva, Sphera, Greenly, Sweep, Watershed, Persefoni, Pulsora, IBM Envizi. Pricing ranges from €40K/year for mid-market to €200K+/year for large listed entities, plus implementation. The Big 4 sustainability advisory team quotes €2–5M for "CSRD readiness." Half of that is advisory; the other half is described, vaguely, as "data integration and systems work."

The CFO asks the obvious question: why is the data integration line item so large? The reporting tool already has connectors. The audit firm assures everyone the platform handles ESRS modules natively. Where does €1–2.5M of integration work go?

This is the single most under-discussed reality of CSRD implementation: the reporting platforms are the visible 20% of the problem. The other 80% is the data bridge layer between operational source systems and the reporting tool. For Asian conglomerates with operations across Japan, China, Thailand, Vietnam, Korea, and the EU, that bridge is where projects fail — and where most of the actual money goes.

This post is about what that bridge actually does, why Asian operations are uniquely hard, and what we’ve learned building integration middleware for production environments where audit trails are not optional.

What the reporting tools actually do (and don’t do)

Modern CSRD reporting platforms are good at what they’re designed for. They handle the 1,144 ESRS data points across the 12 modules, generate audit-ready iXBRL output, manage double-materiality assessments, and produce the disclosure documents in the format the EU expects. They have pre-built connectors for the largest enterprise systems — typically meaning SAP S/4HANA, Oracle Fusion, Microsoft Dynamics, and a handful of HR and CRM platforms.

What they don’t do is solve the actual problem most Asian conglomerates have, which is that the data those connectors expect doesn’t exist in those systems in the format the connectors want.

A specific example. ESRS E1-6 requires gross Scope 1 and Scope 2 GHG emissions disclosed by location, by activity, with documented emission factors and methodology. The reporting tool’s SAP connector reads the energy expenditure account from your finance ledger. But that account contains the invoice amounts in JPY, broken down by vendor — not by facility, not by energy type, not by kilowatt-hours, and certainly not with emission factors attached. The actual data needed for Scope 2 lives somewhere else: the facility energy management system, the building management system at each plant, or the local utility’s monthly invoice PDFs scanned into a SharePoint folder by the General Affairs department.

This is not a software bug. It’s the gap between operational reality and regulatory requirement. The reporting tool can’t read the building management system at a plant in Saitama. The Big 4 consultant flying in from Frankfurt cannot read it either. Someone, somewhere, has to build the bridge.

What lives in the gap

In our experience implementing data integrations for Asian manufacturers and conglomerates, the source systems feeding sustainability data look something like this for a typical mid-cap with global operations:

flowchart TD
    A["Asian Source Systems"] --> B["ESG Data Bridge"]
    B --> C["CSRD Reporting Tool"]

    A1["SAP ECC / S4 HANA<br/>(JP/KR/CN regional)"] --> A
    A2["mcframe / OBIC7<br/>(JP factory ERP)"] --> A
    A3["Factory MES / SCADA<br/>(Modbus, OPC-UA)"] --> A
    A4["Building Management<br/>Systems (BMS)"] --> A
    A5["Fleet / Logistics<br/>Tracking Systems"] --> A
    A6["HR / Payroll<br/>(SmartHR, local systems)"] --> A
    A7["Supply Chain<br/>(supplier portals, EDI)"] --> A
    A8["Local Accounting<br/>(弥生, 勘定奉行, 用友)"] --> A
    A9["Spreadsheets, PDFs,<br/>shared drives"] --> A

    B1["Connectors layer"] --> B
    B2["ESRS data point<br/>mapping"] --> B
    B3["Emission factor<br/>library"] --> B
    B4["Validation & quality"] --> B
    B5["Multi-language<br/>normalization"] --> B
    B6["Audit log<br/>(immutable lineage)"] --> B

    C --> D["Workiva / Sphera /<br/>Greenly / in-house BI"]

The systems on the left are real. The Japanese factory ERP market is dominated by mcframe and OBIC7, which most European consultancies have never seen. The Chinese ERP market runs on Yonyou (用友) and Kingdee, which require Mandarin documentation and local entity setup to integrate against. Japanese SME accounting is Yayoi (弥生), Kanjō Bugyō (勘定奉行), or Freee, none of which have ESRS-aware export modules. Factory PLCs across older Asian manufacturing plants speak Modbus RTU or proprietary fieldbuses that haven’t been touched in fifteen years.

A reporting tool’s "SAP connector" will not help you read any of this. Neither will the European consultant.

What the bridge actually does

The data bridge layer is, mechanically, an integration platform purpose-built for the regulatory translation problem. The components that matter:

Source-system connectors that speak the protocols of Asian operational systems — SAP IDoc/BAPI for the regional SAP installations, REST APIs for the modern systems, ODBC/SQL for the legacy ones, file-based ingestion for the spreadsheets and PDFs that are not going away. For factory data, OPC-UA and Modbus translation layers that pull energy and production telemetry from the shop floor.

ESRS data point mapping that takes raw operational data and transforms it into the format the reporting tool expects. This is not a one-time configuration — ESRS data points evolve as EFRAG releases implementation guidance, and the mapping needs to be versioned. A change in how E1-6 calculates location-based emissions in 2027 should not require rebuilding the source system connectors.

Emission factor management with provenance. Scope 2 calculations require region-specific grid emission factors, and the choice of source (IEA, country-specific national inventories, supplier-specific factors) is auditable. Scope 3 categories require factor libraries by spend category, transport mode, and supplier. The bridge stores which factor was used for which calculation, when, and why.

Quality validation that catches problems before they reach the reporting platform. Missing months of utility data, outlier readings from a malfunctioning meter, currency-conversion errors, double-counting between subsidiaries that share a facility — all of this needs to be flagged and resolved upstream of the reporting tool, because the auditor doesn’t care that the reporting tool was technically correct if the input was wrong.

Multi-language and multi-entity normalization. Operational data in Japanese, Chinese, Korean, and Thai needs to be normalized into the units and language the reporting framework expects. Subsidiary fiscal years that don’t align with the parent need to be reconciled. Local currency reporting needs FX handling with the right consolidation methodology.

Immutable audit trail. This is the piece most teams underestimate. Limited assurance under CSRD requires the auditor to trace any reported number back to its source. As assurance moves from limited to reasonable over the next few years, this requirement tightens. The audit trail needs to be queryable, tamper-evident, and capable of answering "where did this number come from" months or years after the report was filed.

Output adapters to push normalized data into whichever reporting platform the customer chose. The bridge is platform-agnostic. If you’ve already procured Workiva, the bridge feeds Workiva. If you switched from Greenly to Sphera in year three because of pricing, the bridge keeps working without rebuilding source connectors.

That last point is the strategic one. The bridge is the durable asset. The reporting tool is replaceable.

Why Asian operations are the hard case

A few specific challenges that European consultancies routinely underestimate.

Source system heterogeneity is much higher than in EU operations. A Japanese conglomerate’s subsidiaries have grown by acquisition over decades, often with autonomous IT decisions at each unit. The parent company runs S/4HANA Japan; the auto parts division runs mcframe; the chemicals subsidiary runs Oracle EBS; the trading arm runs a custom Hitachi system from 2008; the Thai factory runs SAP B1; the Vietnamese plant runs spreadsheets. CSRD scope is defined at the parent level, but the data lives across all of these.

Document data is unusually prevalent. Operational reality in Japanese and Chinese factories is that monthly utility statements are PDFs from the local power company, often scanned, sometimes with handwritten annotations. Energy procurement contracts and PPAs are PDFs in legal Japanese or Chinese. Transport logs from regional logistics partners arrive as Excel attachments. Treating these as "edge cases" doesn’t work; in many Asian operations they are the primary data source. simpliDoc-style multilingual document AI for ingesting these is not optional.

Scope 3 supply chain data is genuinely impossible without supplier engagement infrastructure. ESRS E1-6 demands Scope 3 emissions across 15 categories, several of which require supplier-specific data. Asian conglomerates often have thousands of tier-2 and tier-3 suppliers, many of which have never measured their own emissions. The bridge needs a supplier portal — a place suppliers can submit their data, validated and structured — or you fall back to spend-based estimation, which auditors increasingly question.

Local data residency and access constraints. Chinese operational data cannot freely leave China under PIPL. Japanese banking and HR data has strict cross-border restrictions. The bridge architecture has to handle this — local processing, local storage, federated aggregation — not just from a compliance standpoint but because the customer’s audit committee will block any architecture that violates these constraints, regardless of what the EU regulator wants.

Calendar and unit mismatches. Japanese fiscal years often run April–March; Chinese calendar reporting has Chinese New Year cycles affecting production data; energy units are kWh in some systems and MJ in others; weight is metric tons in some places and 斤 in informal Chinese supplier records. None of this is hard individually, but the cumulative effect of getting it consistently right across 40 source systems and 12 ESRS modules is significant engineering work.

European consultancies, in our experience, either don’t know about these problems or quote them as "to be assessed during implementation" — which is how project budgets explode in month four.

The hard parts most teams underestimate

A few things we’ve learned the hard way building integrations for production environments where the data is non-optional.

Audit trail integrity is harder than it looks. It’s not enough to log every input and calculation. The audit trail needs to survive source system changes (a subsidiary migrates from mcframe to S/4HANA in year two and the historical data needs to remain queryable in its original form), prompt or methodology changes (an emission factor was updated by IEA mid-year and you need to know which calculations used the old factor and which used the new one), and platform migrations (you switch reporting tools and the audit trail must follow).

Data lineage is a contract, not a feature. Auditors will ask: "Show me how this Scope 2 number for Q3 2027 was calculated, including which kWh readings from which facility, with which emission factor from which source, and when each piece of data was last modified." The answer needs to be a few clicks, not a forensic exercise. This is a non-trivial engineering problem if the bridge wasn’t designed for it from day one.

Double materiality drift. The double materiality assessment that justifies which ESRS topics are "material" to your business is supposed to be reviewed regularly. In practice, the data feeding that assessment changes monthly as new operations come online or get divested. The bridge has to support not just the data flow but the metadata about what’s in scope this period and why.

Methodology versioning. A Scope 3 Category 11 calculation done in 2027 using one methodology, and again in 2028 using an updated methodology, will produce different numbers. Year-over-year comparability requires storing not just the data but the methodology version, and being able to recalculate historical periods on demand if the auditor or board asks.

The "we’ll just use Excel for now" failure mode. It is genuinely tempting, especially in the first reporting cycle, to bridge the data with Excel and human effort. This works exactly once. By the second or third cycle, the data volumes, the audit requirements, and the reporting timeline make manual bridging infeasible. The teams that started with Excel in year one are the teams paying €3M emergency consulting fees in year three to fix it.

What this looks like in practice

A reference architecture for the bridge layer, based on patterns we’ve shipped for adjacent integration problems and adapted to ESRS requirements:

# Simplified — illustrative, not production
from fastapi import FastAPI
from pydantic import BaseModel
from typing import Literal
from datetime import datetime

class SourceReading(BaseModel):
    source_system: str
    facility_id: str
    metric: str  # e.g. "electricity_kwh"
    value: float
    unit: str
    period_start: datetime
    period_end: datetime
    raw_payload: dict  # original source data, immutable

class ESRSDataPoint(BaseModel):
    esrs_module: str  # e.g. "E1-6"
    data_point: str   # e.g. "scope_2_market_based"
    value: float
    unit: str
    methodology_version: str
    emission_factor_source: str | None
    source_readings: list[str]  # IDs of contributing readings
    calculated_at: datetime

@app.post("/ingest")
async def ingest(reading: SourceReading):
    # 1. Persist immutable raw record
    raw_id = await raw_store.insert(reading)
    # 2. Validate (range checks, missing data, unit checks)
    issues = await validator.check(reading)
    if issues.blocking:
        await alert_queue.send(issues)
        return {"status": "blocked", "issues": issues}
    # 3. Map to ESRS data point(s) via versioned mapping
    mappings = await esrs_mapper.resolve(reading)
    # 4. Apply emission factors / unit conversions, with audit
    calculated = await calculator.compute(reading, mappings)
    # 5. Persist calculated data with full lineage
    for dp in calculated:
        await datapoint_store.insert(dp, lineage=[raw_id, ...])
    return {"status": "ok", "datapoints": calculated}

The pieces not shown — and where most of the actual engineering value is — include the connector library for each source system, the versioned ESRS mapping framework, the emission factor library with provenance, and the audit query interface that lets a sustainability officer (not a DBA) trace any number back to its sources.

What it costs and what it saves

A realistic budget framing for a mid-cap Asian conglomerate with 8–15 entities in CSRD scope:

The Big 4 quote you’ll get for a fully bespoke implementation, including the data integration work bundled in, ranges €1.5–4M for the first year, with €400–900K in ongoing maintenance. Most of that is loaded labor cost at €350–600/hour for advisory partners and managers.

A purpose-built data bridge layer, scoped to the same source-system surface and the same ESRS reporting requirements, runs roughly 30–50% of that cost in year one and substantially less in subsequent years — because the bridge is a reusable asset, not a billable engagement that restarts every reporting cycle. The work that was variable becomes fixed.

The non-cost benefit is reporting timeline. CSRD reports are due, in most member states, within four months of fiscal year-end. A bridge that delivers clean, audit-ready data feeds in 48 hours after period close gives your sustainability and finance teams genuine working time before the auditor arrives. A manual or Excel-based process gives them a panic week and a deferred audit qualification risk.

Who actually has this problem

If you’re reading this and one or more of the following is true, the problem described in this post is not abstract for you. Your group is a Japanese, Korean, Chinese, or Thai parent company with one or more EU subsidiaries crossing CSRD thresholds. Your sustainability data lives across 15+ source systems including at least one of mcframe, OBIC7, regional SAP installations, factory MES, and PDF-based utility statements. Your initial Big 4 quote for "CSRD readiness" was uncomfortable, and most of the discomfort was the data integration line item. Your reporting platform vendor’s connector list does not include the systems where your actual data lives.

The good news is that this is engineering work, not magic. The bad news is that European consultancies cannot do the engineering work because the source systems are in Asia, the operational ground truth is in Asian factories, and the integration patterns require people who can read Japanese error messages, walk a Chinese plant floor, and speak with a Thai facilities manager. Whoever builds the bridge has to be physically and linguistically close to the data.

If you’re scoping CSRD implementation right now and the data integration line item is making your CFO uncomfortable, that’s the conversation we have at Simplico. We’ve been building integration middleware for Asian operational systems for over a decade — long enough to know which protocols mcframe actually speaks, why the OBIC7 export module won’t help, and what it takes to make a factory PLC’s energy data audit-defensible. CSRD just made that work load-bearing for European market access.