The Carbon Audit Trail That Survives Reasonable...

Ask a bookkeeper what an audit trail is and they'll describe a change log. Every save, every edit, who did it, when. That definition is fine for accounts payable. It is not what an ASSA 5010 assurance provider means by audit trail.

Under reasonable assurance the auditor picks a line item, say a diesel record inside a Q3 fuel consumption figure, and walks it backward. From the AASB S2 disclosure number, through the calculation, through the emission factor edition applied, through the material match rationale, through the reviewer who confirmed it, all the way back to the original supplier PDF. Every hop in that walk needs to be traceable, and nothing in the chain can have been silently amended along the way. That is the standard reasonable assurance holds emission records to.

Group 1 companies discovered the difference the hard way in their first assurance cycle. What passed for an audit trail in most platforms was a UI event log covering the last few changes. What the assurance team asked for was seven years of provable chain of custody. We built Carbonly around the second definition, not the first.

What "audit trail" means when the auditor is testing controls

Limited assurance under ASSA 5010 is already live for Group 1 disclosures. Reasonable assurance follows in Year 4. The gap between the two levels is where most carbon numbers fail.

Limited assurance largely tests whether nothing looks obviously wrong. Reasonable assurance tests whether the number is right, which means the assurance team walks the derivation, samples source documents, checks that emission factors match the NGA edition you claimed to use, and verifies that period-end figures reconcile to what was actually submitted. If any link in that chain is fuzzy, the assurance opinion gets qualified or the engagement blows out its budget while your team chases evidence retroactively.

That is the audit trail we designed for. Not a UI event log. A defensible chain of custody where every emission record on the ledger can be walked backward without gaps.

What Carbonly persists on every emission event

Every event that changes the emission ledger gets recorded with a typed event kind. There are 27 distinct kinds today, covering emission record creation and amendment, factor library updates, material additions, supplier extraction template versioning, calculation rule changes, period lock and submit transitions, JV consolidation events, and organisation-level configuration changes.

Each audit event carries the actor (a named human user with their role at the time of the event, or the identity of the AI agent that took the action), a server-side monotonic timestamp so events cannot be reordered by clock drift, the organisation and project scope, and a structured payload capturing the before and after values of whatever changed.

Every event also carries a content hash, a fingerprint of the payload computed at write time. If anyone tries to silently alter a stored event later, the fingerprint stops matching and the tampering is visible on inspection. That fingerprint is the primary defence against the assurance question "how do I know this record has not been amended since submission".

Emission factor version pinning matters more than most teams realise

The NGA Factors workbook is republished each year. The 2024 edition, 2025 edition, and 2026 edition contain slightly different values for the same activity. Different state grid factors. Different Scope 3 uplifts. Different per-litre fuel factors. Different biogenic content assumptions on stationary energy.

Silent factor updates are one of the most common causes of an assurance walk-through breaking. The platform quietly refreshed the electricity factor for NSW mid-year from the 2024 edition (0.66 kg CO2-e/kWh) to the 2025 edition (0.64 kg CO2-e/kWh), the historical emission records got recalculated on the fly, and now the number the auditor is trying to reconcile against a document from March does not match the number in the report from September.

Carbonly pins the exact NGA edition applied to each emission record on the record itself. Every kilowatt-hour, every litre of diesel, every gigajoule of gas carries the factor version it was calculated under. Update the library to a new edition and historical records stay pinned. When the assurance team asks "which factor edition did you apply to this Q3 diesel line", the answer is one click.

That pinning matters for another reason. NGER continues to use AR5 global warming potential values, while AASB S2 has moved to AR6. Silent factor updates would silently misstate one of the two reports. Explicit versioning is the only way to run both frameworks off the same underlying activity data without one framework quietly overwriting the other. We covered the specific methane and nitrous oxide implications in a separate deep dive on AR5 versus AR6 GWP.

