The AI Carbon Accounting Loop That Gets More...

An AI carbon accounting tool gets more accurate when every correction your reviewer makes is saved and reused: the next docket with the same wording matches through the alias instead of going back to review. Many carbon accounting vendors publish an accuracy number instead. 98%. 99%. 99.5%. Whichever is larger than the last vendor's number.

Ask any of them the follow-up question. Accuracy on what document, from what supplier, in what layout, at what confidence threshold, with how much tenant memory behind it, and the answer stops being clean. It becomes: it depends.

That's the honest answer. And it's the one we lead with when a prospect asks us the ChatGPT-generated evaluation question about OCR accuracy.

A tool that reads Ampol fuel dockets well can fall over on a scanned handwritten Coles Express receipt in a truck cab. A tool that handles Boral's Sydney invoice layout can guess wrong on Boral's Melbourne format. A tool that's tuned on AGL electricity bills has never seen your regional gas retailer's PDF. Publishing "98% accurate" hides all of that.

The alternative is not to publish a global number at all. Send the uncertain matches to a reviewer. Keep the source document on every emission record so the auditor can see where the number came from. That's what we do.

What "accuracy" actually means when you dig in

Accuracy in AI carbon accounting is really three questions stacked on top of each other.

Did the AI extract the right numbers from the document. Did it map those numbers to the right material and emission factor. And did anyone check its work before those numbers landed in your NGER submission or your AASB S2 disclosure.

Extraction is the OCR part. Reading 5,832 litres from a fuel docket. Reading 12,450 kWh from an electricity bill. Reading 24.7 m3 of 40 MPa concrete from a Boral delivery ticket. Extraction accuracy is very high on clean digital PDFs from major suppliers. It drops on scanned image PDFs. It drops further on phone photos taken in a truck cab at dusk. It drops the most on handwritten dockets where the driver's biro pressed through three carbon copies.

Mapping is the harder question. "Diesel" on a fuel docket needs to map to the right NGA 2025 factor. "40 MPa concrete" needs to map to a product EPD, or to a spend-based fallback with a data quality flag. A line item that says "TRANSPORT SURCHARGE" needs to be recognised as not-an-emission and excluded. Mapping accuracy depends heavily on how many aliases your organisation's reviewers have already taught the system.

Review is the compliance question. Nobody wants an AI silently posting Scope 1 emissions into a disclosure that has director liability attached. Section 19 of the NGER Act is a civil penalty provision, with a maximum of 2,000 penalty units per contravention. AASB S2 Scope 1 and 2 disclosures carry full liability from day one, with no modified liability protection. Any tool that removes the reviewer from the loop is designing for the wrong risk.

How a corrected docket matches itself next time

When Carbonly's document engine reads a line item, it runs a five-tier material matching cascade against learned aliases, the NGA factors and a construction EPD factor library. Low-confidence matches go to a reviewer rather than posting silently.

At the top is an exact match on an organisation alias. Six months ago your Carbon Lead corrected "DIESEL BULK DEL" on your supplier's dockets to NGA 2025 diesel. Every future docket with that wording matches through the alias.

Next is an exact match on the NGA 2025 library. "Natural gas" as a description with a GJ unit lands here. The system knows what it is. The reviewer sees a high confidence score.

Lower down is a fuzzy match on the material description. "Concrete 40MPa 20mm agg" might fuzzy-match to a known concrete factor with only moderate confidence, and go to the reviewer. If they correct it, the line text becomes an alias that the top tier matches on the next invoice.

What the reviewer sees before a row posts

Low-confidence matches land in a review queue before they become emission ledger rows. That is the design.

The review screen shows the source document open on the left, the extracted quantity and unit in the middle, and the proposed material match with confidence score and NGA factor on the right. Confirm, correct, or reject. Three buttons.

Confirmation posts the row to the ledger. Correction saves the line text as an alias on the corrected material for your organisation, so the next document with the same wording matches through it. Rejection sends it back to the queue with a note.

