Your Carbon Numbers Are Wrong If You're Not Tracking Environmental Incidents

A maintenance technician tops up a commercial refrigeration unit with 15 kg of R-410A. The work order gets logged in the facilities management system. The EHS team never sees it. The sustainability team definitely never sees it. And your emissions inventory stays exactly the same — even though that top-up represents a leak of roughly 31 tonnes CO2-e.

That's not a rounding error. For a mid-size commercial building, 31 tonnes might be 20% of total Scope 1 emissions. Gone. Invisible. Not because anyone lied, but because the system that records refrigerant servicing doesn't talk to the system that calculates emissions.

We see this pattern constantly. Environmental incidents — refrigerant leaks, fuel spills, equipment malfunctions, uncontrolled venting — sit in one database. Carbon accounting sits in another. The two never meet. And the result is Scope 1 figures that reflect what was invoiced, not what actually happened.

The Gap Between EHS and Carbon Accounting

At most Australian companies, environmental incident management and emissions reporting are run by different teams using different software. The EHS team tracks incidents for workplace safety and EPA compliance. The sustainability team tracks emissions for NGER and ASRS reporting. The two functions might not even sit in the same building, let alone the same data system.

This separation made some sense when carbon accounting was a voluntary exercise. You pulled your electricity bills, applied NGA emission factors, and produced a Scope 2 number. The utility invoices were the source of truth, and they were good enough.

But Scope 1 fugitive emissions don't arrive on an invoice. Nobody sends you a bill for the R-404A that leaked from your cold storage over six months. You don't get an invoice for the SF6 that seeped from your switchgear. The only way you know about these losses is if someone records the top-up, calculates the loss, and feeds it into your emissions data. That "someone" is usually nobody.

Australia's DCCEEW Cold Hard Facts 4 report (December 2024) estimates 55,000 tonnes of refrigerants sitting in Australian systems — equivalent to 100 million tonnes CO2-e if released. Annual direct emissions from refrigerants run at about 6.9 Mt CO2-e nationally. That's not a small number. And a significant chunk of it goes unreported because the NGER framework only requires refrigerant reporting for systems with a charge above 100 kg and a GWP above 1,000, covering specific ANZSIC codes like food manufacturing, retail, and warehousing. Everything below those thresholds? It just disappears.

The Ecolibrium analysis of Australia's refrigerant reporting gaps put it bluntly: no mandatory leak registers, reliance on estimated rather than measured data, and unreported end-of-life emissions. The framework was designed for large industrial systems. The collective impact of thousands of smaller systems — each leaking 5-15% of charge annually — falls through the cracks.

What Counts as an Emissions-Relevant Incident

Not every environmental incident has carbon implications. A chemical spill in a bunded area might be an EPA notifiable event without generating any greenhouse gas emissions. But more incidents than you'd think do have a direct emissions impact that should show up in your Scope 1 figures.

Refrigerant leaks are the obvious one. R-410A has a GWP of 2,088 under AR5. R-404A — still common in commercial refrigeration — has a GWP of 3,922. A 10 kg leak of R-404A equals 39.2 tonnes CO2-e. For context, that's roughly the same emissions as driving a diesel truck 100,000 kilometres. One leak. One piece of equipment. And unless your maintenance contractor reports the top-up volume and someone translates it into CO2-e, it never touches your emissions inventory.

Fuel spills are Scope 1 losses that rarely get recorded as emissions events. When diesel spills from a ruptured line on a construction site, the EHS team manages the cleanup and EPA notification. But the spilled fuel still has an emission factor — it just wasn't combusted in an engine. Under the GHG Protocol, fugitive losses from fuel handling are Scope 1. In practice, most companies only account for fuel that gets burned, not fuel that gets lost.

Equipment malfunctions causing venting are particularly significant in industrial settings. A pressure relief valve that opens on a natural gas line. An SF6 circuit breaker that develops a slow leak — SF6 has a GWP of 23,500 under AR5, making even tiny losses massive in CO2-e terms. A 2 kg SF6 leak equals 47 tonnes CO2-e. For electricity utilities and large commercial buildings with medium-voltage switchgear, this is a genuine Scope 1 source that rarely gets measured.

Process upsets in manufacturing can cause uncontrolled emissions — flaring events, boiler trips that release uncombusted methane, waste treatment system failures that generate excess CH4 or N2O. These are exactly the kinds of events that should be captured as emissions data points, but they typically live only in the EHS incident log.

