Ask a sustainability lead at a mid-market manufacturer why their last GHG report took so long, and the answer is almost never "we do not care about emissions." The answer is usually some version of: "It took three weeks to collect all the invoices," or "The electricity figures from the Johor facility were in a different unit," or "Finance changed the ERP system and the extract we used last year broke."
The problem being described is an infrastructure problem, not a motivation problem. The data needed to calculate Scope 1, 2, and 3 emissions exists inside most manufacturing organisations. Fuel purchase invoices sit in accounts payable. Electricity billing data is in whatever portal the utility provides. Purchase orders for raw materials are in the ERP. The challenge is that none of this data was collected and stored with emissions accounting in mind, so every reporting cycle involves re-excavating and transforming it from scratch.
Why Spreadsheets Break at the First Complexity Threshold
The spreadsheet approach works tolerably well for a single facility with one electricity account, one fuel type, and no Scope 3 obligation. It fails in recognisable ways as complexity increases.
First, there is the unit normalisation problem. A Singapore utility bill reports consumption in kWh. A diesel delivery receipt reports in litres. A natural gas invoice may report in therms, GJ, or MMBtu depending on the supplier. Converting these to a common unit for emission factor multiplication requires a lookup table, and that lookup table needs to be updated when emission factor vintages change. In a spreadsheet, this logic is invisible and its maintenance is informal.
Second, there is the version control problem. An emissions report for a given year is not finished the moment the spreadsheet is submitted. Auditors may request revisions. A billing dispute may surface a corrected invoice three months after the report was filed. The CFO may ask for a restatement as part of a merger due-diligence process. Tracking which version of the spreadsheet incorporates which correction, and which historical factor database was used in which year, is work that spreadsheets do not handle well.
Third, there is the multi-facility aggregation problem. A manufacturer operating three facilities in different countries, each with its own ERP configuration and utility billing portal, cannot simply add up figures from three separate spreadsheets without resolving boundary definitions, unit conventions, and which entities are in-scope. Doing this manually each year creates inconsistency between reporting periods that third-party verifiers flag.
What an Emissions Data Infrastructure Actually Contains
When we talk about emissions data infrastructure, we mean a set of persistent, documented systems for collecting, transforming, storing, and outputting activity data. Each component has a specific job.
The collection layer handles inbound data from source systems: utility portals, ERP exports, meter APIs, and manual uploads for cases where no direct connection is available. This layer needs to accommodate the diversity of formats that actually exist in a manufacturing business, PDF invoices, Excel exports, CSV meter reads, API responses from smart meter systems. It also needs to handle the fact that data arrives on different schedules. Electricity bills may arrive monthly; fuel deliveries may be recorded at point of purchase; purchase orders may be exported quarterly.
The transformation layer does two things: normalises the incoming data into a consistent unit structure, and classifies each entry into the GHG Protocol scope and category framework. Normalisation means resolving the litre-to-kWh-to-GJ unit problem with documented conversion factors. Classification means deciding: is this a Scope 1 stationary combustion entry, a Scope 2 purchased electricity entry, or a Scope 3 Category 1 purchased goods entry? That classification has to be consistent across reporting periods and documented so an auditor can see the basis for each assignment.
The emission factor layer matches each classified activity entry to the correct emission factor. This is not trivial. The right factor for natural gas combustion at a Singapore facility is not the same as the right factor for the same activity at a Malaysian facility. The right factor for purchased electricity in Singapore depends on the reporting period because the EMA grid emission factor changes annually. The right Scope 3 factor for a purchased material depends on whether the company is using a spend-based or activity-based approach. All of these decisions need to be recorded against each entry.
The storage layer keeps all of this: source documents, extracted values, classification decisions, factor versions applied, and calculation results. It needs to support lookups by time period, by facility, by scope category, and by source document. Without this, answering "show me the audit trail for the natural gas entries in Q2" is a manual investigation rather than a query.
The output layer formats the aggregated results for the disclosure format required: GHG Protocol summary tables, CDP questionnaire data structure, IFRS S2 metrics, SGX climate reporting disclosures. These formats differ in what disaggregation they expect, what boundary definitions they require, and what units they use.
The Connection Points That Break Most Often
In our experience working through how manufacturing companies assemble their emissions data, the same connection points fail repeatedly.
The invoice-to-activity-data step is the first common failure. An electricity invoice has a consumption figure and a billing period, but also potentially a demand charge, a fuel cost adjustment, and several line items that have nothing to do with kWh. Extracting just the consumption figure accurately requires understanding the invoice format, which varies by utility and sometimes by tariff class within the same utility.
The allocation step for multi-facility businesses is the second. When a single legal entity operates multiple sites that share a parent-level utility contract or master purchase agreement, attributing the total consumption to individual facilities requires documented allocation logic. Without that logic, per-facility figures cannot be reproduced independently.
The factor database maintenance step is the third. Emission factors are not permanent. The EMA updates Singapore's grid emission factor annually. IPCC AR6 GWP values superseded those from AR5. Using outdated factors in subsequent years creates a silent inconsistency in the time series. Managing this requires tracking which factor vintage applies to which reporting period, permanently, not just for the current year.
Where Spreadsheets End and Infrastructure Begins
The line between a sophisticated spreadsheet and genuine infrastructure is not a technology line. It is a reproducibility line. If a different person in the sustainability team can reproduce last year's calculation, from raw source documents, without asking the person who originally built the model, the system has infrastructure qualities. If they cannot, it does not.
A third-party verifier applying ISO 14064-3 expects to be able to trace any individual emission entry in the final report back to the source document, the extraction step, the classification decision, and the factor applied. A spreadsheet can technically contain all of this if it is built carefully and disciplined documentation is maintained. In practice, they almost never are, because the documentation load is incompatible with the pressure to finish the report on time.
Building emissions data infrastructure is not the same as building a perfect emissions calculation. It means building a system where the calculation can be reproduced, audited, and updated without starting from scratch. That distinction matters more as disclosure requirements tighten and third-party verification becomes standard rather than optional for the companies SGX rules are reaching.
What This Does Not Replace
Infrastructure does not make boundary decisions. Whether a leased facility is inside or outside your organisational boundary, how to treat joint ventures, and whether to apply the operational or equity share approach are policy decisions that belong to the sustainability lead and the CFO. Good infrastructure makes it easier to implement whatever decision you have made, and to change it consistently across historical periods if you need to restate. It does not make the decision for you.
Infrastructure does not resolve supplier data quality. For Scope 3 categories that depend on supplier-provided primary data, the quality of the calculation is limited by the quality of what suppliers submit. Better data infrastructure makes it easier to ingest and validate whatever suppliers do provide, but it cannot substitute for data that does not exist.
The most immediate return from investing in emissions data infrastructure, before any disclosure improvement is visible, is time. The annual reporting cycle that currently takes six weeks of manual work can be compressed once the collection and transformation steps are automated. That time saving is real and measurable before the first CDP submission and before any auditor review.