An assurance provider does not audit a number in isolation. They audit a chain of custody. Every tonne of CO2-equivalent disclosed in a CSRD or SEC filing needs to trace back through calculation steps to a source document, an activity measure, and an emissions factor with a documented source and version. If any link in that chain is missing, the number is undefendable.
This is a design problem, not a data problem. The data is usually somewhere in the company. The problem is how it gets recorded, versioned, and connected on its way from raw transaction to disclosed figure. We spent a long time thinking about this when designing Emitpulse, and the decisions we made shape everything about how the ledger works.
What "Auditable" Actually Means in the Context of Emissions Data
The word auditable gets used loosely. In the context of sustainability assurance, it has a precise meaning grounded in ISAE 3000 (Revised), the international standard for assurance engagements on non-financial information. Under ISAE 3000, limited assurance requires the practitioner to obtain sufficient appropriate evidence to support a conclusion that nothing has come to their attention to suggest the information is materially misstated.
For emissions data specifically, "sufficient appropriate evidence" means the auditor can agree a disclosed figure to its underlying calculation, agree that calculation to its input data, agree that input data to a source document or authenticated data feed, and agree the emissions factor applied to a published, versioned factor library. That four-step verification chain is what "auditable" means in practice.
A carbon ledger that records only the final category totals cannot satisfy this requirement. A carbon ledger that records every calculation row with full lineage can.
Principle 1: One Row Per Emissions Event
The foundational design choice we made is that every emissions event gets its own row in the ledger. Not one row per month, not one row per Scope category, not one row per supplier. One row per activity that generates a calculable emissions figure.
A single row in the Emitpulse ledger contains: a unique event identifier, the date of the underlying activity, the legal entity, the Scope classification (1, 2, or 3 with sub-category), a description of the activity, the activity quantity and unit (kWh consumed, litres of fuel, GBP of spend, km travelled), the emissions factor applied, the factor source library and vintage year, the calculated tCO2e figure, the calculation method flag (spend-based, activity-based, supplier-specific), and a reference to the source document or data feed that supplied the activity datum.
This structure is modeled after how financial ledgers work. A financial auditor expects to trace every line in a P&L to a journal entry, and every journal entry to a source document. Carbon accounting assurance is heading in the same direction, and we built for that standard from the start rather than retrofitting it later.
Principle 2: Factor Versioning is Non-Negotiable
Emissions factors change. DEFRA updates its UK government conversion factors annually. The US EPA's eGRID regional emission rates update with each new grid year. IPCC global warming potential values shift between assessment reports (AR5 vs. AR6 changes GWP for methane from 28 to 27.9, with further refinements for biogenic sources). If you apply a 2022 factor to a 2025 activity and do not record which vintage you used, your disclosed figures cannot be independently replicated.
In our ledger, every emissions factor reference stores the factor value, the source library name, the publication version or year, and the date it was applied. When a factor library updates, we do not silently update historical calculations. We flag the change, allow the user to decide whether to restate prior periods, and record any restatement with a reason code.
This matters for multi-year comparability disclosures. ESRS E1 requires disclosure of prior year comparatives and an explanation of material changes in methodology or factors. If you cannot distinguish between a genuine emissions reduction and a factor-driven restatement, your year-on-year trend narrative is unreliable.
Principle 3: Immutable Source Records with Explicit Override Logging
One of the more subtle audit risks in carbon data is the normalized edit: someone adjusts an activity figure, or swaps an emissions factor, and the original value disappears. When the auditor asks why the Scope 2 electricity figure for Q3 is lower than the utility bill they are holding, there is no version history to explain it.
Our approach is that source records are write-once. When data enters the ledger from a CSV upload, an ERP connector, or a supplier response, the raw import is stored immutably with a timestamp and import identifier. If a correction is needed, a correction record is created with a reference to the original, a reason code, the correcting user identity, and the timestamp. The original is never deleted. The ledger always reflects the net of original plus any corrections, with full history visible.
We built this partly because we saw what happens without it. A sustainability manager at a growing food-and-beverage business had been using a prior tool that let direct edits to emissions figures. By their second year, they had no way to explain why certain monthly figures differed from what was on their utility bills. The tool's help desk could not reconstruct what had happened. We built immutability because that kind of forensic dead end is exactly what an assurance engagement cannot afford.
Principle 4: Disclosure Mapping Must Be Explicit
The connection between the ledger and the disclosure report is itself an audit point. An assurance provider needs to know that the Scope 3 Category 1 figure in the ESRS E1 disclosure is the sum of ledger rows classified as Scope 3, Category 1, for the reporting entity and period, calculated using the specified methodology, with no manual adjustments made at the aggregate level.
This sounds obvious until you see how reports often get assembled. A common pattern: ledger exports to CSV, someone opens it in Excel, adjusts a few figures to account for a late data submission, adds some categories manually, and pastes the totals into the report template. The connection between the ledger and the report is now a spreadsheet process that no one will be able to reconstruct six months later.
In Emitpulse, the disclosure report is generated by querying the ledger directly with defined filters: entity scope, date range, Scope classification, methodology flag, and exclusion rules. Every report generation event is logged with those filter parameters. The assurance provider can rerun the same query and get the same numbers, because the query definition is stored as part of the report record.
The Boundary Question: What the Ledger Covers and What It Doesn't
We should be clear about what a well-designed ledger does not solve. A ledger records what you give it. If your Category 1 spend classification is wrong (office supplies coded as raw materials), the ledger records and traces the wrong answer faithfully. The ledger is an integrity layer, not a data quality correction layer.
We are not saying ledger design is sufficient for audit readiness. Ledger design is necessary but not sufficient. The other component is data governance: clear ownership of each emissions category, defined data collection procedures, documented assumptions for estimation approaches, and a review process before the disclosure draft is finalized. Those are organizational controls. The ledger records the output of those controls in a retrievable, traceable form.
The combination of a well-structured ledger and documented data governance is what produces a disclosure that survives an assurance engagement. Neither alone gets you there.
A Worked Example of Chain-of-Custody
Here is what a chain-of-custody trace looks like in the Emitpulse audit export for a single ledger row. The disclosed ESRS E1 figure for Scope 3 Category 3 (Fuel and energy-related activities not included in Scope 1 or 2) for a manufacturing company contains a natural gas upstream extraction and processing component. The trace for one row in that component:
- Disclosed figure contribution: 14.7 tCO2e
- Activity: upstream emissions from natural gas procurement, January 2026
- Activity quantity: 82,500 kWh of natural gas (converted from 7,500 therms on utility statement)
- Emissions factor: DEFRA 2025 "Fuels - Natural gas" upstream factor, 0.178 kgCO2e/kWh
- Calculation: 82,500 kWh x 0.000178 tCO2e/kWh = 14.685 tCO2e, rounded to 14.7
- Source document reference: utility invoice ID INV-2026-0043, uploaded 2026-02-14
- Import batch ID: IMP-2026-0018
- No corrections applied
That trace can be reconstructed from the ledger export in about 30 seconds. That is what "auditable" looks like in practice.