The Emission Data Module: How Every Kilogram of CO2e Actually Gets Onto the Ledger
The emission ledger is the foundational data structure of carbon accounting. Every number on an ASRS report, every NGER submission, every board slide derives from records in this one table. Here is what those records actually look like inside Carbonly, how they get created, and what keeps them defensible over seven years of retention.
Every disclosed carbon number in Australia rests on a table.
Not a spreadsheet. Not a dashboard. A table, somewhere, that says "on this date, this activity happened, at this quantity, in this unit, and it produced this amount of CO2e, using this factor, sourced from this document." Everything downstream (the NGER submission, the AASB S2 climate statement, the CDP disclosure, the board's Scope 1 chart) is a projection of that table.
When we designed Carbonly, this was the first thing we built. Not the AI. Not the reports. The ledger. Because if the ledger is wrong, everything else is theatre.
What an emission record actually is
An emission record is the atomic unit of carbon accounting. One row. One activity. One number.
Think of it the way a general ledger thinks of a journal entry. A journal entry doesn't just say "we spent money." It says: on 2026-08-14, this account was debited $4,320.50 for this vendor invoice, posted by this user, referencing this GL code. If any of those fields are missing, the entry can't survive an audit.
An emission record works the same way. It doesn't say "we burned diesel." It says: on 2026-08-14, at the Mount Isa haul road site, we combusted 12,480 litres of automotive diesel oil, which under the NGA Factors 2025 edition (Table 3, Post-2004 vehicles) produces 33.53 tonnes CO2-e, and the source is fuel docket #A-88214 from Ampol.
That's the level of granularity the ledger has to hold. Not because we like typing. Because the alternative is trying to reconstruct the number from memory in front of an ASSA 5010 assurance engagement three years later, and that reconstruction is what breaks.
The core fields every emission record carries
Every row in the Carbonly emission ledger is designed to carry the following.
activity_date. The date the emission occurred, not the date the invoice was raised. This matters for period allocation. A June invoice covering May consumption belongs in May.
project_id. The site, facility, or business unit the activity occurred at. Carbonly's project structure supports operational, financial, and equity-share consolidation methods, so the same underlying record can appear in different report totals depending on the boundary being disclosed.
activity_type. What actually happened. Diesel combustion. Grid electricity purchase. Refrigerant top-up. Business flight. Waste to landfill. This is not a free-text field. It maps to a controlled vocabulary tied to NGER activity categories.
activity_quantity and activity_unit. The physical measurement. 12,480 litres. 4,207 kWh. 1.2 kg R-410A. This is the field a spend-based approach does not capture, because it never extracts quantity from the source document. It takes dollars, multiplies by an intensity factor, and hopes. Quantity is the difference between an audit-defensible number and a plausible number. Our extraction pulls quantity first, price second (see the per-supplier extraction templates post).
scope. 1, 2, or 3. And for Scope 3, the specific category (1 through 15).
factor_id and factor_version. The exact emission factor used and the version it was calculated with. NGA Factors 2025, Table 5, State-specific electricity, Victoria. Not "the electricity factor." A record calculated with an NGA 2024 factor keeps that version on the record after the 2025 edition is published. This is not an implementation detail. It is the whole point of a defensible ledger.
gas_breakdown. The CO2, CH4, and N2O components of the total, in tonnes CO2-e. NGER requires per-gas reporting for facilities above threshold, and AR5 versus AR6 GWP toggling only works if the gases are stored separately.
methodology_label. How this number was arrived at. Activity-based, hybrid, supplier-specific, average-data, or spend-based. This is a required disclosure under AASB S2 and a field assurance providers are likely to test.
source_document_link. A pointer to the actual PDF, image, CSV, or spreadsheet the record was derived from. Not a filename. A hashed reference to the stored document, so we can prove the record and the evidence are still the same pair three years later.
created_by (actor). The user, agent, or integration that created the record. Human data entry, AI extraction, calculation rule or CSV import. Every record knows its own origin.
created_at (timestamp). When the record was created. Combined with the actor, this is the start of the audit trail.
content_hash. A cryptographic fingerprint of the record's material fields. Any edit produces a new hash. Any tampering is detectable. Records inside a locked period cannot have their hash changed without going through a formal restate workflow that logs the change separately.
That is thirteen fields. Every one of them is load-bearing. Miss one and the record loses the property that makes it useful: the ability to survive a challenge three years after it was created.
Four ways a record actually gets created
The ledger is agnostic about origin. What matters is that the origin is logged.
Path one: AI document extraction. A supplier invoice, meter read, fuel docket, or freight bill arrives, usually via a project-specific email address, a OneDrive folder sync, or a SharePoint connection. The Document AI Engine handles eight file formats (PDF, Word, PowerPoint, Excel, CSV, RTF, image, scanned) and produces a proposed emission record with all the fields above pre-populated. Confidence scores are attached at the field level. If confidence is below the project's threshold, the record lands in a review queue rather than the ledger. If it's above, it commits directly. Either way, the original document is stored, hashed, and linked. This is the workhorse path. We designed the ingestion pipeline expecting it to handle the majority of records for an active site. For the mechanics of how the extraction actually reads an invoice, we walked through the full workflow in the AI document extraction walkthrough.
Path two: calculation rule derivation. Not every emission comes from an invoice. An odometer reading from Monday to Friday is a delta. A tank dip on the first of the month, minus the tank dip on the last, is fuel burned. Grid electricity between two meter reads is consumption. Calculation rules take two or more input readings and produce a derived emission record. The rule itself is stored on the record, so an auditor can see not just the number but the arithmetic that produced it, including which two source readings were subtracted and when.
Path three: manual entry. Some records will always be typed. A refrigerant top-up the contractor emailed in a photograph. A one-off diesel purchase paid on a personal card. A correction to a prior extraction where the AI got the unit wrong. Manual entry is a first-class path. The actor field records who typed it, and the source document link still points to whatever evidence the human had, even if that evidence is a phone photo of a handwritten note.
Path four: bulk CSV import. Historical data migration and ERP exports need a batch path. When a business first onboards, they typically have twelve or twenty-four months of prior consumption already sitting in a workbook. The bulk import path validates every row against the same schema as the other paths. Activity type must map to the vocabulary. Quantity and unit must be consistent. Factor version must be specified. Rows that don't validate are rejected into an error queue rather than silently accepted. There is no path to the ledger that bypasses the schema.
Methodology label per record, not per report
A common shortcut in carbon accounting is to label the entire report as "activity-based" and move on.
That label is rarely accurate. Real Scope 3 inventories mix supplier-specific data (where a supplier has shared their own footprint), activity-based data (litres, kWh, kg), average-data (industry mean intensities), and spend-based data (dollars times an EEIO factor). A single-label report hides which category is which.
Carbonly tags methodology at the record level. Every row on the ledger knows how it was calculated. When the disclosure gets built, we can tell you exactly what percentage of Scope 3 Category 1 is supplier-specific versus spend-based, and where the spend-based portion is concentrated. That is not a nice-to-have. Under AASB S2, methodology mix is a required disclosure. Under ASSA 5010 assurance, expect it to be tested early.
Which factor version produced each number, kept on the record
NGA Factors update annually. The 2025 edition is not the same as 2024. Victorian grid electricity moved from 0.77 to 0.78 kg CO2-e/kWh between editions. Small change, but multiply it by a portfolio of 40 sites and it matters. (We walked through the state-by-state 2025 table in the NGA Factors explainer.)
Each emission record on the Carbonly ledger keeps the emission factor version it was calculated with. When an auditor asks which factor sits behind a 2024-25 figure, the answer is on the record. A restatement of a locked period is recorded with a reason. That matters because ASRS disclosures are audited.
The material library (the internal repository of factors) carries its own provenance for each factor. When an auditor asks "why did you use 0.78 for Melbourne electricity in Q2 2026," the answer is not "because the software said so." The answer is "NGA Factors 2025 edition, Table 5, State-specific electricity, Victoria, published August 2025, effective from 1 July 2025." We wrote about how the material library handles NGA, EPD, and custom factors here.
Why the gas components are stored separately
This is where the gas_breakdown field earns its keep.
NGER requires AR5 Global Warming Potentials. AASB S2 requires AR6. If your ledger only stores tonnes CO2-e, you cannot render both without recalculating from source. If your ledger stores the CO2, CH4, and N2O components separately, a restatement to a different GWP set is traceable arithmetic rather than a recalculation from source.
Carbonly stores the components separately and calculates on AR5, the set NGER requires. It does not currently produce AR6 output, so restating any non-NGER portion to AR6 is a separate step outside the platform. For a methane-heavy facility (a landfill, a coal mine, a wastewater treatment plant), the methane component moves by about 6 percent between AR5 (28) and AR6 fossil methane (29.8).
AASB S2025-1 relief provisions (released 15 December 2025) allow NGER reporters to use AR5 GWPs in the AASB S2 disclosure for NGER-covered portions.
Anomaly checks read the ledger daily and after each batch
Anomaly checks run daily at 6am and after each document batch. They are deterministic rules, not a model. Five rule types cover the space that catches most errors: unit mismatch (a fuel invoice suddenly denominated in gallons instead of litres), quantity outlier (a Victorian office pulling ten times its usual kWh), factor drift (a record calculated against last year's factor when this year's should apply), duplicate detection (the same invoice ingested twice), and period leakage (an activity dated inside a locked period). We walked through the anomaly engine's rule taxonomy in the five-rule-types post.
Anything that trips a rule lands in a queue with the record flagged. Nothing gets silently blocked. The rule that fired, the threshold that was breached, and the record it fired against are all visible. A reviewer either resolves the flag (a genuine spike, explained) or corrects the record (the AI misread the unit, fix it and resync). The action they take is logged on the record itself, so an auditor can see not just the flag but the human decision that closed it.
Compliance gap fixes queue reads the ledger structurally
Anomaly detection watches for individual records that look wrong. The compliance gap queue watches for structural absences.
Missing Scope 2 records for July at a project that reported June and August. A supplier who submitted invoices in Q1 and Q2 but nothing in Q3. These are not anomalies in any single record. They are patterns of missing records. The gap queue surfaces them before the reporting cycle closes, when they can still be fixed, rather than at the audit, when they cannot.
Auditor Workspace against sampled records
When an ASSA 5010 assurance engagement starts, the auditor sampling begins on the ledger. Not on the report. Not on a spreadsheet export. On the underlying records. This is the reality behind the eight-check audit preparation guide: every check terminates in a ledger row.
The Auditor Workspace gives the audit team read-only access to sampled emission records. For each sampled row, they see all thirteen fields, the source document (opened in the browser), the calculation trail, the factor version used, the actor who created the record, and any anomaly or gap flags raised against it during the period. They can also see the restate history for records changed after a period was submitted.
The Evidence Pack export bundles the whole picture (records, source documents, factor provenance, methodology tags, actor logs) into a single archive at the boundary of a report. That is the artifact that gets handed to the audit team. It is not a PDF. It is the ledger's answer to a specific report, frozen in time.
For a deeper walkthrough of what lineage looks like from source document to disclosed number, we covered the full trail in the emissions data lineage post.
What the ledger deliberately does not do
Two things.
It does not replace the finance general ledger. Emissions are physical; the finance ledger is monetary. They intersect (an invoice can be a source document for both) but they diverge everywhere it matters. The right relationship is that the two ledgers share sources, not schemas.
It does not modify records once a period is locked. Once a reporting period is submitted, its records are immutable. Corrections happen through a formal restate workflow that produces a new record referencing the old one, with a reason code and an actor. The original record stays visible. This is the pattern the finance world uses for closed accounting periods, and it is the pattern assurance work is built around.
Where we're still working
Scope 3 remains the hardest category to keep clean, and we won't pretend otherwise. Supplier-specific data arrives late and inconsistently. Spend-based Category 1 records carry wide error bars even under the best conditions. Cross-portfolio boundary questions (equity-share versus operational control) rarely have a single obviously right answer for JV structures.
The ledger holds these records the same as any other, tagged with an honest methodology label so spend-based data doesn't get laundered into "activity-based." But we are not going to claim the underlying data quality problem is solved by any software, including ours. What software can solve is the record-keeping. The measurement problem is upstream.
FAQ
Does every extracted invoice become an emission record automatically? No. Extraction produces a proposed record with confidence scores. Records above the confidence threshold commit directly to the ledger; records below it land in a review queue for a human to confirm or correct. The threshold is configurable per project.
Can we edit records after they're on the ledger? Yes, until the period they belong to is locked. After lock, edits go through a restate workflow that creates a new record referencing the old, with a reason code. The original record is preserved and remains visible in the audit trail.
What happens if NGA Factors updates mid-year? Records already on the ledger keep the emission factor version they were calculated with. New records created after the factor update use the new version. Retroactive rebaselining is a separate, deliberate process, not a side effect of the update.
Can we import historical data from a spreadsheet? Yes, through the bulk CSV import path. The same schema applies: activity type, quantity, unit, scope, factor version, source reference. Rows that don't validate are rejected into an error queue rather than silently accepted.
How long are records retained? Seven years from the end of the reporting period they belong to, under our internal retention policy. That is longer than the five years the NGER Act requires. Source documents, actor logs, anomaly flags, and restate history all retain for the same window.
The point of a ledger is that it doesn't rely on your memory. Send an invoice to the project inbox, let the AI Document Engine draft the record, review the confidence flags, and let it commit. Three years later, when an auditor asks where a number came from, the ledger already knows. Email hello@carbonly.ai to see the ledger against a set of your actual invoices. Pricing is per-project from $100 per month.