ESG Reporting for FMCG, Packaging & EPC on Fabric

Most mid-market FMCG, packaging, and EPC companies do their ESG reporting in Excel. Energy consumption pulled from utility bills. Scope 3 emissions estimated from supplier emails. Packaging recyclability sourced from product spec sheets updated six months ago. Water usage from a facility manager's log.

This is not a compliance gap — it is a data architecture gap. The same problem that makes operational reporting slow and untrustworthy is the problem that makes ESG reporting slow and untrustworthy.

There is a common assumption that sustainability data is somehow separate from operational data — that it lives in a different system, is owned by a different team, and requires a different platform. That assumption is why most mid-market industrials end up with an ESG spreadsheet that is assembled once a year, audited under stress, and filed with a regulator before the data is thoroughly validated.

The reality is that most sustainability metrics are operational metrics viewed through a different lens. Energy consumption at a plant is an operational cost metric and an ESG metric simultaneously. Packaging waste is a production efficiency metric — it shows up in OEE calculations — and an ESG metric simultaneously. Supplier delivery performance is a supply chain metric and, when extended to include supplier emissions disclosures, a Scope 3 metric simultaneously.

The data is already there — in SAP S/4HANA, in SAP ByDesign, in Microsoft Dynamics 365, in the MES, in the WMS. The missing piece is a layer that connects it, governs it, and makes it visible in a form that can survive an audit.

Microsoft Fabric with OneLake as the data foundation is not purpose-built for ESG — it is purpose-built for any data that needs to be unified, governed, and made available for reporting. That is exactly what sustainability data requires.

The architecture is the same as an operational data deployment:

ADF pipelines ingest from source systems — utility meter APIs for energy data, SAP S/4HANA for production and materials consumption, procurement records from SAP ByD or Dynamics 365 for supplier spend and emissions factors, facility management systems for water and waste data.

All of that lands in OneLake as Delta Parquet tables, governed under the same data model as the operational estate. There is no separate sustainability data lake. There is no parallel reporting environment. There is one OneLake, one governance model, one set of semantic models in Power BI — and sustainability metrics sit alongside operational metrics because the underlying data is the same data.

Power BI then delivers two views of that data: the operational view (OEE, OTIF, fill rate, cost per unit) and the ESG view (energy intensity per tonne of output, Scope 1 and Scope 2 emissions, supplier-level delivery and emissions variance, packaging recyclability rate, waste per production run). Same semantic layer. Different perspectives.

The most immediate change is audit confidence. When energy consumption data flows directly from meter APIs into OneLake rather than being manually extracted from utility bills into a spreadsheet, the audit trail is automatic. The regulatory submission does not break because someone cannot find the original data source. Every figure is traceable to the ingestion pipeline, to the source system, to the raw event.

Procurement gains a new lens. When supplier-level emissions data is connected to the procurement record in the same OneLake estate, the procurement team can see — at vendor selection time, not ESG reporting time — which suppliers have high delivery variance and which have high emissions intensity. Scope 3 tracking moves from an annual exercise to an ongoing supplier performance dimension.

Packaging waste enters the OEE conversation. A packaging line running at 82% OEE because of high material waste rates is both an efficiency problem and a sustainability problem. When packaging waste data from the MES is in the same semantic model as OEE, the plant director can see both dimensions simultaneously. The conversation stops being "OEE versus ESG" and becomes "line efficiency, all-in."

Power Automate can alert the sustainability lead when energy intensity per tonne crosses a threshold — the same mechanism that alerts the supply chain manager about OTIF trend breaks. The platform does not distinguish between operational and sustainability signals; both are data, both get the same treatment.

The reporting requirements landing on mid-market FMCG, packaging, and EPC companies — BRSR Core in India, UAE Ministerial Decision sustainability disclosure requirements, CSRD scope creep through Tier 1 suppliers, SEC climate disclosure rules for companies with US-listed counterparts — are not asking for aspirational statements. They are asking for data with audit trails.

BRSR Core, which applies to the top 1,000 listed companies in India by market capitalisation and is cascading to their supply chains, requires business responsibility and sustainability reporting against specific metrics: energy consumption, water intensity, GHG emissions (Scope 1, 2, and 3), waste generated and disposed. Those are data fields — not qualitative statements.

A Microsoft Fabric deployment that connects these data points to OneLake and surfaces them in a Power BI semantic model produces the audit-ready output that regulators are asking for. An Excel-based process, by definition, cannot.

Scope 1 and Scope 2 are tractable because the data already exists in your systems — energy from meter APIs, direct emissions from production and materials consumption in SAP S/4HANA or SAP ByDesign. Scope 3 is the genuinely hard one, because most of the data lives outside your walls, in suppliers who may not measure their own emissions at all. Pretending otherwise is how ESG reports acquire a single confident Scope 3 number that no auditor can defend. The honest approach is a hybrid, and it is a data-modelling decision as much as a sustainability one.

