From Bill to tCO2e: How Your Emission Evidence Should Flow Through Your Business

The Chain That Must Hold

An assurer's job is methodical and unforgiving: take the final tCO2e figure at the top of your sustainability report and pull on the thread beneath it. Trace backwards — from the aggregated total, through individual scope entries, to the source documents those entries were drawn from — and confirm that every link in that chain is documented, defensible, and tamper-evident. If a single link is missing or broken, the assurer's opinion reflects that gap, and your report's credibility suffers for it.

This matters more than ever in Singapore's regulatory landscape. SGX-listed companies face mandatory climate-related disclosures with external assurance requirements phasing in from FY2025 for large-cap and FY2029 for all listed issuers. But the obligation doesn't stop at listed boundaries. If your company is a supplier, landlord, logistics partner, or service provider to a listed company, their Scope 3 reporting requirement extends into your Scope 1 and Scope 2 data. They will ask you for verifiable emission figures. "We calculated it in a spreadsheet" is not a verifiable figure.

The emission evidence chain isn't optional. It's the infrastructure that makes your sustainability data usable — for reporting, for assurance, and for the supply-chain data requests that are already arriving. What follows is a step-by-step walkthrough of each link in that chain, what each link requires, and where — almost universally — companies discover they have gaps.

Step 1 — The Source Document

Every emission entry begins with a source document: an SP Group electricity invoice, an Esso fuel receipt, a Daikin refrigerant recharge invoice, a PUB water bill, a town gas statement. This document is the start of the evidence chain, and it is the document the assurer will ask to see. Not a summary. Not a spreadsheet cell. The original document, in original form.

What counts as a valid source document? Original invoices with billing period and consumption quantity clearly stated. Utility meter readings with timestamps and the identity of the meter reader. Fuel delivery notes specifying quantity delivered by date and vehicle or asset. Refrigerant recharge records specifying the gas type, quantity, and the equipment it was used on.

What doesn't count? Manually-entered summaries prepared after the fact. Screenshots of totals without line items. Consolidated year-end statements prepared by a finance team from data already entered into an accounting system. These derived documents are useful as cross-references but do not substitute for originals.

The most common failure at this first step is depressingly mundane: a sustainability manager scans an invoice, enters the consumption figure into Excel, and doesn't archive the original PDF. Six months later, the file is gone — deleted from the downloads folder, overwritten, or simply never saved anywhere permanent. The assurer arrives, requests the source document for a specific entry, and it doesn't exist. The chain breaks at step one.

Step 2 — Data Extraction

Once the source document is preserved, someone — human or AI-assisted — reads it and extracts the relevant activity data: billing period, consumption quantity, unit, and utility type. For an electricity bill from SP Group, the extraction produces something like: "March 2025, 4,200 kWh, electricity, SP Group." For a diesel delivery note: "14 March 2025, 280 litres, diesel, vehicle registration SGA 1234 X."

This extraction must be recorded alongside a traceable reference to the source document it came from — the document filename, invoice number, or a system-assigned document ID. If it isn't, the extracted data floats free of its origin, and no one can verify later where it came from.

When AI performs the extraction, the requirements become more explicit. The AI's output should be logged with a confidence score for each extracted field. A human reviewer should inspect the AI output and approve it before it proceeds into the calculation stage. The log should capture the input document reference, the extracted fields, confidence scores, the timestamp, and the model version that performed the extraction. This isn't bureaucracy for its own sake — it's the audit trail that lets an assurer understand exactly what happened to the data at this step.

Common extraction errors include confusing billing period with meter-read period (these are often different dates on the same bill), extracting peak consumption rather than total consumption when both appear, and misreading units (kWh versus MWh is a factor of one thousand — a single transposition doubles or halves an emission entry). Manual extraction from PDFs amplifies these risks because the human doing the reading is also the human making the entry, with no independent check. The extraction is not the data. It's a claim about the data. Claims need to be traceable.

Step 3 — Emission Factor Selection

Extracted activity data is dimensionless until multiplied by an emission factor. The factor converts a physical quantity — kilowatt hours of electricity, litres of diesel, kilograms of refrigerant — into CO2e. The selection of the right factor, from the right source, for the right year, is one of the most consequential decisions in the calculation chain.

