Spend-Based Emission Factors: Inflation and FX Adjustments

When you estimate a Scope 3 category from spend, you apply an emission factor expressed as emissions per unit of currency. A common situation is that the factor was built from an older year's data, say 2019, while the spend you are applying it to is from the current year. Multiplying one directly by the other overstates your emissions, because a spend-based factor carries an assumption about prices and currency that is easy to miss the first time you meet it. This guide explains what that assumption is, how to correct for inflation and exchange rates with a worked example, and why the whole issue is a reason to move your larger categories onto activity data.

What a spend-based factor is really measuring

A spend-based factor estimates emissions from money: so many kilograms of CO2-e per dollar you spent on a category. It's drawn from environmentally-extended input-output data such as EXIOBASE, and it's the fast way to cover a category when you don't have physical activity data. But the factor was built from a particular year's economy, so it's really emissions per dollar in that year's prices and that dataset's currency. A 2019 factor is emissions per 2019 dollar. That base year is the assumption you have to respect.

The inflation problem

Prices rise over time, so a dollar today buys less real activity than a dollar did in 2019. If you take a 2019 factor and apply it straight to 2025 spend, you treat the extra dollars that are only inflation as if they were extra activity, and the emissions come out overstated. The correction is to bring the two into the same year. Either deflate your current spend back to the factor's base-year prices using a price index before you multiply, or use a factor that's already been re-based to the current year with a compounding inflation adjustment built in.

A worked example makes it concrete. The numbers here are illustrative, not real factors:

The currency problem

The same logic applies to exchange rates. Many spend-based datasets are built in euros or US dollars, and your spend is in Australian dollars. To keep the price basis consistent, you convert using a rate tied to the factor's base year, not an unrelated rate from today. Mixing an old factor with a current exchange rate stacks two different years' worth of prices and currency on top of each other, and the error compounds with the inflation one. A good factor library handles both adjustments for you, per year, so you're not doing index maths by hand.

The other way a factor ages: emissions intensity

Inflation is one reason an old factor misleads, and it is a price artefact, a change in the dollars rather than in the underlying carbon. There is a second, separate reason, which is the emissions intensity the factor carries. That is how much carbon it actually took to produce a unit of the good or service in the factor's base year, and it is not fixed. As electricity grids and economies decarbonise, the real emissions behind a dollar of most goods and services tend to fall over time, so a factor built on an older year carries a higher intensity than the current one. The GHG Protocol calls how well a factor's period matches your reporting period its temporal representativeness, and good practice is to use factors that are reasonably current. Grid and electricity factors are a clear case: they are republished every year, and in Australia you use the current National Greenhouse Accounts Factors for each reporting year.

Both effects push the same way. A stale factor tends to overstate the emissions of current activity, once for inflation and again for intensity, so moving to a current factor usually lowers the number and makes it more accurate. Recent updates to the main input-output datasets have generally reduced industry-average factors, reflecting real progress on decarbonisation. Two cautions come with that. The pattern is general rather than a rule: some sectors move the other way, and a dataset update often folds in methodology changes as well as real-world decarbonisation, so not all of a drop is a physical improvement. And a fall that comes from the grid or the wider economy getting cleaner is not your own reduction. It is worth capturing for accuracy, but background decarbonisation should not be claimed as your own mitigation or as progress against a target. There is also a consistency trade-off: if you change factor vintages partway through a trend, a year-on-year movement now mixes your own actions with the factor update, so document any change and, if it is significant, recalculate your base year to keep the comparison like-for-like.

Why this pushes you toward activity data

The arithmetic points to a more basic limitation. Spend is a proxy for activity, and it moves with prices as well as with what you actually did. Spend more on freight because rates went up, and a spend-based estimate reads it as more emissions, even if you shipped the same tonnage. That's why the general approach is to put your effort into activity-based data where a category is a big share of your footprint, often the majority, and to accept an adjusted spend estimate where the category is small. You don't have unlimited time, and tracing activity for every minor line isn't worth it. Match the effort to where the emissions are.

What to check on your own factors

Three questions surface most of the problems. What base year and currency is each spend factor built on? Has an inflation and exchange-rate adjustment been applied to bring it to your reporting year, or is a raw old factor sitting against current spend? And is it applied consistently, so two similar categories aren't adjusted one way in one place and left alone in another? If a factor can't answer the first question, you can't trust the emissions it produces.