In practice that means: use supplier-disclosed data where a supplier actually provides it, fall back to industry-average emissions factors (the GHG Protocol Scope 3 Standard) where they do not, and — critically — carry a confidence flag on every figure so the report shows which numbers are measured and which are estimated. On a Microsoft Fabric estate, that flag is a column in the OneLake model and a visible dimension in the Power BI report, not a footnote. Better to surface the gap explicitly than to average it into a single number that looks precise and falls apart under audit. Regulators and serious investors trust a disclosed estimate with a confidence marker far more than a suspiciously exact figure with no provenance.

It also reframes Scope 3 as an ongoing supplier-data programme, not an annual calculation. Each supplier that moves from industry-average to disclosed data tightens the estimate, so the number improves over time as supplier engagement matures — and the same governed supplier record that feeds procurement's delivery-variance view feeds the Scope 3 emissions view. The platform manages the data once it arrives; collecting it from under-resourced suppliers is the separate workstream that no Fabric deployment removes. Naming that honestly is the difference between a credible disclosure and a number waiting to be challenged.

A flexible packaging manufacturer — approximately 600 employees, two production sites, SAP ByDesign as the ERP — was preparing for BRSR Core compliance and had no structured way to report GHG emissions below the annual estimate level. Energy data was in utility bills. Material waste was in a production log spreadsheet. Supplier emissions factors were not tracked at all.

A Fabric deployment that had originally been scoped for operational reporting — OTIF, OEE, and material yield — was extended over six weeks to incorporate sustainability metrics. ADF pipelines were added to pull utility meter data via API and to ingest supplier emissions factors from a standardised supplier questionnaire stored in SharePoint. The Power BI semantic model was extended with an ESG dimension, sitting on the same OneLake estate as the operational data.

At the end of the engagement, the sustainability lead had a Power BI report covering Scope 1 and Scope 2 emissions by site, energy intensity per tonne of output, material waste rate by production line, and supplier-level delivery performance. The annual BRSR Core submission, which had previously taken six weeks of manual data assembly, was produced in two days.

If your organisation is not running operations on Microsoft Fabric — if your operational reporting is still spreadsheet-based or if you have not yet built a Fabric estate — the ROI case for a sustainability-first Fabric deployment is harder to make. The economics work when sustainability data shares infrastructure with operational data. A standalone ESG data platform, separate from everything else, is both expensive and fragile.

If your primary sustainability challenge is strategy — defining material topics, engaging stakeholders, setting science-based targets — technology is not the first answer. The data platform is the reporting and audit layer. The sustainability strategy has to exist first.

If your supply chain is highly fragmented — hundreds of Tier 1 suppliers with no standard data exchange format — Scope 3 data collection will require a supplier engagement programme that goes beyond what a Fabric deployment alone can solve. The platform can manage the data once it arrives; collecting it from unwilling or under-resourced suppliers is a separate workstream.

The Discover phase maps which sustainability metrics are already in the operational data estate and which require new ingestion pipelines. In most mid-market FMCG and packaging companies, Scope 1 and Scope 2 data — energy and direct emissions — can be connected within four weeks because the underlying data exists in utility systems and ERP records. By week six, a Power BI dashboard covering energy intensity per tonne, Scope 1 and Scope 2 emissions by site, and material waste rate by production line is live and connected to OneLake.

Scope 3 and supplier-level emissions data is an Expand phase item — it requires supplier data collection processes that cannot be compressed into six weeks. That is the honest sequencing.

The reframe that changes the investment decision is that ESG reporting is not a separate compliance project — it is your operational data viewed through a sustainability lens. Energy is an operational cost metric and an ESG metric; packaging waste shows up in OEE and in the waste disclosure; supplier delivery performance extends into Scope 3. So the question is not "what ESG platform do we buy" but "are we already building the operational data foundation that ESG reporting also runs on." If the answer is yes, the marginal cost of audit-ready ESG is an extra dimension on a model you are building anyway.

It starts where the data already exists. A six-week build connects Scope 1 and Scope 2 — energy intensity per tonne, emissions by site, material waste by line — because that data sits in utility APIs and the ERP, and lands it in OneLake with Purview lineage so every figure is traceable for the audit. The packaging-manufacturer example cut a BRSR Core submission from six weeks of manual assembly to two days. Scope 3 follows as an Expand-phase supplier-data programme, sequenced honestly rather than promised on day one.

And weigh it against the alternative now arriving: regulators (BRSR Core, UAE disclosure rules, CSRD scope-creep through Tier 1, SEC climate rules) are asking for data with audit trails, not aspirational statements — and the annual spreadsheet is becoming a regulatory and investor risk in itself. The leader who owns the disclosure does not need a separate ESG data lake; they need the operational foundation extended one dimension. Unify the data, make the disclosure audit-ready by design, and the once-a-year fire drill becomes a live report on the same platform that runs the plant.