Emission Factor Versioning: The Audit Trail Nobody Thinks About Until It's Too Late

Here's a question that will ruin your week: which edition of the NGA Factors workbook did you use to calculate your Scope 2 emissions for Q3 2024?

Not "what factor did you use." That's the easy part — 0.78 for Victoria, 0.64 for NSW, you probably remember. The harder question is which version of that factor. Was it from the 2024 edition (which used 0.77 for Victoria) or the 2025 edition (which bumped it to 0.78)? And can you prove it?

If you're reporting under NGER, the Clean Energy Regulator requires you to keep records for five years from the end of each reporting year. That means your 2021-22 calculations need to be traceable until at least June 2028. Not just the final number — the method, the factor, and the reasoning for selecting it. When Beach Energy copped an enforceable undertaking in July 2025 for "inadvertent misstatements" across multiple NGER reporting periods, the CER didn't just flag the wrong numbers. They flagged the absence of internal controls that would have caught those errors in the first place.

Most carbon accounting tools treat emission factors like a static lookup table. Pick a factor, multiply, move on. But factors aren't static. The NGA Factors workbook gets updated every year by DCCEEW. Electricity grid factors shift as the generation mix changes. Methodology changes land — like the discontinuation of three-year averaging in September 2024. And if your system doesn't track which version of which factor was applied to which calculation, you don't have an audit trail. You have a snapshot that can't be verified.

Factors move more than most people realise

The year-on-year changes in Australian electricity emission factors aren't trivial. Between the 2024 and 2025 editions of the NGA Factors workbook, Victoria went from 0.77 to 0.78 kg CO2-e per kWh. NSW dropped from 0.66 to 0.64. Queensland fell from 0.71 to 0.67. Tasmania climbed from 0.15 to 0.20.

Tasmania's jump is the one that should get your attention. A property manager with 10 sites in Hobart consuming 500,000 kWh each would see their reported Scope 2 emissions increase by 33% — from 750 tonnes to 1,000 tonnes — purely from the factor update. Nothing changed operationally. Same buildings. Same energy use. But if you recalculated your prior-year baseline using the new factor, you'd be comparing apples to oranges and your reduction target would be meaningless.

And those are just the electricity factors. The 2025 NGA update also added Scope 1 emission factors for hydrogen combustion. Updated flared gas factors for oil and gas operations. Changed market-based reporting rules for biomethane. Every one of those changes creates a version boundary. Every version boundary creates an audit risk if you can't trace which factor applied when.

This is before we even get to the AR5 versus AR6 GWP problem. NGER currently uses AR5 global warming potential values (methane = 28). AASB S2 references AR6 (methane = 27.9 for fossil, but 27.0 for biogenic with new categorisation). If you're reporting under both schemes — and most NGER reporters will be, since they're automatically pulled into ASRS Group 2 — you may need the same activity data calculated twice with different GWP baselines. Without factor versioning, good luck explaining that to an auditor.

What factor versioning actually looks like in practice

When we built Carbonly's emission factor system, we borrowed a concept from software engineering: semantic versioning. Every emission factor in the system carries a version number — 1.0.0, 1.1.0, 2.0.0 — and moves through a defined lifecycle: draft, active, superseded, deprecated.

That lifecycle matters. When DCCEEW publishes the 2026 edition of the NGA Factors, the 2025 factors don't vanish. They move to "superseded" status. Every historical calculation that used the 2025 factor retains its link to version 1.0.0 of that factor. The new factor gets loaded as version 2.0.0 and becomes "active" for new calculations going forward.

This is the distinction that most tools miss. A typical carbon accounting spreadsheet — and yes, we still see plenty of those, as we've written about before — has a column for "emission factor" with a number in it. When the new NGA edition arrives, someone overwrites that number. The old value is gone. Silently. No record of what it was, when it changed, or who changed it. The ANAO's performance audit of NGER found that 72% of 545 reports examined contained errors. We'd bet a good portion trace back to exactly this kind of invisible factor swap.

Our system tracks five types of changes against each factor version: value updates (the number itself changed), methodology changes (how the factor was derived changed), source updates (a new edition of the NGA workbook), corrections (an error was found and fixed), and regulatory updates (a legislative amendment changed the requirement). Each change type carries different implications for whether historical calculations need review.

A value update to a current-year factor? Straightforward — recalculate affected records. A methodology change to a prior-year factor, like the three-year averaging discontinuation? That's more nuanced. You don't retroactively change 2023-24 calculations because they were correctly calculated under the rules that applied at the time. You need both versions to coexist in the system. This is exactly what "superseded" status is for.

The temporal query problem

Here's where it gets genuinely hard, and where we had to think carefully about architecture.

An auditor reviewing your 2024-25 NGER report in January 2027 asks: "Show me the emission factor that was in effect for this Victorian electricity bill dated March 2025." Your system needs to answer that question without ambiguity. Not "here's the current factor" — here's the factor that was valid at that date, according to the edition of the NGA workbook that applied to the 2024-25 reporting year.

We built a temporal query function — getFactorAsOfDate — that returns exactly this. Give it a date, and it returns the factor version that was active at that point in time. It works by checking the effective dates of each factor version and returning the one whose active window contains the query date. For the 139+ verified Australian emission factors pre-loaded from the NGA Factors 2025 workbook, this is straightforward. For factors that have been through multiple version transitions, the query walks the version chain backwards.

