When Your Emission Factor Database Updates Itself

Queensland's Scope 2 electricity emission factor dropped from 0.71 to 0.67 kg CO2-e/kWh between the 2024 and 2025 editions of the NGA Factors workbook. That's a 5.6% decrease. For a property portfolio consuming 8 million kWh across Queensland sites in a reporting year, the difference between last year's factor and this year's is 320 tonnes of CO2-e.

If you submitted your NGER report using 0.71, you overstated. If that number also fed into your AASB S2 climate disclosure (which it now does for Group 2 entities reporting from July 2026), you overstated there too. And the fun part: nobody told you the factor changed. You had to notice.

That's the problem we're going to talk about. Not how to calculate emissions. How to make sure the numbers feeding your calculations are actually current.

The Annual Factor Shuffle

DCCEEW publishes the National Greenhouse Accounts Factors workbook once a year. It's an Excel file. You download it from the DCCEEW website, open it, and compare it against whatever you used last year. Table by table. Cell by cell.

The 2025 edition (which applies to 2025-26 NGER reports submitted by 31 October 2026) didn't just tweak electricity factors. The NGER (Measurement) Amendment (2025 Update) Determination introduced market-based reporting for biomethane and hydrogen consumption, updated flared gas emission factors for oil and gas operations under Methods 1 and 2A, expanded Method 2B access to natural gas transmission and distribution facilities, and revised the N2O factor for estuarine effluent discharge in the waste sector.

That's a lot of changes buried in a single annual update.

And here's the bit that makes factor management genuinely hard: these aren't always annual. Legislative amendments can land mid-cycle. The 2025 public consultation (which ran from 28 February to 11 April 2025) proposed changes to co-processed fuel reporting, the REGO scheme integration for renewable electricity certificates, and sampling standards for open-cut coal mine fugitive emissions. Some of those flow through to factor updates. Some don't. Knowing the difference requires reading the actual determination text, not just scanning the workbook.

We've spent nearly two decades building data systems for mining and energy companies. The emission factor update problem is a data versioning problem. And most carbon accounting setups don't treat it that way.

What Happens When You Use Last Year's Numbers

Let's work through a concrete example. Say you manage emissions reporting for a company with operations in three states: 15 sites across Victoria, Queensland, and NSW. Your total grid electricity consumption across the portfolio is 12 million kWh, split roughly 40% Victoria, 35% Queensland, and 25% NSW.

Using the NGA Factors 2024 edition:

• Victoria: 4,800,000 kWh x 0.77 = 3,696 tonnes CO2-e
• Queensland: 4,200,000 kWh x 0.71 = 2,982 tonnes CO2-e
• NSW: 3,000,000 kWh x 0.66 = 1,980 tonnes CO2-e
• Total Scope 2: 8,658 tonnes CO2-e

Now the same consumption with the NGA Factors 2025 edition:

• Victoria: 4,800,000 kWh x 0.78 = 3,744 tonnes CO2-e
• Queensland: 4,200,000 kWh x 0.67 = 2,814 tonnes CO2-e
• NSW: 3,000,000 kWh x 0.64 = 1,920 tonnes CO2-e
• Total Scope 2: 8,478 tonnes CO2-e

The net difference is 180 tonnes. A 2.1% decrease overall. But look at the state-level movements. Victoria went up. Queensland went down significantly. NSW went down. The overall number masks movements in opposite directions.

For NGER reporting, you must use the factors from the edition that matches your reporting year. Full stop. The Clean Energy Regulator's compliance team has specifically called out stale emission factors as a common audit finding. For AASB S2 disclosures, you need to use factors that "best represent the entity's activity," and if you've changed the way you measure emissions from one period to the next, you may need to adjust your comparative information under the transitional requirements.

Using the wrong edition isn't just inaccurate. It's a compliance problem on two fronts simultaneously.

The Manual Update Process (and Why It Breaks)

Here's what the emission factor update process looks like at most organisations we talk to.

