Spend-based vs activity-based emission factors

A spend-based factor gives emissions per unit of money spent. An activity-based factor gives emissions per physical unit: a kilogram, a litre, a kilowatt-hour. Use activity factors when you know the quantity, and spend factors when all you have is an amount on an invoice.

Two ways to estimate the same purchase#

• Activity-based. You multiply a physical quantity by a factor for that product: 1,000 kWh times a grid factor per kWh. The factor usually comes from a life-cycle assessment or a national inventory. It reflects the product itself.
• Spend-based. You multiply the money you spent by a factor for the whole sector that sells it: 10,000 euros of animal products times a factor per euro. The factor comes from an environmentally extended input-output (EEIO) model, which spreads a country's emissions across the flows of money between its sectors.

A spend factor averages everything a sector sells. It cannot tell a cheap product from an expensive one, or a low-carbon supplier from a high-carbon one. It covers the whole supply chain, which makes it useful for screening and for purchases no activity factor covers.

Why. The GHG Protocol accepts spend-based estimates for Scope 3, but ranks them below supplier-specific and activity-based data. Start with spend to find your hot spots, then replace the largest lines with activity data.

The spend-based libraries#

Four of the public libraries these docs write examples against are spend-based. Factor search carries others.

Counts are default top-level factors. All of them carry unit_family = monetary and data_type = average; the EEIO models also carry co2e_basis = io_total, the whole supply chain as the model sees it. Browse monetary factors.

Currency year#

A spend factor is per euro of a given year. currency_year is that price year. It is a price level, not the date the data was published, and it is independent of reference_year.

Prices rise, so a 2025 euro buys less than a 2019 euro. Applying a factor built on 2019 euros to 2025 spend without adjustment overstates your emissions by the whole price rise in between.

The data makes that adjustment for you. A monetary factor is served once per activity year from 2015 to 2025. Each row is already expressed per currency unit of that year, and price_index_ratio shows the adjustment applied to the publisher's figure. The index is chosen by the economy of the factor (deflation_economy), not by its currency.

For EXIOBASE animal products in France, published on 2019 euros:

The 2025 factor is 14 % smaller per euro, because a 2025 euro buys fewer animal products. Pick the row for the year of your spend. See the factor page.

Watch out. The price index runs to 2025. Spend from a later year has no adjusted row yet, and the data does not extend the index by guessing.

The currency it is quoted in#

Each library prices in one currency, and unit_code names it: euro for EXIOBASE and ADEME, US dollars for USEEIO, yen for Open CEDA. That is the money the factor is per unit of, whatever economy the factor covers, which is why an Argentine Open CEDA row is money that moved the way the yen moved.

You do not have to convert it by hand. Factor search and the API restate every monetary factor into a currency you name, at the annual average rate of the row's own activity year, so one factor read across several spend years crosses several rates. The restatement is presentation and not selection: the rows, the counts and the order are the same with it and without it, and a physical factor is never touched. A restated row carries the publisher's own currency in original_unit_code and the multiplier in fx_ratio, so the as-published number is always recoverable from the served one.

Watch out. Convert after the price adjustment, never before. The served row is already on your spend year's price level in the publisher's currency. Converting the publisher's raw figure instead counts the exchange-rate move between the two years twice. Read it in your own currency shows the order and the rates.

Price basis#

The same purchase has three prices, and price_basis says which one the factor divides by:

• basic: what the producer receives, before taxes on products.
• producer: the basic price plus taxes on products, less subsidies.
• purchaser: the producer price plus trade and transport margins. It is what you pay.

Your invoice shows the purchaser price. A factor on a basic or producer basis divides the same emissions by a smaller amount of money, so applied to invoice spend it overstates the result. None of these libraries prices the same activity on two bases, so factor search cannot tell you how large that bias is: prefer a purchaser-basis factor where one exists rather than correcting one yourself.

When to use which#

Never add a spend-based and an activity-based estimate of the same purchase: each already covers it.

Related#

• Deflate spend factors
• Glossary: currency year and price basis
• Units and conversions
• Choosing a library