Automated Emissions Data Collection: What It Actually Means (and What It Doesn't)

A construction company we're working with handed us a box problem last year. Not a metaphorical box. An actual problem involving boxes of fuel receipts — 10,000 of them, from one quarter. Their sustainability manager had been manually entering each docket into a spreadsheet. At two minutes per receipt, that's 333 hours. Eight and a half working weeks of a qualified professional reading smudged thermal paper and typing litres into cells.

That person wasn't doing carbon accounting. They were doing data entry. And they were doing it badly — not through any fault of their own, but because humans make transcription errors at a rate of 1-4% under ideal conditions (according to a 2016 JAMIA study of 6,930 entries). Utility bills and fuel dockets are not ideal conditions.

Automated emissions data collection exists to kill this problem. But the phrase gets thrown around so loosely that it's lost meaning. Every carbon accounting vendor claims automation. Most of them mean you still type numbers into a form — they just made the form prettier.

The 86% Spreadsheet Problem

An SAP survey found that 86% of mid-market executives still track emissions in spreadsheets. The GHG Protocol puts it differently: 83% of companies reporting climate disclosures struggle to even access their emissions data. Both stats point at the same bottleneck.

Data collection isn't 10% of the carbon accounting job. It's 60-70% of it. A BCG and CO2 AI survey found sustainability teams spend the majority of their time gathering and cleaning data, not analysing it or building reduction strategies. For Australian companies facing NGER reporting deadlines on 31 October and ASRS Group 2 obligations from July 2026, that time ratio is a serious problem. You can't compress the analysis and assurance preparation into whatever's left after data entry.

And here's what makes this specifically dangerous for regulated reporters: the ANAO found that 72% of the 545 NGER reports it audited contained errors, with 17% including significant errors. The most common issues? Gaps in own-use electricity, missing sources, and facility aggregate mistakes. These are data collection failures, not calculation failures. The maths was often fine. The inputs were wrong.

Beach Energy learned this the hard way. In July 2025, the Clean Energy Regulator accepted an enforceable undertaking after Beach "inadvertently misstated components of its NGER reports" across multiple years. They're now paying for three years of mandatory reasonable assurance audits — at their own cost — plus an external consultant to rebuild their data collection systems entirely.

What "Automated" Actually Means — Three Channels

When we say Carbonly automates 70-80% of emissions data collection, we mean something specific. We mean documents arrive without someone manually entering them, get processed without someone reading them, and produce emission calculations without someone looking up factors in a spreadsheet. The remaining 20-30% needs human review — anomalies, low-confidence extractions, documents too damaged to read reliably.

That's an honest number. Anyone claiming 100% automation is either lying or hasn't processed enough documents to hit the messy edge cases.

The three channels work differently depending on how your organisation actually handles documents.

Document upload handles the bulk case. You drag and drop files — PDFs, CSVs, Excel workbooks, Word documents, PowerPoint presentations, RTF files, or photographs. Eight formats in total. The system processes them all without needing different templates for different retailers. A batch of 200 electricity bills from six different energy retailers goes in. Structured emissions data comes out. We've tested this at 10,000+ records in a single batch.

OneDrive and SharePoint sync is for organisations that already have a document management system. Point Carbonly at a folder and new documents get picked up automatically. Your accounts team saves an Origin gas invoice to the shared drive — it flows into the emissions pipeline without anyone forwarding emails or uploading files. This matters for companies with 30+ sites where utility bills arrive from multiple sources and land in different places.

Email ingestion is the one that surprised us by how much people wanted it. Each project in Carbonly gets a dedicated email address. Forward your utility bills to that address (or set up an auto-forward rule from your accounts inbox), and they enter the pipeline. No login required. No file management. We built it because a property manager told us their biggest bottleneck wasn't processing bills — it was getting site managers to actually send them in. A forwarding rule solved it.

None of these channels require someone to pre-sort documents by type, site, or scope. The AI pipeline handles classification. Send everything to one place and let the system figure out what it's looking at.

The 7-Phase Pipeline: What Happens After Documents Arrive

We've written a detailed technical walkthrough of our pipeline elsewhere, but here's the version that matters for understanding what "automated" means at each step.

Phase 1 — Classification. The system determines what kind of document it's dealing with. Electricity bill, gas invoice, water statement, fuel receipt, waste manifest. This isn't trivial. A document labelled "Energy Statement" could be electricity or gas. The classifier looks at units (kWh vs MJ vs cubic metres), retailer formatting, and charge structures. It's been trained on documents from 40+ Australian energy retailers and utilities. Get this wrong and every downstream calculation uses the wrong emission factor category.

Phase 2 — Vision-to-Text extraction. A multimodal AI model reads the document image — not through template matching, but by understanding the page layout the way a person would. It doesn't care that AGL's bill format changed last quarter. It reads the content, not the coordinates. This is what separates LLM-based extraction from traditional OCR. We don't maintain templates for each retailer. We don't break when someone uploads a format we haven't seen.

Phase 3 — Structured data extraction. The raw reading gets narrowed to the fields that actually matter: consumption quantity, unit of measurement, billing period dates, meter number or NMI, site address, supplier name, and whether the reading is actual or estimated. Each field gets a confidence score and a reference back to where in the source document it was found.

Phase 4 — Validation. This is where most tools stop. They extract data and call it done. We don't, because extraction without validation is just faster data entry with the same error rate. The validation agent checks whether 2,450,000 kWh makes sense for a small office in Parramatta (it doesn't). It flags missing billing periods, unit inconsistencies, and consumption figures that deviate significantly from historical patterns. Our anomaly detection picks up data entry errors and unusual patterns that a human reviewer would likely miss in a batch of 500 bills.