This sounds simple. It's not. Time zones matter (Australian reporting uses AEST/AEDT, not UTC). Factors have effective dates tied to reporting years, not calendar dates — the 2025 NGA edition applies to the 2025-26 NGER reporting year starting 1 July 2025, not from the date DCCEEW published the workbook. And some factors change mid-year through legislative amendments, which the CER tracks separately.

The temporal query gives us something else that turns out to be surprisingly useful: change impact analysis. When a new factor version is loaded, the system can automatically calculate the total tCO2-e delta across all historical records that used the previous version. This isn't about changing those records — they stay linked to the factor version that was correct at the time. It's about quantifying the magnitude of the change. A sustainability manager can see at a glance: "If this factor had applied to last year's data, our Scope 2 total would have been 3.2% higher." That context matters for target setting, for board reporting, and for understanding whether an apparent emissions reduction is real operational improvement or just a factor shift.

Why this matters more now than it did three years ago

Before ASRS, emission factor versioning was a nice-to-have. NGER reporters needed to get the right number into their report by 31 October. Once submitted, nobody was going back to check which factor version was used for bill number 847 out of 2,000.

That's changing. AASB S2 paragraph 29 requires entities to disclose their greenhouse gas emissions and to use "the emission factors that best represent the entity's activity." Under ASSA 5010, assurance practitioners need to verify not just that the number is right, but that the methodology is right — including factor selection. Starting from Year 1, Scope 1 and 2 emissions disclosures face limited assurance. By Year 4 (financial years from 1 July 2030), it's reasonable assurance — positive confirmation that the numbers are correct, with 80-90% evidence testing.

That means an auditor won't just check your total. They'll sample individual calculations, trace each one back to its source document, and verify that the correct emission factor was applied. If your system can't show the factor version, its source (NGA Factors 2025, Table 1), its effective date range, and the change history that led to that version being active — you're going to spend a lot of billable hours explaining yourself.

The CER's record-keeping guidance is explicit: organisations must retain records of "the methods and measurement criteria used for estimating emissions and energy and the reason why they were selected." Factor versioning isn't a feature request. It's a compliance requirement dressed up as a data management problem.

The honest limitations

We should be straight about what factor versioning can and can't do.

Temporal queries work for factors that are in the system. If you calculated emissions in a spreadsheet for two years before migrating to Carbonly — or any platform — those historical calculations don't retroactively gain version tracking. You can load the historical factors and link them manually, but the system can't verify what was actually used in a calculation it didn't perform. Migration is a real gap, and we're honest about it.

Custom emission factors still need manual entry. If you're using facility-specific factors — common in oil and gas, where actual gas composition differs from NGA defaults — you're responsible for entering those factors, assigning them version numbers, and recording the source. The system provides the versioning infrastructure, but it can't auto-generate a factor from a lab report. Yet.

And here's the big one: the system doesn't auto-update factors when DCCEEW publishes a new NGA edition. Someone on your team needs to load the new factors, verify them against the published workbook, and activate them. We pre-load the 139+ NGA factors and maintain them as a base set, but we won't silently change a factor that's being used in live calculations without human verification. The risk of an automated update introducing an error into an active reporting period is worse than the inconvenience of a manual review step. DCCEEW publishes updates on varying schedules — the 2024 edition dropped in September 2024 with a methodology change that discontinued three-year averaging. If we'd auto-applied that without flagging it, every open calculation in the system would have shifted.

We're also still working through the AR5/AR6 dual-reporting challenge. For entities that need to report the same emissions under both NGER (AR5 GWP) and ASRS (AR6 GWP), the cleanest approach is maintaining parallel factor sets — one tagged NGER, one tagged ASRS — with different GWP multipliers. It works, but it's not elegant, and we're not sure it scales well for organisations with hundreds of distinct emission sources.

The state-factor geography trap

One versioning scenario we see repeatedly deserves its own callout because it catches experienced teams. A company has 30 sites across three states. Their spreadsheet uses the national average electricity factor (0.62 kg CO2-e/kWh) for everything. When they migrate to proper state-based factors, their Victorian sites jump 26% (0.62 to 0.78) and their South Australian sites drop 65% (0.62 to 0.22). The total might not change much, but the site-level numbers are dramatically different.

Without factor versioning, this looks like Victoria's emissions suddenly spiked and SA's plummeted. With versioning, the system records that all prior calculations used version 1.0.0 (national average) and new calculations use version 2.0.0 (state-based). The change type is logged as "methodology_change" — not a value update but a fundamental shift in how the factor was selected. Anyone reviewing the data can see exactly when and why the numbers changed.

This matters for reduction targets. If your 2023-24 baseline was calculated using national average factors and your 2025-26 actuals use state-based factors, any comparison between them is meaningless. Factor versioning makes that mismatch visible instead of burying it in a number that looks like operational improvement.

What to do about it

If you can answer "yes" to three questions, you're probably fine. If not, you've got work to do before your next NGER submission or your first ASRS assurance engagement.

Can you identify which specific edition of the NGA Factors workbook was used for each emission calculation in your 2024-25 reporting? Can you show an auditor the factor value, its source, and the date it was applied — not just for your total, but for any individual bill they might sample? And if a factor changed between editions, can you quantify the impact of that change on your reported totals without recalculating everything from scratch?

If any of those answers is "no," you don't have an audit trail. You have a number in a cell. And when assurance requirements tighten under ASRS — which they will, every single year through 2030 — that number in a cell won't be enough.

Related Reading: