Per-Supplier Extraction Templates: How Carbonly...

Pull a Boral concrete delivery docket and an Ampol fuel invoice off the same email inbox. Now try to write a single set of extraction rules that handles both. Carbonly does not try. It learns each supplier's layout from five sample documents and extracts every later one under that confirmed mapping.

The Boral docket has a supplier code up the top, a product code that looks like 32MPA-20-80-C (that's a 32 MPa strength grade, 20mm aggregate, 80mm slump concrete), cubic metres in the quantity column, delivery site, plant of origin, docket number, and driver name. The Ampol invoice has fuel type (ULP 91, diesel, PULP 95), litres, price per litre, station, vehicle rego, transaction ID. They share almost nothing structurally. And AGL's electricity bill is different again: NMI, meter number, billing period, tariff code, kWh consumption, kWh peak vs off-peak.

Every carbon reporter in Australia deals with this. Many tools handle it one of two ways: force a manual mapping on every invoice, or run a generic OCR pass that pulls text but can miss fields you actually need for a defensible emission record. Neither is a real answer.

Ten to twenty suppliers carry most of your invoice volume

Once you've been doing carbon accounting for a full reporting cycle, you notice something. Sixty to eighty per cent of your invoice throughput comes from ten to twenty suppliers. Boral or Holcim for concrete. Ampol or BP for fuel. AGL or Origin for electricity and gas. Cleanaway or Veolia for waste. Toll or Linfox for freight. The exact mix depends on your sector, but the pareto shape holds.

Each of those suppliers has a stable-ish invoice layout. A large supplier's docket structure might change once every couple of years. A retailer's bill format can change when a customer moves to a new tariff. A fuel supplier's docket can differ between card-lock stations and delivered fuel. But within each supplier, the layout is repeatable enough that a well-defined mapping between "column X on the docket" and "target field in the emission record" holds for hundreds of subsequent invoices.

The value of extraction templates comes from that stability. If we can define the mapping once and reuse it, the analyst's job changes. It stops being data entry. It becomes exception review.

What a per-supplier template actually is

A supplier extraction template is a structured mapping between a supplier's invoice layout and the emission record data model. Which column carries the material description. Which carries the quantity. Which carries the unit of measure. Which carries the delivery site or business unit. Which carries the invoice date. Which carries the reference number the auditor traces back to.

In the Carbonly data model, the target fields are canonical. Every emission record needs a supplier, a businessUnit, a material, a quantity, a unit, a date, and a reference. Optional fields (notes, and a small budget of custom fields) cover the supplier-specific columns that don't map cleanly, like Boral's MPa strength grade or Ampol's card number.

The template lives inside a supplier's own record and travels with every extraction that matches. When the extraction pipeline processes an invoice and the supplier identifier matches an active template, the template's column mappings drive the field assignment directly. No manual mapping. No guessing. And the lastSeenAt timestamp updates so you always know which templates are still in use versus which have gone stale.

Five sample documents is all a new supplier needs

The auto-derive workflow is the piece that makes this practical. Upload five processed documents from a new supplier. The template matcher inspects the column headers across those five samples, tallies which columns recurred, and drafts a mapping proposal. The draft is proposed, not activated. A Carbon Lead reviews it, adjusts anything the matcher got wrong, and confirms.

Five is a deliberate choice. It's the point where the layout signal is strong enough for a confident auto-derive proposal while the reviewer effort is still bounded. The matcher only proposes a mapping for columns that appear in at least 80% of the samples, which with five samples means the column has to be present in at least four of them. That threshold filters out one-off columns (a special note field that only appeared on one docket) while keeping the recurring skeleton that defines the supplier's real layout.

The five-sample minimum is enforced at the schema level, not just as a soft check. A draft cannot be silently activated without meeting the sample count. If only three samples are available, the caller gets an explicit error telling them how many more samples are needed before auto-derivation is allowed. This matters for the audit trail. When an auditor asks "how did you decide this Boral docket's cubic-metres column maps to the quantity field?", the answer is: five sample documents recurring in four out of five, canonical synonym match on "quantity" or "volume" or "metres", proposed by the matcher, confirmed by a named human reviewer on a specific date.

How the matcher decides which column is which

The matcher doesn't guess. It runs a synonym-driven analysis with a fixed priority order. Reference-type columns (docket number, invoice number, transaction ID) get matched first, because "invoice" and "reference" can accidentally sound like other fields. Date columns come next. Then quantity, unit, material, supplier, business unit, and notes.

Each canonical target field has a synonym list that maps common column header names to that field. Quantity matches on qty, quantity, volume, amount, weight, litres, mass, metres. Business unit matches on site, location, project, branch, depot, yard. Material matches on material, product, item, goods, commodity, fuel, type. Reference matches on ref, docket, invoice, PO, purchase order, transaction ID.

When the matcher finds a header that doesn't match any canonical synonym, it doesn't throw the column away. It proposes it as a custom field with a sanitised name. That's how Boral's MPa strength grade lands in the record: the header "MPa" doesn't match any canonical field, so the matcher proposes it as a custom field called MPa, and the reviewer decides whether to keep it, rename it, or drop it. The custom field budget is capped so the templates stay bounded and reviewable.

Every template version stays retrievable for the auditor

Every template goes through a defined lifecycle: draft, confirmed, live, archived. Each state carries typed audit events so the history is walkable.

Draft means the matcher has auto-derived a proposal but no human has confirmed it. confirmedByUser=false, isActive=false. The extraction pipeline ignores drafts entirely. They exist purely as review candidates.

Confirmed means the Carbon Lead has reviewed the draft and accepted the mappings. confirmedByUser=true, isActive=false. The template is ready to activate but isn't yet driving extractions.

Live means the template is active. confirmedByUser=true, isActive=true. Every incoming document from that supplier matches against the template and extracts under its mappings. The lastSeenAt timestamp updates each time the pipeline uses it, so you can distinguish templates that are actively pulling their weight from ones that have gone quiet.

Archived means the template has been retired. Ever-active templates can only be archived, never hard-deleted. This is the audit trail lock. If a template was used to extract even one emission record that eventually landed in an NGER submission, that template must remain retrievable for at least five years under NGER Act 2007 section 22. Carbonly retains for seven years as an internal policy, longer than the five the NGER Act requires.

Each state transition emits a typed audit event: supplier_template.created, supplier_template.confirmed, supplier_template.activated, supplier_template.archived, supplier_template.auto_derived_drafted, supplier_template.matched. That last event fires every time the template matches at extraction, which gives you a full history of which invoices were extracted under which template version.

What happens when a supplier changes their layout mid-year

This is the honest part. Suppliers do change their invoice layouts. An electricity retailer migrates a portfolio to a new billing platform and the NMI column moves. A fuel supplier shifts from a delivered-fuel docket format to a card-lock format when a customer changes contract type. A concrete supplier rolls out a new plant management system and the docket adds two columns.

When that happens, the next batch of invoices from that supplier still routes to the existing template on the supplier identifier match, but the extraction confidence drops because the recurring columns are no longer where they used to be, and low-confidence results go to a reviewer. The matcher runs against the new sample corpus and drafts a new template version. The Carbon Lead reviews the drift, confirms the new mapping, and archives the previous version.

Old emission records extracted under the previous template version stay linked to that version. That linkage matters. If an auditor pulls a record from January and one from August, and both were Boral concrete but extracted under different template versions because Boral changed docket layout in July, the audit trail shows exactly which template version was in force at each extraction date. No silent overwrites.

We won't pretend this is fully solved. Detecting genuine layout drift versus a one-off malformed invoice is a judgement call, and the system errs on flagging for review rather than auto-transitioning. That's the right conservative default for a compliance system, but it does mean the Carbon Lead sees drift alerts they end up dismissing as noise from time to time.

Suppliers this pattern covers across Australian sectors

The template mechanism is supplier-agnostic. The auto-derive works on whatever recurring layout is in front of it. In practice, these are the supplier populations most Australian reporters end up templating first.

Fuel: Ampol, BP Australia, Shell and Viva Energy, Puma Energy, 7-Eleven Fuel, regional and card-lock providers. Fuel is usually the fastest template win because the layout is stable and the invoice volume is high.

Electricity: AGL, Origin Energy, EnergyAustralia, Alinta, Red Energy, Powershop, Momentum. The NMI and meter number pattern is consistent enough that most electricity retailers template cleanly, though multi-site accounts with per-NMI billing need business unit mapping care.

Gas: Origin, AGL, Alinta Gas, EnergyAustralia, ActewAGL. Natural gas invoices carry MJ or GJ as the unit, which the synonym matcher handles, but the calorific factor for Scope 1 combustion still comes from the NGA Factors workbook, not the invoice.

Construction supply: Boral, Holcim, InfraBuild, BlueScope, Wagners, Hanson, Adbri. Concrete and steel dockets carry the material grade and cubic metres or tonnes, which map to the five-tier material matching for factor selection.

Waste: Cleanaway, Veolia, SUEZ, Bingo Industries, JJ Richards, Solo Resource Recovery. Waste dockets carry waste stream code and tonnes, and the template mapping feeds into the waste emission calculations under NGER methods.

Freight and logistics: Toll, Linfox, StarTrack, Australia Post, TNT, FedEx Australia, Aramex. Freight is where the boundary calls get harder (tonne-kilometres versus spend-based Scope 3), but the invoice extraction itself is straightforward once the template is in place.

What each emission record can trace back to

The template is one layer of the extraction stack, not the whole thing. When an invoice arrives, the AI document engine processes the file, identifies the supplier, and checks whether an active template exists for that supplier. If yes, the template's column mappings drive the field assignment. The extracted material description then routes through the five-tier material matching engine, which resolves it to a specific NGA 2025 emission factor with the factor version pinned to the emission record.

Template plus matching plus factor version pinning is what produces the audit trail an ASSA 5010 reasonable assurance engagement walks. Each emission record answers: which document did this come from, which template version extracted it, which material matching tier assigned the factor, and which factor version was in force at the time. That's the full provenance chain.

What a consultant keeps across fifteen clients

Sustainability consultants running multi-client engagements ask whether templates learned in one client workspace transfer to another. The honest answer is no, and deliberately so. The auto-derive corpus is strictly org-scoped. Each client's document population derives its own templates from its own five-sample threshold, and no data crosses the tenant boundary. That's a compliance requirement, not a limitation.

Where the compounding happens is at the consultant's operational layer. A consultant running fifteen construction clients that all buy Boral concrete knows exactly which columns matter, which docket variants exist, and how to confirm the drafted template in ninety seconds instead of thirty minutes. The playbook compounds even when the data doesn't. That's the leverage.

Carbonly is the workshop equipment; the consultant is the craftsperson. The workflow we designed the Supplier Portal around assumes the consultant is leading the engagement and the client's operations team is providing the source documents.

What the template does not do

The template is a data extraction layer. It doesn't make methodology decisions. Whether an emission record uses activity-based or spend-based methodology falls out of the data model (do you have quantity in physical units, or only dollar spend?), not out of the template. If you extract cubic metres of concrete under a Boral template, activity-based falls out naturally. If you can only extract dollar spend from a summarised statement, you're in spend-based territory regardless of the template.

The template doesn't automate Scope 3 boundary decisions. Which categories to report, which to omit as immaterial, which to disclose but not measure, those calls belong to the reporting team and to the ASRS materiality assessment. The template gives you the physical data; the boundary decisions still need human judgement.

And the template doesn't replace the reviewer on unusual invoices. A Boral docket with an unexpected fifth column, or an AGL bill with a solar credit line item that changes the net kWh calculation, still needs the Carbon Lead to look at it. The pipeline flags the anomaly, the reviewer confirms, and the record proceeds. This is the human review model the whole extraction stack operates under.

Your first ten templates in half a day

Pick your top ten suppliers by invoice volume across the last full reporting year. For most Australian reporters that list is dominated by two fuel suppliers, two electricity retailers, one gas retailer, one or two waste contractors, and three to four sector-specific material or freight suppliers. Ten templates typically cover 60 to 80 per cent of invoice throughput.

For each of those ten suppliers, ingest five recent processed documents into the workspace. Trigger the auto-derive. Review each drafted template. Confirm and activate the ones the matcher got right; adjust the mappings on the ones it didn't. Budget half a day of a Carbon Lead's time. When you're done, the next quarter's extraction workload drops sharply, and the ones that come through are the exceptions you actually want to look at.

If your top ten suppliers include Boral, Ampol, AGL, or any of the names above, this is the first place we'd point you.

The result is a quarter where Boral, Ampol and AGL documents extract under mappings your Carbon Lead confirmed once, and only the exceptions reach a reviewer. Carbonly pricing is per project with a workspace minimum of $100 per month. To see it running on your own supplier invoices, email hello@carbonly.ai with a handful of dockets or bills.

Per-Supplier Extraction Templates: How Carbonly Learns Boral, Ampol, AGL, and Every Australian Supplier's Invoice Layout