For Singapore grid electricity, the authoritative source is the Singapore Energy Market Authority's annual Singapore Energy Statistics. EMA publishes a grid emission factor (in kg CO2 per kWh) that changes year on year as the grid mix evolves. The rule is clear: use the factor published for the year of consumption, not the year of reporting. A 2024 electricity bill should use the 2024 EMA grid emission factor, even if your report is submitted in 2025.

For diesel and other fuels, the UK Department for Environment, Food and Rural Affairs (DEFRA) emission factor tables are widely adopted in the absence of a Singapore-specific equivalent. DEFRA publishes updated tables annually, organised by fuel type, vehicle category, and combustion scope. The factor selection must be documented: which factor, from which source, for which year, and when it was accessed.

This step is where most emission reporting systems fail silently. A company that hardcodes a 2020 grid emission factor into a spreadsheet and never updates it will produce incorrect results for every subsequent year — and the assurer reviewing 2024 data with 2020 factors will flag the discrepancy immediately. Version- controlled emission factor registries are not a luxury. They are what separates defensible reporting from guesswork dressed in decimal places.

Step 4 — Calculation and CO2e Entry

The calculation itself is straightforward: Quantity multiplied by Emission Factor equals CO2e. For the electricity example: 4,200 kWh multiplied by 0.4233 kg CO2e per kWh equals 1,777.9 kg CO2e, or 1.78 tCO2e. The arithmetic is simple. The documentation requirement is not.

The audit trail needs to show the starting value, the factor applied, and the resulting CO2e — not merely the final figure. An assurer spot-checking calculations will re-perform them independently. If the entry shows only "1.78 tCO2e" with no intermediate workings, the assurer cannot verify whether the calculation was performed correctly or which factor version was used.

Rounding deserves specific attention. Intermediate calculations should carry full decimal places through. Round only the final reported figure. Rounding at each intermediate step introduces compounding error that accumulates across hundreds or thousands of entries and produces a reported total that differs from the mathematically correct sum.

Scope categorisation also happens at this step. Electricity purchased from SP Group is Scope 2. Diesel combusted in company- owned vehicles is Scope 1. Refrigerant leakage from owned equipment is Scope 1, with the CO2e calculated by multiplying the refrigerant quantity by its global warming potential (GWP) — a refrigerant-specific multiplier that converts the physical quantity of gas into a CO2-equivalent mass. Errors in categorisation produce misallocation between scopes that affects boundary completeness, and double-counting occurs when the same source appears in multiple cost centres without a consolidation check.

Step 5 — Human Approval

Before any entry enters the formal emission record, a human reviewer should confirm four things: the source document matches the extracted data; the emission source is correctly categorised by scope; the emission factor applied is appropriate and from the correct year; and the calculation is arithmetically correct. This review must be logged — who approved it, when, and whether any correction was made before approval.

This is the human-in-the-loop gate that makes an emission entry assurance-ready. It is also the step that sustainability teams most frequently try to eliminate in the name of efficiency, with consequences that only become visible when the assurer arrives. Assurers expect human accountability for data quality decisions. ISO 14064-1, which governs greenhouse gas inventories at the organisation level, requires that the data management system include review and approval processes. "The AI did it" is not an acceptable chain of custody in isolation.

What does a meaningful approval look like? A reviewer who opens the source document, reads it, compares it to the extracted data, checks the factor reference, and confirms the calculation. What does a rubber-stamp look like? A reviewer who clicks "approve" without opening the source document because they trust the AI extraction. Both produce the same approval record. Only one produces an actually verified entry. The distinction matters when the assurer asks the reviewer to walk through their review process for a sampled entry.

Step 6 — Immutable Record and Hash Chaining

Once approved, an emission entry should enter the evidence vault in an append-only state. It cannot be edited or deleted. If a correction is necessary — a misread quantity, a wrong emission factor applied — a reversal entry is added to the record, documenting the reason for the reversal, and a corrected entry follows. The original incorrect entry is visible in the history. Nothing disappears.

This immutability is not merely a nice-to-have. If a sustainability manager can edit last year's emission figures, so can anyone else with database access. So can a poorly-secured admin panel. So can a SQL injection attack against an unprotected reporting system. The editability of historical data is a governance risk — one that assurers are specifically trained to probe.

