Two teams can measure the same electricity consumption, apply a perfectly official factor each, and publish results that differ by a factor of two. Neither made a calculation error. They did not pick the same emission factor database, the same year, or the same boundary.

This article does not redefine what an emission factor is: that is covered in our article on emission factors explained. It answers a different question. Among the available databases, which one should you adopt, on what criteria, and how do you document that choice so it survives an audit. Every value quoted below comes from the official site of the database concerned, with its unit, version and year.

Table of contents

  • What an emission factor database actually is
  • Why two databases give two answers
  • The main public databases and what they cover
  • Five criteria for choosing an emission factor
  • One reference database per inventory
  • Versioning your factors
  • The most common traps
  • What a verifier expects
  • Emission factor databases in Kabaun
  • FAQ

    • What an emission factor database actually is

    An emission factor database is a dataset published and maintained by an organisation. It attaches to an activity a coefficient that converts it into carbon dioxide equivalent, along with a unit, a boundary, a geography, a validity year and, in most cases, an uncertainty.

    It is not a table of physical constants. It is a publication: it has an editor, a methodology, an update policy and a version number. A factor therefore only means something when it is attached to its database and its version; a value sitting alone in a spreadsheet cannot be audited. And every database has a domain of validity: a factor built for the French electricity mix does not describe consumption in Poland, even though the unit is identical.

    Why two databases give two answers

    Electricity is the textbook case. In the ADEME Base Carbone, the entry "Électricité, mix moyen, consommation" for mainland France, year 2024, is 0.0519 kgCO2e/kWh, with a stated uncertainty of 10 %. That total aggregates three components documented separately: 0.035 kgCO2e/kWh for combustion at the power plant, 0.0131 upstream, and 0.0038 for transmission and distribution.

    In the UK government conversion factors for 2026, UK grid electricity is 0.13096 kg CO2e/kWh for generation, classified as Scope 2. The remaining components are published separately under Scope 3: 0.01299 for transmission and distribution, 0.03682 for the well-to-tank stage of generation, and 0.00359 for the well-to-tank stage of transmission and distribution.

    Three gaps stack up here, and they explain most of the divergence between two inventories:

  • Geography. A mostly nuclear grid and a grid that still burns fossil fuels do not produce the same coefficient. That is the physical reality of the two networks, not a mistake.
  • Boundary. The French factor includes upstream emissions and grid losses; the UK generation factor does not. Comparing 0.0519 with 0.13096 means comparing a total with one of its components.
  • Year. The same Base Carbone entry is 0.0607 kgCO2e/kWh for 2019, 0.052 for 2022 and 0.058 for 2023. Same activity, same database, same unit, and more than 10 % of variation year on year.

    • The main public databases and what they cover

  • ADEME Base Empreinte, at base-empreinte.ademe.fr. The French entry point, hosting the Base Carbone, currently in version V23.6. The dataset published on data.ademe.fr under the French open licence held 18,616 records when checked in November 2026. ADEME describes it as the reference database for article 75 of the Grenelle II law, which sets out the greenhouse gas inventory obligation. Default choice for activity located in France.
  • UK government conversion factors, at gov.uk. Updated every year, with a methodology report and a major changes report. They target UK organisations and international organisations reporting on their UK operations, and they are relevant to Streamlined Energy and Carbon Reporting. One point that is often missed: they are distinct from the spend-based multipliers published by the UK environment department, which are primarily meant to compare carbon intensities across categories of final demand.
  • EPA GHG Emission Factors Hub, at epa.gov. Default factors for corporate reporting in the United States, updated regularly; the current release is dated January 2025. Its sources are documented: the EPA Greenhouse Gas Reporting Program, the eGRID database for electricity by subregion, the national inventory, the WARM model for waste, and the IPCC Fifth Assessment Report for global warming potentials. Several earlier editions, from 2011 to 2024, remain archived, which makes historical recalculation practical.
  • ecoinvent, at ecoinvent.org. A life cycle assessment database, paid, accessible under licence. It holds more than 26,000 datasets modelling human activities and processes, with an annual update; version 3.13 was released on 4 November 2026. Relevant when the subject is a product, an industrial process or a modelled supply chain.
  • IPCC Emission Factor Database, at ipcc-nggip.iges.or.jp. Suited to fuels and national inventories rather than to a corporate footprint. The IPCC states that its primary objective is to act as a repository of measurements supporting its default factors, and that responsibility for appropriate use remains with the user.
  • Sector databases. Agribalyse for food, INIES for construction products, the GLEC framework for freight. They complement a general database on a specific category, they do not replace it.

    • Five criteria for choosing an emission factor

  • Geography. The factor must match where the activity took place, not where the head office sits: a Spanish subsidiary consumes Spanish electricity. With no local factor available, using a foreign one becomes an assumption that has to be written down.
  • Reference year. The factor must match the year of the activity data. Applying a 2019 factor to 2024 consumption creates an unjustified gap.
  • Unit, physical or monetary. A physical factor applies to a measured quantity: kWh, litres, kilograms, tonne-kilometres. A monetary factor applies to an amount spent, and remains a fallback reserved for categories with no physical data, as explained in our article on invoice data extraction for carbon accounting.
  • Factor boundary. Combustion only, combustion plus upstream, with or without grid losses, with or without end of life. This is the most frequently overlooked criterion, it produces the largest gaps, and it drives the split across Scopes 1, 2 and 3.
  • Documented uncertainty. A serious database publishes an uncertainty or quality indicators. That information sets collection priorities: a material category carrying an uncertain factor deserves primary data.

    • One reference database per inventory

    The operating rule fits in one sentence: pick one reference database for the whole inventory, and leave it only through a documented exception. For a business operating mostly in France, Base Empreinte is the baseline. Three exceptions are legitimate: activity located abroad, handled with the relevant national database; a sector category the baseline does not cover, handled with a specialised database; a product that requires life cycle modelling.

    Every exception is traced line by line: which category, which database, which version, which reason. Without that discipline, nobody can reconstruct the logic of the inventory six months later, including the team that produced it.

    Versioning your factors

    An inventory is reproducible when the same activity data produce the same result. That requires freezing the factors. Three things to store on every calculation line:

  • The factor identifier in its database, its full label and its exact unit.
  • The database version and the validity year of the factor, not just the date you looked it up.
  • The numeric value actually applied, stored alongside the calculation line.

    • The third one is the one teams forget. If the system queries the database in real time on every page load, last year's inventory will change silently the day an update lands. Serious publishers make this easier: earlier editions of the EPA hub stay archived, and the UK factors ship with a report of the major changes between vintages.

    The most common traps

  • Mixing databases within one category. Part of the gas consumption calculated with the French database, another part with the UK factors, because two people searched separately. The total stops meaning anything.
  • A French factor applied abroad. The most expensive trap on electricity, where two neighbouring countries can carry very different coefficients.
  • A tax-exclusive monetary factor applied to tax-inclusive amounts. Monetary factors are built on amounts excluding tax. Applying them to a VAT-inclusive invoice overstates emissions by the amount of the tax.
  • Confusing net and gross calorific value. In the 2026 UK factors, natural gas is 0.20199 kg CO2e per kWh on a net calorific value basis and 0.18231 on a gross calorific value basis. Gas invoices do not all express the same quantity.
  • Double counting by stacking boundaries. Adding a total factor that already includes upstream emissions to a separately published upstream line counts the same emission twice.
  • Treating an archived factor as a valid one. Databases keep superseded entries. In the Base Carbone, every entry carries a status, and one activity often exists in a valid version and several archived ones. Filtering on that status is not optional.

    • What a verifier expects

    A verifier does not challenge your database, they challenge the absence of justification. For every category, they should be able to read:

  • The database used, its version and the validity year of the factor.
  • The exact factor label and unit, as they appear in the source.
  • The boundary the factor covers and how that boundary maps to the scopes.
  • The justification for exceptions, whenever a line leaves the reference database.
  • The uncertainty or quality indicator published by the database.
  • The assumptions made, in particular geographic substitutions and any use of monetary factors.

    • This note is written as you go. Rebuilt at the end, it is always incomplete. The broader subject is covered in our article on carbon accounting.

    Emission factor databases in Kabaun

    Kabaun gives access to several public databases inside a single calculation engine, including the ADEME Base Carbone, the UK government factors, the EPA factors, Exiobase, Agribalyse, GLEC, Miteco and OpenCEDA, alongside the IPCC and IEA methodological references.

    Custom factors are available when no public database covers a given activity, with administrator validation and full traceability. Every update to the factor database is logged and timestamped. When a factor is broken down into components, the calculation returns that breakdown line by line, so the applied boundary can be checked rather than assumed. On each category, suggested factors rely on a hybrid search, semantic first then deterministic reranking, and are shown with their match rate. Klem, the platform's artificial intelligence layer, suggests factor matches when accounting documents are imported: validation stays human and logged.

    FAQ: common questions about emission factor databases

    Which emission factor database should a French company use?

    ADEME Base Empreinte, which hosts the Base Carbone. ADEME describes it as the reference database for article 75 of the Grenelle II law, which sets out the greenhouse gas inventory obligation. Other databases come in as complements, for activity outside France or for sector categories the baseline does not cover.

    Can you mix several databases in one carbon inventory?

    Yes, but only through documented exceptions. You define one reference database for the whole inventory, then justify each departure line by line: category, substituted database, version, reason. Mixing two databases within one category without justification makes the total impossible to interpret.

    Why does the electricity factor vary so much between countries?

    Because it reflects the generation mix of the grid concerned. In the Base Carbone, the French average consumption mix is 0.0519 kgCO2e/kWh for 2024; in the 2026 UK factors, UK grid electricity is 0.13096 kg CO2e/kWh for generation. The two boundaries differ, which rules out a direct comparison.

    Should you use a physical or a monetary factor?

    A physical factor whenever the data exists, because it rests on a measured quantity. A monetary factor is reserved for categories with no physical data available, typically some purchased services. It applies to amounts excluding tax and must be flagged as such.

    Is ecoinvent paid, and when do you need it?

    Yes, access runs through a licence. It holds more than 26,000 datasets modelling activities and processes; version 3.13 was released on 4 November 2026. It becomes useful once the subject goes beyond standard energy consumption: product footprint, detailed industrial process, modelled supply chain.

    How do you document a factor choice for a verifier?

    By keeping, for every calculation line, the factor identifier and exact label, its unit, the database and its version, the validity year, the boundary covered, the value applied at calculation time, and the justification if the factor sits outside the reference database. This documentation is produced during the calculation.

    Conclusion

    Choosing an emission factor database comes down to four decisions: one reference database for the whole inventory, a geography and a year aligned with the activity data, an explicit factor boundary, and a written trace of every exception.

    What to do now: open your latest inventory and check, on the three largest categories, that the database version and the factor year are stored alongside the calculation line. If they are not, the inventory is not reproducible.

    Talk through your factor sources with Kabaun → www.kabaun.com/en/contact