Phase 5 — Normalisation. Everything gets converted to consistent units. GJ to kWh. Litres to kilolitres. Calendar months to financial quarters. We have 50+ unit conversions built in. This step sounds boring but it prevents the exact kind of error that causes NGER restatements — confusing megajoules with gigajoules is a factor-of-1,000 mistake that looks perfectly plausible in a spreadsheet.

Phase 6 — Emission factor matching and calculation. This is the step that makes the whole thing carbon accounting instead of just document processing. The system applies the correct NGA emission factor based on what was extracted: state-based grid factors for electricity (Victoria's 0.78 kg CO2-e/kWh versus Tasmania's 0.20), fuel-specific combustion factors for diesel and gas, waste category factors for disposal. We have 139+ NGA 2025 emission factors pre-loaded, with the 5-tier material matching system resolving which factor applies.

The formula is always: Emissions = Quantity x Unit Conversion x Emission Factor. That's it. The hard part isn't the maths. The hard part is getting the right quantity from the right document, converting it to the right units, and matching it to the right factor.

Phase 7 — Audit trail. Every calculated emission links back through the entire chain. Which emission factor was used and why. What the normalised quantity was. What the raw extracted value was. The exact page and location in the source document where that value appears. When the CER audits your NGER submission or your financial statement auditor reviews ASRS disclosures, you don't go hunting through shared drives. You click a number and see the source.

The 5-Tier Material Matching Problem Nobody Talks About

Here's something we didn't appreciate until we'd processed a few thousand real documents. Extracting data accurately is only half the problem. You also need to match each extracted record to the correct emission factor. And emission factor databases aren't organised the way real-world documents describe things.

A fuel receipt says "diesel." The NGA Factors workbook has separate entries for automotive diesel oil, industrial diesel, marine diesel, and off-road diesel — each with slightly different emission factors. A waste manifest says "general solid waste (non-putrescible)." The NGA waste emission factors distinguish between multiple waste categories with different methane generation rates.

Our 5-tier matching system works through this progressively. First, it tries an exact match against the NGA database. Then a normalised match (stripping units, adjusting formatting). Then a semantic match using AI to understand what the document is actually describing. Then a category-level match. And finally, if confidence is low, it flags for human review rather than guessing.

The system learns from corrections. When a human reviewer says "this fuel receipt labelled 'regular unleaded' should match to 'petrol — gasoline'" the association gets stored. Next time, it matches automatically. We're not sure this approach scales perfectly across every edge case in the NGA workbook — there are hundreds of factor entries and the real world finds endlessly creative ways to describe the same fuel — but it handles 70-80% of matching without intervention, and it gets better over time.