The same versioning discipline applies to custom emission factors uploaded to a workspace. If your carbon lead uploads a supplier-specific EPD factor and later updates it, both versions stay retrievable and every historical emission derived under the old version links back to the old version, not the current one.

Calculation rules also carry versions

The emission factor is only half the derivation. The other half is the calculation rule that converts an odometer reading, a meter reading, or a docket quantity into an emission figure.

Carbonly's calculation rules and custom formulas are versioned the same way factors are. Update the odometer-reading delta formula for the fleet fuel model and the version bumps. Every emission derived under the previous formula stays linked to the previous formula version. The old version stays retrievable in the calculation library, not just in git history. Reasonable assurance walks the derivation, not just the output, and if the assurance team cannot see the exact formula that produced a figure at the time it was produced, the walk breaks.

Supplier extraction templates get the same treatment

When we designed the ingestion flow, the pattern we kept seeing across construction, food and beverage, and property portfolios was suppliers changing their invoice layout mid-year without warning. A Boral concrete docket suddenly gains a new field. An Ampol fuel invoice moves the tax code column. An AGL electricity bill splits network charges out from energy charges.

Every per-supplier extraction template in Carbonly is versioned. When the AI document engine sees five consecutive samples that drift from the current template shape, the Data Health Agent flags the drift and the Trust Graduation Agent drafts a new template version for the carbon lead to confirm. The old version stays live for all historical documents. When the auditor asks "how did you extract the tonnage from this docket dated March, given that the layout changed in July", the platform can point to the March-vintage template version and show the extraction event.

That is the difference between an extraction system built for reporting and an extraction system built for assurance.

Period locking, submit, and the restatement register

Reporting periods in Carbonly have four states: open, locked, submitted, and archived.

Open means new documents can still be ingested into the period and new emission records can still be created. Locked freezes the ledger against new writes inside the period window. Any late-arriving invoice for that period surfaces as an exception the carbon lead must consciously handle, not a silent backdated record.

Submitting captures the framework (NGER, AASB S2, Safeguard Mechanism, an internal Board reference, or a Climate Active baseline the team is preparing) and an optional submission reference number. From that point the ledger for the period is frozen and any change requires a restatement.

Restating requires written justification. Not a UI checkbox. Not a comment field. A structured justification that becomes part of the restatement register, itself a first-class object with its own audit trail. Under the NGER Determination retention requirements the restatement register is exactly the kind of evidence the Clean Energy Regulator will ask for if a report gets picked up for follow-up review.

The Beach Energy enforceable undertaking from July 2025 turned on data quality and the ability to reconstruct what was reported and why. Teams without a restatement register end up rebuilding that history from Slack threads and email chains. Teams with one hand the auditor a document.

Baseline snapshots for the AASB S2 comparative

AASB S2 paragraph 21 requires comparative disclosure of the prior year. That means the FY24 Scope 2 figure has to appear alongside the FY25 Scope 2 figure in the FY25 report, and it has to be the FY24 figure as understood at the time it was submitted, not the current-day recalculation of FY24 after any restatement.

Carbonly captures baseline snapshots at period submit time. The snapshot is immutable. When the auditor asks "what was your Scope 2 for FY24 the day you submitted, before any restatement", the snapshot is the answer. When a restatement subsequently updates the FY24 figure, both the original snapshot and the restated figure are retained, and the comparative disclosure shows both with the restatement flagged.

Without immutable baseline snapshots the comparative disclosure becomes a rolling recalculation, and rolling recalculations do not survive reasonable assurance testing.

Seven-year retention, and why every element matters

The NGER Determination requires records to be kept for five years from the end of the reporting year they relate to. In practice, ASRS Group 1 assurance conversations, ACCC investigations, and Clean Energy Regulator follow-ups routinely reach back further than five years, especially where a baseline year sits in the middle of a target trajectory. Carbonly retains every audit event, every source document, every factor version, every calculation version, every emission ledger row for a minimum of seven years by default. Sectors with stricter obligations (financial services, resources) can extend that.

