Carbon accounting automation is sold as a single block: connect your systems and the inventory builds itself. In practice, it behaves as a sum of very different situations. Some emission categories fill themselves almost on their own from data already present in your systems. Others require preliminary nomenclature work without which no tool will produce anything but a rough estimate. And part of the work does not automate at all, because it involves a methodological choice you will have to justify to an auditor.
This article breaks the question down category by category: what automation delivers today for energy, purchases, travel and freight, what it does not cover, the technical prerequisites that condition the result, the common mistakes of a poorly scoped deployment, and the three indicators that tell you whether your automation is reliable.
The calculation methods cited are those of the GHG Protocol. The characteristics of the monetary factors come from the ADEME Base Carbone, the French emission factor database, consulted via its public API.
Contents
What carbon accounting automation covers
Automating a carbon accounting process means automating three distinct operations, each with its own difficulty and risk:
A single criterion determines the degree of automation achievable for a category: does a machine-readable trace of the corresponding physical activity already exist somewhere in your systems? A reading in kWh, a volume of liters, a tonnage, a distance. When this trace exists, the automation is solid. When it does not, and all that remains is an amount in currency, the tool can still produce a figure, but that figure carries an uncertainty that must be explicitly acknowledged.
Energy and fuel: the most automatable category
This is the category where automated carbon data collection delivers the best results, for three combined reasons.
First, the data is already physical. An electricity bill carries kWh, a gas bill carries kWh or cubic meters, a fuel card carries liters. No monetary conversion is needed.
Second, the data is recurring and structured. Energy bills arrive in the same format, from the same issuer, at fixed intervals. Supplier portals and metering APIs often expose consumption series that are directly usable. A smart meter produces a time series with no human intervention.
Third, the choice of emission factor is stable and low in cardinality. You are working with a handful of energy carriers, not ten thousand purchase references. Once the mapping is established for a site, it holds for every subsequent period.
What automation handles without difficulty in this category:
One limit to keep in mind: the GHG Protocol's Scope 2 Guidance requires dual reporting when contractual instruments exist in your market. You must publish a result under the location-based method and a result under the market-based method, each clearly labeled. The location-based part is fully automatable from kWh data. The market-based part depends on contracts and certificates of origin, meaning documents to upload and verify, not a meter reading.
A second limit: as soon as fuel is consumed under an all-inclusive contract, a long-term lease with fuel included, for example, you lose the liter count and fall back on an amount. The category becomes monetary again.
Purchases and upstream scope 3: automatable under conditions
This is the category where most of the volume sits, and the one where automation requires the most scoping. For scope 3 category 1, purchased goods and services, the GHG Protocol describes four calculation methods, from most to least specific:
The Protocol is explicit about the status of the last one: it applies when the first three are not feasible, notably for lack of data. It is a fallback, not a default option.
What automates well
Extracting line items automates: an ERP or accounting export, a general ledger file, or a batch of invoices run through optical character recognition produce a usable table of lines. Mapping automates too: a recurring supplier, a dedicated accounting code, a stable label are mapped once and then reapplied. On a clean purchasing dataset, the majority of volume runs through a small number of rules.
The method for processing a batch of invoices is detailed in our article on invoice data extraction for carbon accounting.
The cost of falling back on spend
When a line item carries only an amount, the tool applies a monetary ratio. Those in the ADEME Base Carbone, built from SDES and INSEE data, have three characteristics worth keeping in mind:
The operational consequence is more troublesome than the uncertainty figure itself: your footprint tracks your prices, not your physical consumption. Renegotiating a contract down mechanically lowers your reported emissions, without a single tonne actually avoided. A category calculated on a spend basis is therefore of limited use for steering a reduction effort.
A nuance not to miss
The GHG Protocol warns that more specific data is not automatically more accurate. Supplier data implies allocating the supplier's emissions across the products it sells you, and that allocation adds its own degree of uncertainty, sometimes considerable depending on the method used. The guidance actually recommends choosing different methods for different purchase categories, reserving the most specific methods for the categories that contribute the most to the total.
The reasonable objective is therefore not to eliminate spend-based data everywhere. It is to concentrate the effort toward specificity on the significant purchase families, and to accept spend-based data for the long tail. To situate which categories are concerned, see our article on upstream and downstream scope 3 emissions.
Travel and freight: it depends on the data available
For business travel as for upstream transport, the GHG Protocol offers the same structure of choices: a method based on fuel consumed, a method based on distance, a method based on spend.
Automation does not choose the method. It inherits the method that your data makes possible:
The ceiling for automation of a travel category is therefore decided upstream of the software, in the data contract you negotiate with your travel agency or freight forwarder. Getting class and distance included in the monthly export moves the category to a different calculation method. That is a procurement discussion, not a configuration setting.
What does not automate
Part of the inventory relies on judgment for which you remain responsible:
Automation can timestamp these decisions and make them searchable and reproducible. It cannot make them for you. The corresponding checkpoints are detailed in our article on what to check before trusting a result produced with AI (FR).
The prerequisites for automation that holds up
An automation project rarely fails on the calculation engine. It fails upstream.
Quality of ERP exports. Stable columns from one export to the next, a unique identifier per line, the amount net of tax and the quantity in two separate columns, the unit column populated. An export where quantity and unit are concatenated into a free-text label condemns the category to spend-based data.
Purchase nomenclature. A chart of accounts designed for accounting is not a carbon nomenclature. Catch-all accounts such as "miscellaneous purchases" or "external services" have no physical equivalent and can only receive an average ratio. Splitting these accounts is often the single move that most improves an inventory, ahead of any tool choice.
Supplier reference data. The same supplier recorded under four different spellings produces four independent mappings, and therefore four opportunities to diverge.
Discipline around supporting documents. An invoice attached to a line is what turns a number into a defensible number. Without documentation, you have an estimate, not an auditable inventory.
Alignment of reporting periods. Fiscal year, calendar year, meter reading dates, and invoice dates do not coincide. The mapping rule must be decided once and applied everywhere.
Most of these prerequisites are not carbon work. They are data governance work, and they largely predate the project.
Common mistakes in a poorly scoped automation
Double counting. The same fuel counted twice: once in scope 1 via the fuel card, once in scope 3 category 1 via the supplier's invoice present in the accounting export. The same mechanism applies to freight paid and rebilled, or to a site's energy rebilled by the landlord. The more sources you connect, the higher the risk of overlap.
Units. kWh in higher or lower heating value, liters versus kilograms, tonnes versus tonne-kilometers, cubic meters of gas versus kWh. An automated mapping that ignores the unit column produces results that are plausible and wrong, which is the worst possible outcome.
VAT-inclusive amounts instead of net of VAT. The Base Carbone's monetary ratios are defined per thousand euros net of VAT. Feeding the calculation with VAT-inclusive amounts mechanically inflates a purchase by the applicable VAT rate.
Ignored euro vintage. These ratios are indexed to a reference year for the euro. Applying a euro 2019 ratio to 2025 amounts without deflating overstates the result, since the same good costs more in current euros.
Factors frozen at import date. A frozen mapping keeps applying a factor version that has since been revised. The result should retain the reference and version of the factor used, not just its numerical value. The definition and lifecycle of an emission factor are detailed in our article what is an emission factor.
Scope 2 method chosen silently. A tool that applies a national average factor by default even when the site holds certificates of origin, or the reverse, produces a figure that is correct under a method you did not choose.
How to measure whether your automation is reliable
Three indicators are enough, and they can be measured without specialized expertise.
Reproducibility. Rerun the same import over the same period and compare the total. If it moves, either the factor database changed between the two runs, or the mapping is not deterministic. Both cases are acceptable, provided they are visible and explained. A silent discrepancy is not.
Rate of lines requiring review. The share of lines for which a human corrected the tool's proposal, tracked by purchase family. A family with a high correction rate signals an upstream nomenclature problem, not a flaw in the engine. A family that stays permanently at zero corrections is either genuinely stable, or simply not checked by anyone: the two are worth distinguishing.
Traceability. From any figure in the report, can you trace back to the source line, its unit, the factor with its version, and the supporting document, in a bounded number of steps? If the answer is no, the automation produced speed, not an auditable inventory.
A fourth indicator is worth tracking over time: the share of emissions calculated using the spend-based method. This is your indicator of dependence on the fallback. It should decrease for significant purchase families and can remain high for the long tail, which is a deliberate trade-off rather than a flaw.
What Kabaun automates
Kabaun covers the acquisition and mapping chain described above, while keeping the judgment calls with the user:
For an overview of the tooled approach, see our guide on carbon accounting with AI.
FAQ
Can a carbon accounting process be fully automated?
No. Acquiring data, mapping it to a category, and recalculating largely automate. The organizational boundary, cutoff criteria, assumptions on estimated data, and validation of suggested factors remain human decisions, because an auditor will ask you to justify them. Automation documents and reproduces these decisions, it does not make them for you.
Which categories automate best?
Energy and fuel, when consumption is already measured in kWh, cubic meters, or liters on recurring documents. The data is physical, structured, and the number of factors to apply is small. Purchases also automate, but the quality of the result depends entirely on the purchase nomenclature set up upstream.
Is the spend-based approach acceptable for scope 3?
Yes, as a fallback. The GHG Protocol provides for the spend-based method when the supplier-specific, hybrid, and average-data methods are not feasible. It remains poorly suited to steering reductions: the ADEME Base Carbone's monetary ratios are defined by broad activity division and carry a declared uncertainty of 80% for the large majority of them. A price decrease lowers your reported emissions with no physical effect.
Do you need an ERP to automate carbon accounting?
No, but you need a usable export. What matters is the structure of the file: stable columns, a line identifier, amount net of VAT and quantity in separate fields, and the unit populated. A clean accounting export or a general ledger file is enough to get started. A poorly configured ERP guarantees nothing.
How do you know if the factors suggested automatically are correct?
Check three things on a sample: the factor's unit matches your data's unit, the geographic scope and validity year are consistent with the activity, and the factor version is recorded alongside the result. Prioritize checking the families that carry the most weight in the total, not the ones with the most line items.
How many lines need to be checked manually?
There is no universal threshold. One operational approach is to exhaustively check the purchase families that concentrate the majority of emissions, then sample the long tail. Track the rate of corrected lines by family: that, not the total line volume, indicates where to focus verification effort.
Resources
Conclusion
Carbon accounting automation delivers on its promise where a physical trace of the activity already exists: energy, fuel, travel documented by distance, freight invoiced in tonne-kilometers. It produces a usable but coarse result where only an amount remains. And it leaves untouched everything that depends on judgment: the boundary, the exclusions, the assumptions, the acceptance of a mapping.
The most cost-effective step before choosing a tool is to look at your exports: is the unit column populated, do your catch-all accounts carry significant weight, are your suppliers standardized. This diagnosis determines your automation ceiling far more reliably than any product sheet.
Let's discuss your boundary and your data sources → www.kabaun.com/en/contact