Sometime between July and September, someone on the sustainability team remembers that the new NGA Factors workbook should be out. They check the DCCEEW website. Maybe they download it immediately. Maybe they bookmark it and come back in October when the NGER deadline is breathing down their neck.

Then they open the new workbook. They open last year's workbook. They compare Table 1 for electricity factors. Table 2 for natural gas. They check the transport fuels tables. They look for any new materials or methods. They update their spreadsheet or system with the new numbers.

If they're thorough, this takes a day or two. If they have 50+ emission factors in use across multiple fuel types, states, and calculation methods, it takes longer. If they're also tracking Scope 3 factors from non-NGA sources (like supplier-specific EPDs or industry databases), the comparison exercise multiplies.

And that's the happy path. The failure modes are predictable. Someone copies last year's template without checking whether factors changed. A new analyst doesn't know the workbook exists. The update gets partially applied (electricity factors are updated, but natural gas factors aren't because they sit in a different tab). A mid-year legislative amendment changes something, and nobody catches it until the auditor asks for the source reference.

We're not guessing about these failure modes. The ANAO's performance audit found that 72% of NGER reports contained errors. Stale or incorrect emission factors are one of the recurring categories. When we built Carbonly, we decided to treat factor management as an engineering problem, not a calendar reminder.

The Versioning Problem Nobody Talks About

Here's where it gets genuinely tricky, and where most spreadsheet-based approaches completely fall apart.

When a new NGA Factors edition comes out, you need the new factors for new calculations going forward. But you absolutely cannot retroactively change historical calculations. If you reported 3,696 tonnes of Scope 2 emissions for your Victorian operations last year using a factor of 0.77, that number stays. It was correct at the time, calculated with the factor that was in effect for that reporting period.

This is emission factor versioning. And it's a requirement, not a nice-to-have. Under NGER, each reporting year has a specific edition of the Measurement Determination (and corresponding NGA Factors) that applies. Under AASB S2, if you change your measurement approach (including switching to updated factors), you need to consider whether comparative period adjustments are required.

In a spreadsheet, versioning is nearly impossible to do well. You either overwrite cells (destroying the audit trail) or maintain parallel sheets for each reporting year (creating a maintenance nightmare). We've seen organisations with seven tabs of "factor lookups" in a single workbook, one per year, with VLOOKUP formulas that reference the wrong tab because someone forgot to update the year parameter. Silent. Invisible. Wrong.

What you actually need is a system where every emission factor has a lifecycle. An effective date and an end date. A state: active, superseded, or deprecated. When the 2025 edition replaces the 2024 edition, the 2024 factors don't disappear. They get marked as superseded with a clear end date. Any calculation that falls within the 2024 reporting period still references the 2024 factor. Any new calculation for the 2025 period picks up the 2025 factor automatically.

This is how Carbonly handles it. Every factor in our library carries a version, an applicable period, a source reference (down to the specific table and row in the NGA workbook), and a lifecycle state. When we update factors, old calculations don't change. New calculations use the current factor. And you can run a temporal query: "show me the factor that was in effect for Victorian grid electricity on 15 March 2025." That kind of traceability is what auditors actually want to see.

What "Self-Updating" Actually Means

We should be honest about what's realistic here and what's marketing fluff.

No carbon accounting system should silently update your emission factors and recalculate everything without telling you. That's not automation. That's a compliance risk dressed up as a feature. You need to know what changed, why, and what the impact is before anything gets applied.

What should happen is this: the system detects that a new edition of the NGA Factors workbook has been published. It compares the new factors against the ones currently in your library. It identifies which of your active factors are affected. It calculates the impact across your open records, the ones that haven't been submitted yet and fall within the new edition's applicable period. And then it tells you.

Something like: "14 of your emission factors have updated values in the 2026 NGA Factors edition. 9 are electricity factors. 3 are natural gas. 2 are transport fuels. Net impact on your current-period Scope 1: +1.4%. Net impact on Scope 2: -2.1%. Review and apply?"