Retention alone is not enough. The retention needs to preserve the same chain of custody the live system enforces. That means seven-year retention of:

Every audit event with its content fingerprint
Every version of every emission factor with its edition and effective dates
Every version of every calculation rule with its formula body
Every version of every supplier extraction template with the layout snapshot it was trained on
Every source document uploaded (PDF, CSV, Excel, Word, PowerPoint, RTF, image, or scanned document across the eight supported file formats) with its content hash
Every emission ledger row with pointers back to all of the above

If any of those elements is dropped from retention, the chain breaks in the years the auditor will actually test.

Content fingerprints on every source document

Every uploaded document, and every attachment ingested through the per-project email address or the OneDrive and SharePoint folder sync, has a content hash computed at upload time.

That fingerprint solves three problems at once. Duplicate uploads are recognised (the same fuel docket submitted twice does not create two emission records). Amended documents are detectable (an invoice re-issued with a corrected tax code produces a different fingerprint, and the audit trail captures both versions with the reason for the amendment). Document integrity testing during assurance becomes trivial (the auditor picks a sample document from the Evidence Pack, computes the hash, and confirms it matches what the platform recorded).

The 5-tier material matching system that assigns an activity type to each extracted line carries a match provenance badge with eight distinct states, so the auditor can see whether a match came from exact NGA library match, per-supplier learning, workspace override, AI reasoning at high confidence, AI reasoning at low confidence needing review, or one of the other pathways. The learning velocity metric tracks how often each supplier's invoices are hitting exact match versus AI reasoning over time, which is the leading indicator the assurance team will look for when testing data quality controls.

Auditor Workspace and the Evidence Pack

The last mile of the audit trail is the export, and this is where most platforms fall over. A live web UI is not what an external assurance team wants to work in. They want to sample records, cross-reference them against source documents, and hand over their working papers in a format that survives the file server for the seven-year retention period.

The Auditor Workspace is a dedicated read-only view that the external assurance team signs into. They can step through any reporting period, see lock and submit state, filter emission records by scope, project, facility, or activity type, and inspect the full audit event chain for any individual record. The workspace exists separately from operational access, so nothing an auditor does can affect the live ledger.

From the Auditor Workspace, the Evidence Pack is a one-click ZIP export bundling every emission ledger row with its source document, extraction event, reviewer confirmation, factor version, calculation version, and audit event chain. Built for ASSA 5010 limited assurance and reasonable assurance under ISAE 3410. That is the "export format for external assurance" answer, and it is what compresses the assurance conversation from weeks into days.

For NGER submissions the same export logic drives the NGER evidence pack, so the Clean Energy Regulator and an external assurance team are looking at the same underlying chain of custody with different framings on top.

What this saves the sustainability team

Group 1 companies going through their second year of assurance have reported that internal walk-through evidence preparation, on top of the assurance fee itself, consumed 40 to 60 hours of the sustainability team's time. That figure is not the assurance work. It is the internal work of finding the March PDF, confirming which factor edition was used, tracking down the reviewer who signed off in June, and reconstructing what "final" meant on submission day.

The audit trail architecture is what compresses that number back down. Not by making the assurance conversation shorter, but by making the walk-through samples immediately answerable from the platform rather than from a shared drive.

The common audit failure modes all trace back to the same root cause: the platform in use was designed to produce a report, not to defend a report.

Practical starting point

Pick one facility. Pull three emission records at random from your current Q4 ledger. Try to trace each one back to source in under a minute. Factor edition, calculation formula, reviewer, source document.

If you can do all three in under three minutes total, your audit trail is at the level reasonable assurance will accept. If you cannot, that is the first place the assurance conversation is going to break, and it is worth solving before the auditor arrives rather than after.

Carbonly workspaces start at $100 per month with per-project pricing across Small, Medium, Large, and Enterprise tiers. If a walk-through demo of the audit trail against your own three sample records would be useful, hello@carbonly.ai is the address.

The Carbon Audit Trail That Survives Reasonable Assurance