Hash chaining provides the mathematical layer of tamper evidence. Each entry in the vault contains a cryptographic hash — a fixed-length fingerprint — of the entry that preceded it. The chain of hashes creates a sequence where any alteration to a historical entry changes the hash that entry produces, which invalidates the hash stored in the subsequent entry, which invalidates the next, and so on. Tampering with a record from twelve months ago immediately produces a broken chain that is detectable by anyone who recalculates the hashes. An assurer can verify the chain independently, without relying on the reporting company's assurances about data integrity.

The distinction between an audit log and an immutable vault matters here. Audit logs record actions but can typically be disabled or cleared by a system administrator. A hash-chained vault produces self-evident proof of integrity that does not depend on the log being intact. The mathematical relationship between entries constitutes the evidence.

Step 7 — Aggregation Into the Report

The total tCO2e for Scope 1 and Scope 2 in your sustainability report is the sum of all approved, vault-recorded entries within the reporting period. The numbers in the report should trace directly to the vault, and the vault entries should trace directly to source documents. The chain from report figure to original bill should be walkable in either direction.

This means the report should not be produced by copying figures from a spreadsheet that was itself populated from a different spreadsheet. It should be a direct export or query from the evidence system. Every figure in the report should have a vault query behind it. If the report is produced by manual copy-paste from a tracking spreadsheet, that spreadsheet becomes a break in the chain — a step where errors can be introduced without leaving a trace.

The Scope 2 calculation merits specific attention here. The GHG Protocol requires that companies report both a location-based and a market-based Scope 2 figure when relevant. The location-based figure uses the EMA grid emission factor for Singapore electricity. The market-based figure uses supplier-specific emission factors or the emission factor associated with renewable energy certificates (RECs) the company has purchased. Companies that have invested in RECs but report only a location-based figure are understating the value of their procurement decisions. Companies that report a market-based figure without holding valid, unexpired RECs are overstating those decisions.

The chain does not end at the report itself. The report must reference a methodology statement that names the standards applied (GHG Protocol, ISO 14064-1), the organisational boundary, the emission factors used and their sources, and the approach to uncertainty. A reader should be able to take that methodology statement and independently reconstruct any calculation in the report. That reconstructibility is the final test of whether the chain holds.

What the Complete Chain Looks Like

Assembled from end to end, the emission evidence chain runs through seven distinct steps, each with a named owner, a documented artefact, and a review mechanism:

1. Source Document — Original invoice, delivery note, or meter reading preserved in read-only archive. Owner: operations or finance. Artefact: the document itself. Review: completeness check at point of receipt.
2. Extraction — Human or AI-assisted reading of the document to produce billing period, quantity, unit, and utility type. Owner: sustainability team or AI system. Artefact: extraction log with document reference, field values, confidence scores, and timestamp. Review: human inspection before proceeding.
3. Factor Selection — Identification of the appropriate emission factor for the emission source and year of consumption. Owner: sustainability team. Artefact: factor reference record (source, version, year, date accessed). Review: annual update check against EMA and DEFRA publications.
4. Calculation — Quantity multiplied by emission factor to produce CO2e, with scope categorisation applied. Owner: sustainability system. Artefact: calculation record (starting value, factor applied, resulting CO2e, scope). Review: arithmetic spot-check during human approval.
5. Human Approval — Reviewer confirms source document, extraction, factor selection, and calculation are all consistent and correct. Owner: named sustainability officer. Artefact: approval log (reviewer identity, timestamp, corrections). Review: the approval itself is the review.
6. Immutable Vault Entry — Approved entry enters the evidence vault in append-only, hash-chained form. Owner: evidence system. Artefact: vault record with hash linking it to the prior entry. Review: hash chain verification at any time.
7. Report Aggregation — Vault entries are summed by scope and period to produce the report figures, supported by a methodology statement that enables independent reconstruction. Owner: sustainability team. Artefact: report and methodology statement. Review: assurance engagement.

Every step in this chain is verifiable. Every gap in this chain is findable. The question is not whether assurers will look for gaps — they will — but whether your chain is ready to withstand the inspection.