Emission Factor Version Control
On 11 June 2026 DEFRA published its conversion factors. On 31 July it republished them, correcting values that had been “incorrectly reported as 0 rather than left blank where no data were available.” Same year, same name, same page — different numbers. If you ingested in June and recorded the source as “DEFRA 2026”, you cannot tell today which of the two files you are running on, and a zero does not look like a missing value. It looks like no emissions.
“DEFRA 2026” is not a version. Publishers revise in place, factors move in bursts, and labels change while identifiers stay put — so a figure recorded with only a publisher and a year cannot be reproduced. Store four things beside every computed number: the factor key, the data version that answered, the value itself, and the date you retrieved it. Then a restatement becomes a decision you make, rather than something that happens to you between reporting cycles.
Failure 1 — publishers revise in place
The assumption underneath most factor pipelines is that a published dataset is immutable: DEFRA 2026 is DEFRA 2026, and if you fetched it you have it. That assumption is wrong, and it is wrong in the quietest possible way.
The 2026 UK conversion factors were first published on 11 June 2026 and the collection page now reads “last updated 31 July 2026”, with a note that the flat file was republished because a number of values “were incorrectly reported as 0 rather than left blank where no data were available” — affecting well-to-tank figures for hybrid, CNG and LPG vehicles, and hotel stays in some countries.
A blank cell fails loudly: your pipeline raises, someone investigates. A zero passes every validation you have. It sums, it charts, it reconciles — and it silently removes an emissions line from your inventory. If you ingested the June file and did not re-check, those rows are still zero, and nothing in your system will ever tell you.
This is not unique to DEFRA. The EPA’s eGRID2023 shipped three times — released 15 January 2025, revision 1 on 17 January, revision 2 on 12 June. Three files, one name. A pipeline pinned to “eGRID2023” is pinned to whichever of the three it happened to fetch.
Failure 2 — the factor moves and your total moves with it
Factors are not stable between cycles, and they do not drift gently. Across 112 days of continuous version control we recorded 2,219 published factor values changing, with 93% of them landing inside a single fortnight in June — the annual release window. Between the 2025 and 2026 DEFRA editions, 585 of 1,453 tracked UK factors changed value.
The one that matters most for reporting: the UK grid factor fell 26%. Recompute last year’s electricity consumption on this year’s factor and your Scope 2 drops by a quarter without a single kilowatt-hour being saved.
That number will end up in a board pack. If nobody can separate the factor change from the activity change, the organisation is told it decarbonised when it did not — and the correction, when it comes, is more expensive than the pin would have been.
Failure 3 — the label changes, the identifier doesn’t
The subtlest of the three, and the one that breaks joins.
Datasets carry both a stable identifier and a human label, and publishers revise the label freely between editions — a category gets renamed, a qualifier is added, a hierarchy is restructured. If your lookup joins on the label, a pure cosmetic rewrite silently orphans rows: the factor is still there, your join no longer finds it, and depending on your code you either raise or quietly fall through to a default.
Join on the identifier, always. And when a publisher offers no identifier at all — the EPA’s Emission Factors Hub is one — you must mint and maintain your own mapping, which is a permanent job rather than a one-off migration. That is worth knowing before you choose to build on a source rather than buy it.
What to store beside every number
The practice that solves all three failures is unglamorous: every computed figure carries its inputs. Four fields, alongside the result:
| Field | Why |
|---|---|
| Factor key or identifier | The stable handle. Never the display label — see failure 3. |
| Data version | Which edition answered. This is the field that distinguishes DEFRA-2026-in-June from DEFRA-2026-in-August. |
| The value itself | So the figure reproduces even if every upstream system disappears. Cheap to store; impossible to reconstruct later. |
| Retrieval date | Distinct from the data year. Tells you which side of a mid-cycle correction you are on. |
Storing the value alongside the key is the part teams argue about, on the grounds that it duplicates the source of truth. Store it anyway. It is a handful of bytes, and it is the difference between reproducing a two-year-old figure offline and re-deriving it from a supplier who has since revised, rebranded or shut down.
If your source can pin a read to an edition, use that rather than keeping private copies — the Python guide shows the mechanics. If it cannot, the archive is your responsibility, and that cost belongs in the build-versus-buy decision. How to evaluate a carbon data API makes it one of five tests.
Restate or pin: choosing deliberately
Once figures are pinned, a genuine question appears that unpinned pipelines never get to ask: when a factor changes, should last year’s report change too?
Both answers are defensible and they serve different purposes.
Pin the reporting year. Each year’s figures stay as published, computed on the factors current at the time. This is what most disclosure frameworks assume, and it means a prior-year number never moves after sign-off. The cost is that a multi-year trend mixes factor revisions into what looks like performance.
Restate the series. Recompute prior years on the current factors so the trend reflects activity alone. This is the honest way to answer “are we actually reducing?” — and it requires you to hold every prior year’s activity data and be able to re-run it, which is only possible if you pinned in the first place.
The workable answer for most organisations is both: report on the pinned basis, and maintain a restated series alongside for internal trend analysis, with the difference between them stated. What you cannot do is neither — which is where an unpinned pipeline leaves you, reporting a number that quietly changed for reasons nobody recorded.
The conversation this is for
All of this exists for one exchange, which arrives eighteen months after the work: “Where did this number come from?”
With version control in place the answer takes a minute. This factor key, this data version, this value, retrieved on this date, from this publisher’s table — and here is the same query returning the same number today. Without it, the answer is an afternoon of archaeology ending in “we think it was the 2026 factors”, which is not an answer, because as this page opened by showing, there were two 2026 files.
The asymmetry is what makes this worth doing early. Pinning costs one extra field in a table. Not pinning costs an unbounded amount at exactly the moment you have least time, and the cost lands on whoever inherits the pipeline rather than whoever built it.
If an assurance engagement is what prompted this, pinning is one of three criteria a verifier applies to factor data, alongside naming the factors and retaining the evidence. The assurance readiness checker scores all three against your obligation and its assurance level, and names the weakest.
Frequently asked questions
No, and the 2026 DEFRA release is the proof: the same publisher and the same year names two different files, seven weeks apart, with different values in the well-to-tank rows. A year identifies an edition only if the publisher never revises it, and publishers revise. You need something that distinguishes the June file from the July one.
In bursts, not continuously. Over 112 days of tracking we saw 2,219 values change with 93% inside a single June fortnight, because publishers ship annually and cluster around the same window. The practical consequence is that you cannot schedule the work: it is quiet for months and then a year’s worth arrives at once, usually while you are doing something else.
It depends what the number is for. Disclosure generally wants the pinned basis, so a signed-off figure never moves. Internal trend analysis generally wants the restated one, so you are measuring your own performance rather than the publisher’s revisions. Doing both and stating the difference is the strongest position — and it is only available if you pinned.
Then you own the archive: keep every edition you ingest, with the retrieval date and a checksum, and never overwrite in place. That is a real maintenance commitment, and it is the hidden cost in building on raw published files rather than a versioned source. Whichever route you choose, choose it knowingly rather than discovering it during an audit.
More than a coded one, because a spreadsheet has no history you can query. The minimum viable version is a column recording which factor edition each row used, filled in when the row is created rather than reconstructed later. It is not elegant, and it answers the audit question, which is the whole purpose.
Because “again” assumes the source still exists, still serves that edition, and still answers the same way. Over a five-year retention period that is an optimistic set of assumptions — publishers withdraw datasets, change licences and shut down. A stored value costs a few bytes and removes every one of those dependencies.