You decide. Not the system. The system does the comparison work that used to take your team a day. You make the judgment call in five minutes.

We're still working out the best approach for non-NGA factor sources. The NGA workbook is structured and predictable enough to monitor systematically. But Scope 3 factors from industry databases, EPDs, and supplier-specific data come in dozens of formats from dozens of sources. Detecting and reconciling those updates automatically is a harder problem, and we won't pretend we've solved it completely.

Why This Matters More Now Than It Did Two Years Ago

Before ASRS, emission factor accuracy was mostly an NGER concern. Get your factors wrong, and you might get a letter from the Clean Energy Regulator. Possibly an enforceable undertaking if the errors were persistent and material (ask the entities that received undertakings in 2025 about how that feels).

But now, for Group 1 entities already reporting and Group 2 entities starting from July 2026, the same emission factors feed into climate-related financial disclosures under AASB S2. Those disclosures sit in your annual report. They're subject to limited assurance under ASSA 5010, escalating to reasonable assurance over time. Your assurance provider will want to see not just the factors you used, but the source, the version, and evidence that they were current for the applicable period.

The gap between "we downloaded the NGA workbook" and "we can demonstrate version-controlled factor management with temporal traceability" is the gap between passing and failing an assurance engagement.

For companies reporting under both NGER and AASB S2, there's an additional wrinkle. NGER uses AR5 global warming potential values (from the IPCC's Fifth Assessment Report). AASB S2 requires AR6 values. The same greenhouse gas, measured using different GWP conversion factors, produces different CO2-equivalent figures depending on which framework you're reporting under. Your factor management system needs to handle both simultaneously, applying the right GWP values to the right report without mixing them up.

If that sounds fiddly, it is. But it's the kind of fiddly that software should handle and humans shouldn't have to think about every time they run a calculation.

What Good Factor Management Looks Like

After building emission calculation engines for two years and spending eighteen years before that inside enterprise data platforms at mining and resource companies, we've landed on a few principles that we think are non-negotiable for emission factor management.

First, factors need metadata. Not just the number. The source (NGA Factors 2025, Table 1, Row 3). The applicable period (1 July 2025 to 30 June 2026). The GWP basis (AR5 or AR6). The geographic scope (state-level, not national average). The unit (kg CO2-e per kWh, per GJ, per litre, per tonne). Without this metadata, you can't audit a calculation. You can't explain to an assurance provider why you used 0.78 instead of 0.77.

Second, superseded factors must be preserved, not deleted. Every calculation should be permanently linked to the factor version that was in effect when the calculation was performed. If an auditor asks "what factor did you use for Queensland electricity in Q2 2025?", the answer should be instant and traceable, not "let me check which version of the spreadsheet we were using."

Third, impact analysis before application. When new factors arrive, the system should show you the delta across all affected records before you approve the update. This is where you catch surprises, like Queensland dropping 5.6% while Victoria went up, before they land in your report.

And fourth, dual-framework support. If you're reporting under both NGER and AASB S2 (and increasingly, most NGER reporters will be), you need the same underlying activity data calculated with the correct factor set for each framework. One source of truth for consumption data. Two parallel calculation paths. No manual reconciliation.

The Bottom Line

The NGA Factors workbook is a spreadsheet that DCCEEW publishes once a year. It changes every time. The 2025 edition updated electricity factors across most states, introduced hydrogen as a fuel, revised flared gas calculation methods, and modified wastewater emission factors. The 2026 edition will change things again.

Your emission factors are not static reference data. They're versioned, time-bound, framework-specific inputs that directly determine whether your NGER report and AASB S2 disclosure are accurate or not.

If your current process for handling factor updates involves someone remembering to check a government website, you've got a single point of failure sitting between you and compliance. We built Carbonly's factor library to remove that single point of failure. If you want to see how emission factor versioning works in practice, reach out at hello@carbonly.ai.