Why Invoices Alone Don't Give You Accurate Scope 1

Here's the core problem. Most carbon accounting systems — including many we've evaluated while building ours — treat invoices as the primary data source. Pull in your gas bills, apply the emission factor, done. Pull in your diesel purchases, multiply by 2.7 kg CO2-e per litre, done.

That works well for Scope 2. Your electricity bill is a reliable proxy for electricity consumption. But for Scope 1, invoices only capture inputs. They don't capture losses.

Consider a facility with a diesel storage tank. Over a quarter, they purchase 50,000 litres. Their generator logs show 47,000 litres consumed. The remaining 3,000 litres? Maybe evaporation. Maybe a slow leak at a fitting. Maybe theft. Whatever the cause, 3,000 litres of diesel has a carbon footprint — roughly 8.1 tonnes CO2-e — that sits in neither the "fuel purchased" calculation nor the "fuel consumed" calculation if you're only looking at invoices.

For refrigerants, the problem is worse. There's often no invoice at all. An in-house maintenance team might top up a system from bulk stock without generating a purchase order. Or the HVAC contractor includes refrigerant in a service call that's invoiced as a single line item ("Quarterly maintenance — $1,200") with no indication of how much gas was added. Without an incident record that says "added 8 kg R-410A to Unit 3 on Level 2," you've got no data point to work with.

We're honest about this: no software can detect a leak that nobody records. The data still has to come from somewhere — a maintenance log, a work order, a technician's report. What software can do is make it easy to record the event, automatically calculate the emissions impact, and ensure it flows into the correct scope and category in your inventory.

How Incident Tracking Connects to Emissions Data

When we built the incident tracking module in Carbonly, we designed it specifically to close this gap. Not as an afterthought bolted onto an emissions calculator, but as a connected system where every incident can carry emissions data if it's relevant.

Each incident record captures severity (low, medium, high, critical), status workflow (open, investigating, resolved, closed), location tied to a specific facility, root cause analysis, corrective actions, and financial impact. Those are standard incident management fields. What makes it useful for carbon accounting is the link back to emissions data.

When a user logs a refrigerant top-up as an incident, the system knows the GWP of that refrigerant — R-410A at 2,088, R-404A at 3,922, R-32 at 675 — and calculates the CO2-e impact automatically. That figure flows into the facility's Scope 1 fugitive emissions under the HFC gas category. It shows up on the dashboard. It appears in the NGER report. And it carries a full audit trail: who recorded it, when, what the source document was, what corrective actions were taken.

The same logic applies to fuel incidents, gas venting events, or any emission source tracked under our per-gas breakdown (CO2, CH4, N2O, HFC, PFC, SF6, NF3). The incident is the trigger. The emissions calculation is automatic. The reporting integration is built in.

We should be clear about what this doesn't do. It doesn't detect incidents autonomously. If nobody logs the refrigerant top-up, it's still invisible. The financial impact field is an estimate — you're guessing at cleanup costs or equipment replacement before the bills come in. And not every incident has emissions implications; the system doesn't force an emissions calculation on incidents that don't warrant one. These are real limitations. But the gap between "no data captured at all" and "an estimate with audit trail" is enormous when your auditor comes asking.

The NGER and ASRS Compliance Angle

Under NGER, fugitive emissions are a mandatory reporting category. The Measurement Determination (section 4.102) specifies methods for calculating emissions from refrigerant equipment, using default leakage factors by equipment type. Method 1 requires the cooling type, refrigerant gas type, and gas charge of the plant. Method 2 uses actual measured top-up data — which is exactly what an incident record provides.

Here's the problem most NGER reporters face: Method 1 defaults often understate or overstate actual losses, depending on how well-maintained the equipment is. Method 2 is more accurate but requires you to actually track top-ups and losses systematically. If your HVAC contractor's invoices don't break out refrigerant quantities — and most don't — you're stuck on Method 1 defaults whether they reflect reality or not.

An incident tracking system that captures refrigerant volumes gives you the data for Method 2. That's not a theoretical benefit. The ANAO performance audit found that 72% of NGER reports contained errors, with missing emission sources being a common problem. Fugitive emissions from refrigerants are exactly the kind of source that goes missing when there's no systematic way to capture the data.

