Carbon Accounting Automation Platform

Carbon accounting for a mid-sized engineering company spans far more than energy bills. It touches fleet fuel, taxi and travel spend, purchased goods, utilities, and international operations — each with its own data source, its own format, and its own reporting cadence.

The existing process handled this manually: emissions were calculated per invoice, using published government conversion factors, with figures compiled by hand into spreadsheets ahead of annual reporting deadlines. This is a standard approach for organisations at this stage of carbon reporting maturity, but it carries three structural limitations that any manual process of this kind will have:

• No automated cross-checking. A figure entered once is trusted; there's no independent mechanism to catch a transcription error, a missed invoice, or a miscalculated factor until an audit — if one happens at all.
• Inconsistent handling across data sources. Different sectors arrive in different formats (PDF invoices, Excel exports, CSV dumps from other systems), each requiring a different manual approach.
• No scalable path to sub-annual reporting. Producing quarterly, rather than annual, figures would multiply the manual workload directly, with no corresponding increase in headcount.

The brief was to reduce the manual burden without reducing accuracy — ideally improving it — while leaving a clear, auditable trail from source document to final figure.

• Support 7 distinct emissions sectors, each with a different data shape and source format.
• Handle real-world document inconsistency: multiple suppliers per sector, format changes mid-year (including at least one supplier rebrand), and older invoice formats with incomplete data (e.g. missing postcodes needed for distance calculation).
• Never silently guess. Where a confident calculation isn't possible, the system must flag the item for human review with enough context to resolve it quickly — not drop it, and not estimate it.
• Support switching between reporting years' conversion factors without manual intervention, since UK government DEFRA factors update annually.
• Provide a live, non-technical dashboard so the sustainability team can see current totals, drill into any sector, and process review items themselves — without needing database or workflow access.
• Full audit trail: every calculated figure must be traceable back to its source file, extracted values, and the exact factor applied.

Large-file handling. The Purchased Goods pipeline processes CSV exports exceeding 17,000 rows. An early version passed the file through the workflow as base64-encoded data, which expanded significantly in memory as it moved through successive processing steps, eventually exceeding available memory on the orchestration platform — a failure with no clear error message, since the process was simply terminated. The fix was architectural, not a patch: the frontend now uploads the file directly to object storage, and the workflow receives only a signed URL, fetching the file itself only at the point it's actually needed. The large payload never travels through the rest of the pipeline.

Year-aware factor switching. UK government conversion factors update annually. Rather than hardcode a single year's factors, the factor-lookup step reads a factor_year parameter supplied at run time, and the underlying tables store multiple years' factors side by side. This was designed in from early in the build, anticipating the year-end transition, and required no structural change when the new year's factors needed to go live.

Security. All 30+ database tables enforce Row Level Security, with read access scoped appropriately and privileged write operations routed through service-role, server-side functions rather than exposed client-side credentials.

Duplicate protection. Implemented at two independent layers — file-hash checking (has this exact document been processed before) and row-level composite-key checking (has this specific line item, e.g. a given invoice number and date, been recorded before) — so a duplicate can't slip through even if one layer is bypassed.

Extraction from real-world documents occasionally produces a technically-valid but implausible value — for example, an invoice number misread into a quantity field, or a multi-page document's metadata misread as tabular data. These failures don't throw an error; they produce a number that looks like a normal result.

A dedicated validation step was added to four of the highest-risk sectors, checking each calculated result against sector-specific plausibility bounds (e.g. a single taxi trip exceeding a realistic maximum distance, or a fuel quantity exceeding a realistic single fill). Anything outside those bounds is withheld from the reported total entirely and routed to a review queue with the specific reason attached — so an implausible figure can never silently reach a report.

This layer was itself tested adversarially before go-live: a batch-processing edge case (the check initially only evaluating the first item in a multi-item file) was identified and fixed during pre-launch testing, using a deliberately constructed multi-invoice test case rather than relying on the first real-world batch to surface it.

Before go-live, every sector was independently reconciled — not just spot-checked — against source documents and, where available, confirmed prior-year figures.

• Taxi: over 100 individual trips manually verified against source pickup/dropoff addresses across all four suppliers. Every trip that completed automated processing matched, within normal route-calculation variance.
• International travel: three full months, spanning the reporting year, reconciled row-by-row against source data — 372 individual line items, 100% accounted for (either calculated, or correctly flagged with a specific, verifiable reason).
• UK gas / electricity: matched confirmed prior-year figures exactly, or within under 0.1%, after resolving two extraction issues found during validation.
• Purchased goods & services: matched confirmed prior-year figures at 99.4% across 1,000+ suppliers and 17,000+ line items.

Issues found and resolved during validation (a deliberate part of the process, not an afterthought):

• A utility-billing extraction bug that under-counted consumption on invoices spanning a mid-period rate change, affecting a subset of monthly figures — identified via an anomalous cost-per-unit ratio during review, not a system error.
• A cross-sector spend classification that had an incorrectly-applied emissions factor for one transaction category, found through direct comparison against source calculations, confirmed, and corrected retroactively.
• A reporting discrepancy between the new system and an existing spreadsheet-based process, resolved by applying a materiality check — annualising both figures against a confirmed prior-year total showed the new system's figure implied plausible year-on-year growth, while the legacy figure implied an implausible multi-fold increase, correctly identifying the discrepancy's source.

The platform now runs as the primary calculation and reporting system for the sectors in scope, with:

• A live dashboard showing current-year totals by scope and sector, with drill-down to source data.
• An automated review queue that routes anything uncertain to a human, with full context, rather than estimating.
• Full traceability from any reported figure back to its source document and the exact factor applied.
• The infrastructure to support quarterly (or more frequent) reporting cycles without a proportional increase in manual effort.