None of this is exotic. It's the same workflow a good carbon consultant would run on a shared spreadsheet. The difference is that every action here is captured with a timestamp, a user, and a link back to the source document. Six years and eleven months from now, when the auditor asks to see the diesel quantity for a specific site in a specific month, one click surfaces the fuel docket that carried that number.

Handling scanned, handwritten, and unusual invoices

The document engine reads eight file formats. PDF, Word, PowerPoint, Excel, CSV, RTF, images, and scanned PDFs. That last category is the one evaluators tend to test hardest.

Scanned image PDFs where the OCR confidence drops. Phone photos taken by a foreman in a truck cab. Handwritten fuel dockets with three carbon copies bleeding into each other. These are the documents that break template-based tools. In Carbonly they land at lower confidence and go to review.

The pattern is consistent. Low-confidence results land in review. The reviewer opens the document, confirms the quantity, and confirms or corrects the material. A correction is saved as an alias, so the next document with the same wording matches through it. A hard-to-read scan still lands at low confidence and still goes to a reviewer.

This is the loop that makes high-volume construction document workloads tractable, not because the tool is perfect on day one, but because matching improves each time a reviewer corrects a match.

What accuracy looks like across the tenant lifecycle

The reason a global accuracy number is misleading is that accuracy in this system has a lifecycle.

Fresh install, week one. No learned aliases yet. More lines land at low confidence and go to review. Reviewers confirm, correct and reject, and every correction is saved as an alias for your organisation.

Three months in. The wording your main suppliers use has largely been taught, so more lines match through learned aliases. New suppliers, unusual formats and low-confidence lines still go to review.

Twelve months in. Review focuses on new suppliers, unusual formats and anomaly flags. Your team's clerical hours can come down, and their reduction and strategy hours can go up.

Publishing a single global accuracy number would flatten this lifecycle into a lie. Sending uncertain matches to a reviewer and keeping the source document on every record is the honest answer.

Errors that surface months later get flagged too

Not every accuracy problem shows up at extraction time. Some show up months later. A fuel consumption spike that turns out to be a decimal-place error. An emission factor version drift after the NGA workbook updates. A material that got mapped correctly six months ago but has been silently pointing at a retired factor since.

Anomaly checks run as deterministic rules every day at 6am and after each document batch, and flag outliers such as fuel consumption ten times the site average. The Data Health Agent checks coverage: scopes or months with no data, incomplete records and stale data.

Flags land in a review queue for a reviewer to action or dismiss.

Proactive flags beat audit-day surprises. Under ASSA 5010 limited assurance, your auditor is going to trace a statistical sample of emission records back to source documents. They are going to compare emission factor versions used against the NGA workbook edition current at the reporting date. They are going to check that quantities look plausible against physical activity. These checks run some of the same tests before the auditor does.

What this means for the reviewer's day

The reviewer's job shifts. Not away. Up the value chain.

Week one is clerical: fuel dockets, utility bills, hours of confirming. The system is learning from every correction, but the reviewer can't feel it yet.

Month three, the reviewer chases anomaly flags, builds emission factor matching rules for a new product line, and confirms three new suppliers. Clerical hours come down.

Month twelve, the reviewer thinks about scenario modelling, reduction pathways, and Scope 3 supplier engagement. That's the shift the AI is actually delivering. Not a number on a marketing page. A change in what the reviewer does with their week.

The practical starting point

If you're evaluating this against your own data, don't try to test it across your whole portfolio on day one. Pick five recent invoices from your highest-volume supplier. Send them through. Confirm the extractions. Then pick five more.

By the tenth invoice, the corrections your reviewer made on the first five should be matching through learned aliases. That's when the loop is closing.

That's a real test of the loop, and it takes a few hours rather than a few months. Send five invoices from a supplier that matters to you and see how far the system gets by the tenth. That's the honest evaluation.

Talk to us at hello@carbonly.ai. Per-project pricing across Small, Medium, Large, and Enterprise tiers, plus a $100 per month workspace minimum. No consultant engagement to unlock the trial.

The AI Carbon Accounting Loop That Gets More Accurate Every Time You Correct It