The AI That Reads Fuel Dockets, Utility Bills and...

The generic "carbon accounting software" category has a ceiling and it's called spend-based estimation. Pull a dollar figure from the finance system. Multiply by an EEIO factor from a national supply-use table. Book the number. It scales, it's cheap, and it's increasingly getting kicked back by auditors when activity data was available and simply not used.

The real work in Australian carbon accounting is reading the physical activity data off the source document. 342.7 litres of diesel from an Ampol fuel docket. 18,432 kWh from an AGL electricity invoice. 22.4 tonnes of 40 MPa concrete from a Boral delivery note. That's the layer AASB S2 assurance walks toward and it's the layer that spend-based approaches skip because it's genuinely hard.

Carbonly's AI document engine was built for that exact job. This post is what "AI document processing for carbon accounting" actually means when you strip out the marketing.

What AI Document Processing Actually Means Here

It doesn't mean a chatbot. It doesn't mean summarising a PDF. It means turning an unstructured supplier document into a structured emission record: quantity, unit, material, supplier, date, site, scope, emission factor, factor version, CO2-e result, and a confidence score on every extracted line.

Eight input formats are handled from day one:

Native PDF invoices with selectable text
Scanned or image-only PDF invoices
Photos of paper dockets from a phone camera
CSV data extracts
Excel workbooks with multiple sheets and merged headers
Word documents (docx)
PowerPoint decks that contain embedded tables
Rich Text (RTF) exports from older finance systems

The last three matter more than they look. A surprising number of supplier statements arrive as Word attachments or Excel workbooks with three sheets and a summary tab. If your ingestion pipeline only accepts clean PDFs, you're back to manual data entry for the messy 30% and that 30% is where the audit questions live.

The Right Factor on Every Line, With Proof of Who Chose It

Extracting "diesel, 342.7 L" from a fuel docket is only half the job. The other half is deciding which emission factor to apply and being able to prove that decision two years later when the auditor arrives. Carbonly runs every extracted line item through a five-tier matching cascade:

Organisation alias: if a reviewer in your organisation has previously corrected a line with this exact wording, use the same material.
NGA 2025 factor library: the National Greenhouse Accounts factors published by DCCEEW, versioned by year, state, and scope split. For diesel this is about 2.7 kg CO2-e/L Scope 1 combustion, with Scope 3 upstream emissions of 17.3 kg CO2-e/GJ (about 0.67 kg CO2-e/L) on top.
Tenant custom library: factors your Carbon Lead has uploaded or authored, including internal emission factors, negotiated PPA-backed electricity, or supplier-provided figures.
EPD import: Environmental Product Declarations from EPD Australasia and equivalent registries, with product-specific embodied carbon numbers for materials like cement, structural steel, and reinforcement bar.
Reviewer queue: when nothing above matches with enough confidence, the line goes to a reviewer, who assigns the material. That correction is saved as an alias for your organisation only, so later documents with the same wording match through it.

The confidence score matters because an assurance walk-through for AASB S2 limited assurance needs more than "the AI got it right." It needs a trail showing the match, who reviewed or corrected it, and when, so an auditor can follow it. That trail is what a defensible Basis of Preparation document is made of. We wrote about this in ASRS Assurance Requirements.

Gaps and Outliers Flagged Before Quarter Close

Extraction accuracy is necessary but not sufficient. You also need checks for the things that break carbon numbers silently:

Coverage gaps: a scope or month with no data, incomplete records, or stale data. This is what the Data Health Agent looks for.
Outliers: a fuel consumption figure far above the site's usual pattern. The anomaly checks look for these using deterministic rules, daily at 6am and after each document batch.
Missing mappings: an extracted line item that no tier of the cascade could match, which goes to a reviewer
Units that cannot be converted without an unstated figure, such as cubic metres to tonnes with no density, which also go to a reviewer

Issues surface for review during the period, not as post-hoc surprises during quarter close.

How the Reviewer Gets to the Data

Web UI is the default for the human reviewer. Beyond that:

Email ingestion: site managers forward dockets from the field to an ingestion address instead of uploading them by hand.
OneDrive and SharePoint folder sync: connect a folder per project. New files are pulled and processed on schedule. This is how finance teams already sharing supplier PDFs into a monthly folder can turn that folder into an emission ledger with no workflow change.

Where This Fits for Consultants

Australian sustainability consultants running multi-client engagements are one of the primary use cases the platform is designed for. The intended pattern is: the consulting practice uses Carbonly as the extraction and calculation engine across all its clients, and produces the client's board-facing report on top of the ledger. The consultant keeps the strategic judgment, the materiality workshops, the scenario analysis, and the transition plan authorship. That's the craft. Carbonly is the workshop equipment underneath.

If a consultant is leading your engagement, the workflow looks like: they set up your workspace, wire the OneDrive folder, load your first months of invoices, and hand you a working ledger. The hours that went into data entry shrink. The strategic work they are engaged for stays.

The Construction Data-Entry Problem

Construction is where manual entry breaks first. A Tier 1 civil operation generates fuel dockets, delivery dockets and supplier invoices faster than a sustainability team of two can key them in, and the layouts change with every supplier, every site and every thermal printer. The architecture routes that whole flow through the AI document engine and puts the sustainability team on the review and exception-handling layer instead, the layer where the actual carbon-accounting judgment sits.

Carbonly is preparing for broader market release and is being deliberate about not inventing customer stories. What is described here is what the platform is designed to do, not an attested customer engagement.

The Honest Bit

A few things this engine doesn't do and won't pretend to:

It is not a PCAF data quality scoring module. We hold the underlying data and the provenance; a PCAF-shaped view is a report on top of it, not a built-in engine.
It is not a NABERS or GRESB submission generator. Same principle: we hold the numbers; the framework-specific submission sits above the ledger.
It does not currently ship New Zealand MfE emission factors as a native library. Australian NGA 2025 is the built-in default.
Direct push into Climate Active or the TfNSW CERT tool is not a built-in integration.

That honesty is part of the point. If you're comparing tools for a mandatory disclosure obligation, the tools that promise everything are the ones that tend to break in assurance.

The 30-Record Trial

If you want a concrete first step: send five sample invoices from your most common supplier to hello@carbonly.ai and we'll run them through the document engine. If the extraction lands well, we onboard the workspace at the per-project pricing that fits (Small / Medium / Large / Enterprise), plus the $100 per month workspace minimum. If the extraction doesn't land, you've spent an email and we've learned something about a supplier format we hadn't seen.

That's the offer. Not a demo of a chatbot pretending to be an emissions system. A real extraction, on your real documents, in a working ledger.

The AI That Reads Fuel Dockets, Utility Bills and Supplier Invoices for Carbon Accounting