How to Evaluate Whether an Automation Tool Is Real

We build this stuff, so we're biased. But we've also seen what other tools in the market actually do, and the gap between marketing claims and reality is wide. Here's what to look for.

Ask about document format support. If a tool only accepts CSV uploads, it isn't automating data collection. It's automating calculation after you've already done the hard work of extracting data from source documents into a spreadsheet. That's not nothing — but it's automating maybe 20% of the process and leaving you with the 80% that actually takes the time.

Ask where the audit trail starts. Does it trace back to the source document, or to a manually entered number? Under ASRS, your financial statement auditor needs to see how you got from a utility bill to an emission figure. Under NGER, the CER expects the same. If the chain starts at "someone typed 12,450 kWh into a form," you've got a gap that no amount of downstream automation fills.

Ask about error handling. What happens when the system can't read a document, or when the extracted value doesn't make sense? Good automation flags uncertainty. Bad automation guesses and moves on. The Beach Energy case happened because of "potential weaknesses in internal control systems." An AI system that silently produces wrong numbers is worse than a spreadsheet, because at least with a spreadsheet you know someone might have made a mistake.

Ask about emission factor matching. Does the system automatically select the correct NGA factor, or do you manually assign it? Does it handle the difference between location-based and market-based Scope 2? Does it know that a Victorian electricity bill uses a different grid factor than a Queensland one? These aren't advanced features. They're baseline requirements for Australian carbon accounting.

Test with messy documents. Not clean PDFs from your favourite retailer. The scanned copy of a gas bill from a regional council with hand-written annotations. The 14-page electricity invoice from an industrial site where consumption sits on page 9. The fuel docket photographed on a desk. If the tool can't handle your worst documents, it won't save you time — because you'll still be manually entering the hard ones.

What Automation Won't Fix

We should be honest about the limits. Automated emissions data collection handles utility bills, fuel records, and waste manifests well because these are structured documents with predictable fields. But not all emissions data lives in documents.

Refrigerant leakage logs are often maintained (poorly) in maintenance spreadsheets or not at all. There's no invoice to scan — someone needs to record the quantity of R-410A recharged into each system and calculate the implied leakage. We can ingest those maintenance records if they're in one of our eight supported formats, but the underlying data capture still depends on someone recording the recharge event.

Scope 3 data from suppliers is genuinely hard. We've written about collecting Scope 3 data from suppliers separately, but the short version is: if your supplier sends you an emissions report, we can process it. If they send you nothing — which is what most suppliers do — no amount of document automation helps. You need a different approach entirely (spend-based estimation, industry averages, or sustained supplier engagement programs).

And we're not going to pretend AI handles every document perfectly. Heavily degraded scans, documents in languages other than English, and highly unusual formats still need human review. Our 70-80% automation rate is measured across real customer documents, including the messy ones. The remaining 20-30% isn't waste — it's the system correctly identifying where it's not confident enough to proceed without a human check.

The Regulatory Clock

ASRS Group 2 entities start reporting for financial years beginning on or after 1 July 2026. ASRS Group 3 follows from 1 July 2027. Both groups get a one-year deferral on Scope 3, but Scope 1 and 2 are required from the first reporting period — and they're not covered by the modified liability safe harbour. Directors face personal liability for materially inaccurate emissions data from day one, with maximum penalties of $15 million or 10% of annual turnover.

NGER reporters (961 controlling corporations as of 2023-24) have their 2025-26 deadline on 31 October 2026. And if you're an NGER reporter, you're automatically pulled into ASRS Group 2 via the registration pathway — so you're dealing with both frameworks using the same underlying data.

The question isn't whether to automate emissions data collection. It's whether you can afford another reporting cycle where a qualified professional spends eight weeks typing numbers from PDFs into spreadsheets, knowing that 1-4% of those entries are wrong, and that the audit trail ends at "Sarah entered it in September."

If you want to see what automated collection looks like with your actual documents — the messy ones, not the clean test cases — upload a batch to Carbonly and compare the output against what your team extracts manually. That's the only test that matters.