Why traditional carbon accounting is the bottleneck

Ask anyone who has prepared a greenhouse-gas inventory where the time went. They rarely say "the maths". Multiplying litres of diesel by an emission factor takes seconds. The weeks go into everything around it: finding the bills, chasing the plant that forgot to send its meter readings, reconciling units, and explaining to an auditor which factor was used and why.

That is the bottleneck, and it is structural. Traditional carbon accounting treats emissions as an annual reporting exercise that sits on top of the business, not a record the business produces as it runs.

Where the time actually goes

A typical inventory for a mid-sized manufacturer runs through the same five steps every year, and almost all of them are manual.

1. Collecting activity data. Electricity bills from each discom, fuel invoices, gas statements, e-way bills and purchase records live in inboxes, ERP exports, shared drives and paper files at each site.
2. Normalising it. Billing periods don't line up with reporting periods. Units vary (kWh, kVAh, litres, kilograms, standard cubic metres), and the same supplier appears under three spellings.
3. Choosing factors. Grid factors differ by country, region and year. Fuel factors differ between DEFRA, IPCC and national inventories. Someone has to pick one, record why, and apply it consistently.
4. Getting supplier data. Scope 3, and now CBAM precursors, depend on numbers held by other companies, who get the same request from every customer in a different template.
5. Leaving a trail. An assurance provider or verifier has to be able to follow each reported figure back to evidence. If the trail is a chain of spreadsheet tabs, re-performing it is as slow as building it.

None of these steps is hard on its own. Together they make the inventory a months-long project that starts over every year.

The consultant loop

Because the work is episodic and specialised, most companies buy it as a service. A consultant arrives, gathers a year of data, builds a model, writes the report and leaves. The report is fine. The problem is what it leaves behind: a point-in-time number, a workbook only its author fully understands, and no system that makes next year faster.

The same data is gathered again the following year, often by a different team, and the numbers shift for reasons nobody can fully reconstruct. It is expensive and slow, and it is fragile exactly where assurance now puts the pressure.

Why dashboards didn't fix it

The first wave of carbon software moved the model out of Excel and into a web application. It helped with calculation, consolidation and charts. It did not remove the bottleneck, because the bottleneck was never the calculation. A dashboard still needs clean activity data, and implementations that take months are usually months of someone uploading and mapping that data by hand.

The regulatory clock just changed the stakes

For years a slow inventory cost little beyond staff time. That changed in 2026.

• EU CBAM entered its definitive period on 1 January 2026. Importers of steel, aluminium, cement, fertilisers and hydrogen will buy certificates for the embedded emissions of 2026 imports, with the first declaration due by 30 September 2027. Where the exporter can't supply actual data, default values apply with a mark-up of 10% in 2026, 20% in 2027 and 30% from 2028.
• SEBI's BRSR Core requires assessment or assurance for the top 1,000 listed companies from FY 2026-27. An assured number needs a trail, not just a total.
• India's Carbon Credit Trading Scheme puts legally binding emission-intensity targets on hundreds of plants in seven sectors, for the 2025-26 and 2026-27 compliance years.

In each case the data now carries a price or an audit, or both. For an exporter, the gap between measured emissions and a marked-up default is money on every tonne shipped. An annual, consultant-built inventory arrives too late to act on and is too opaque to defend.

What removing the bottleneck looks like

The fix is not a better report template. It is a different operating model, built on five principles.

1. Capture at the source. Read bills, invoices and ledgers where they already arrive (email, the accounting system, the ERP) instead of asking people to re-key them.
2. Calculate deterministically. The same inputs and the same factor version must always give the same number. Software should never estimate the arithmetic.
3. Keep lineage. Every reported figure should link back to its source document, the factor used and the version of that factor.
4. Keep a human in the loop where it matters. Automation should prepare the work; a responsible person approves what gets filed.
5. Ask suppliers once. Supplier data should be requested in one standard format, stored with consent, and reused across every customer who needs it.

That is how we are building ZeroCarbon. Our agents read documents and connected accounts such as Gmail, Tally and Zoho. Calculations run in a deterministic engine with versioned factors. Nothing is filed without human approval, and every report is anchored with a SHA-256 digest so it can be checked later. We are working with a small number of design partners, starting with Indian exporters facing CBAM.