Under ASRS (AASB S2), the requirements go further. You need to disclose climate-related risks including physical risks to assets. An environmental incident register isn't just about accurate emissions — it's evidence of how you identify, assess, and manage physical risks. A pattern of refrigerant losses might indicate ageing infrastructure that requires disclosure as a material climate risk. A history of fuel containment failures might trigger transition risk analysis around regulatory tightening.

The incident data serves double duty. It feeds your emissions inventory and it supports your risk disclosure. Most companies treat these as separate exercises. They shouldn't be.

What This Looks Like in Practice

Consider a property manager running 30 commercial buildings across three states. Each building has HVAC systems. Some have backup diesel generators. A few have commercial kitchens with gas equipment. Across the portfolio, there might be 15-20 refrigerant servicing events per year, a handful of fuel delivery incidents, and the occasional equipment failure.

Without connected incident tracking, the sustainability team discovers these events — if they discover them at all — months later when they're chasing data for the annual report. By then, the maintenance contractor's records are incomplete, nobody remembers whether the top-up was 8 kg or 18 kg, and the property manager can't say for certain which refrigerant type was in the system. The Scope 1 figure ends up being either a rough estimate or just... wrong.

With connected tracking, each event gets logged at the time it happens. The facility manager or maintenance contractor records the incident — refrigerant type, quantity, equipment ID, location. The emissions impact calculates immediately. The portfolio-level dashboard updates. When the sustainability team runs the annual report, the fugitive emissions are already there, with source documentation attached.

This isn't theoretical. It's how incident tracking should work. We're not going to pretend we've solved every edge case — connecting legacy EHS systems to carbon platforms is still largely a manual integration exercise for most organisations, and we haven't cracked automatic ingestion from every maintenance management system on the market. But having the incident module live inside the same platform as the emissions engine means at least the internal workflow is connected. The data doesn't have to cross a system boundary.

Our anomaly detection module also plays a role here. If a facility's Scope 1 fugitive emissions suddenly spike — say, a quarter where refrigerant top-ups triple — the system flags it. That flag might reveal an underlying equipment problem that's both an emissions source and a maintenance issue. Without the incident data feeding in, the spike is just a number. With it, there's a root cause attached.

The Honest Gaps

We said we'd be honest about limitations, so here they are.

First, incident data quality depends entirely on people. If your technician doesn't record the refrigerant top-up, or records "some R-410A" instead of "12.5 kg R-410A," the emissions calculation is either missing or wrong. Software can make the recording easy. It can't make people do it.

Second, the financial impact field in any incident record is an estimate at the time of logging. Actual costs emerge over weeks or months. For emissions purposes, the financial impact matters less than the physical quantities — how much refrigerant leaked, how much fuel spilled — but the financial figure is approximate regardless.

Third, not all environmental incidents produce greenhouse gas emissions. A contained chemical spill within a bunded area, a stormwater contamination event, a noise complaint — these are legitimate EHS incidents that don't belong in an emissions calculation. The system needs to accommodate both types without forcing a false carbon number onto every event.

Fourth, integrating existing EHS systems with carbon accounting platforms remains a largely manual exercise. Most companies use standalone incident management tools (SAP EHS, Intelex, Enablon) that weren't designed to feed emissions data into a carbon inventory. We're building API connections where we can, but the honest answer is that for most organisations, someone still has to extract the relevant data from one system and enter it into another. That's not where we want to be long-term. But it's where the industry is right now.

And fifth — some emissions from incidents are genuinely hard to quantify. How much methane escaped during a 45-minute boiler trip? How much diesel evaporated from a surface spill before cleanup? These require engineering estimates, not precise measurements. The numbers are better than zero, but they carry real uncertainty. We'd rather have an approximate figure with a documented methodology than a blank cell that pretends the event didn't happen.

Start With What You Already Know

If your EHS team is already tracking incidents and your sustainability team is already building emissions inventories, you've got both halves of the puzzle. The missing piece is the connection between them.

Start by reviewing your last 12 months of maintenance records for refrigerant top-ups. Calculate the CO2-e impact using the GWP values from the NGA Factors workbook. For most commercial operations, this single exercise reveals Scope 1 fugitive emissions that have been entirely absent from the inventory.

Then set up a process — it doesn't have to be sophisticated — where every refrigerant servicing event, fuel incident, and equipment failure gets assessed for emissions impact before it's closed. Not every incident will have one. But the ones that do need to flow into your carbon data, not disappear into a filing cabinet.

Your emissions numbers should reflect what actually happened at your facilities. Not just what showed up on an invoice.

Related Reading: