A carbon accountant types one line into the AI assistant: "What is the emission factor for natural gas combustion?" Back comes a clean, confident answer in under a second: "0.184 kg CO2e per kWh." It looks perfect. It is the right order of magnitude, the right units, the right gas. The accountant pastes it into the inventory, multiplies it by 4.2 million kWh of gas, and books 772 tonnes of Scope 1 emissions. Six months later the assurer asks one question that the whole number cannot survive: "Where did 0.184 come from? Which database, which version, which year, which geography?" There is no answer. The model recalled a plausible figure from training data, attached no source, and the accountant never asked it to. The figure is not wrong because it is far off. It is wrong because it traces to nothing, and a factor that traces to nothing is a misstatement no matter how close it lands.

Why the Emission Factor Is the Most Dangerous Number in the Inventory

Every line in a greenhouse gas inventory is built from one equation that the GHG Protocol, the global standard nearly every reporting framework points back to, puts at the centre of carbon accounting: activity data multiplied by an emission factor equals emissions. Activity data is the measure of the thing that happened, the litres of diesel burned, the kilowatt-hours of electricity bought, the tonnes of steel purchased, the kilometres flown. An emission factor is the conversion rate that turns that activity into greenhouse gas, expressed as a mass of CO2 equivalent per unit of activity, for example kilograms of CO2e per kWh or per litre or per tonne. Multiply the two, sum the lines, and you have the inventory.

The emission factor is uniquely dangerous because of how it propagates. Activity data tends to be local and checkable: you can trace 4.2 million kWh back to a stack of gas bills. A wrong emission factor, by contrast, is a quiet multiplier applied across an entire category. If the factor is 12% too high, every tonne that depends on it is 12% too high, and the error compounds silently through the total. Worse, a hallucinated factor looks exactly like a real one. There is no asterisk, no warning, no visible difference between a number an authoritative database published after years of measurement and a number a language model assembled because it resembled the factors it had seen. Both are just three digits and a unit. The only thing that separates them is provenance, and provenance is precisely what an AI assistant will omit unless you force it to provide it.

This is why the factor is where AI's convenience and disclosure's discipline collide hardest. The model is genuinely useful for finding factors fast. It is also genuinely capable of inventing one that sails straight into a published, externally assured number. The skill in this lesson is the discipline that keeps the first benefit while closing off the second: never accept a factor the model cannot trace to a named, dated, authoritative source, and make that provenance travel with the factor for the rest of its life in the file.

What Provenance Actually Means for an Emission Factor

In a disclosure context, provenance is not a vague gesture at "a reputable source." It is a specific, structured set of attributes that together let an assurer reconstruct and judge a factor without you in the room. A factor without these attributes is not a sourced factor; it is a number with a story attached. The provenance tag that must travel with every factor has five load-bearing parts.

Database: the named, authoritative source the factor comes from. Version: which release or edition of that database, because factors are revised. Year: the reference year the factor represents, which is not always the year you are reporting. Unit: the exact unit of the factor (kg CO2e per kWh is not interchangeable with kg CO2e per MWh, and a tenfold or thousandfold unit error is one of the most common and most embarrassing inventory mistakes). Geography: the country or region the factor applies to, because the same activity emits very differently depending on where it happens. An electricity factor for France, where the grid is largely nuclear, is a fraction of the factor for a coal-heavy grid, and using the wrong geography can move a number by a factor of ten.

The Categories of Authoritative Databases

You do not need to memorise every database, but you must be able to recognise an authoritative one and force the AI back to it. There are broad categories, named here only to orient you, never as an endorsement of any one. National GHG inventory databases are published by governments and statistical agencies and tend to be the default for energy and fuel factors in a given country. Government factor sets in the DEFRA or EPA style are the annually updated conversion-factor libraries that many corporate inventories run on, covering fuels, electricity, transport, water, and waste with documented methodologies. LCA databases in the ecoinvent style provide life-cycle factors for materials and processes, the kind you need for purchased goods in Scope 3. IEA-style energy factors are widely used for electricity grid factors by country. The common thread is that each is named, versioned, dated, documented, and updated on a known cycle. A factor an assurer accepts on sight comes from one of these and carries the tag that says which one. A factor the model recalled from training carries none of that, and that absence is the tell.

A factor without provenance is not an efficient shortcut. It is an unsourced number wearing the costume of a measured one, and in a disclosure it is a misstatement waiting for an assurer to undress it.

The Hallucinated-Factor Failure Mode

To use AI safely for factor lookup you have to understand exactly how it fails, because the failure is not loud. A language model does not retrieve a factor from a database the way a lookup tool does. It generates the most statistically plausible continuation of your prompt, and when you ask for an emission factor, the most plausible continuation is a number that looks like an emission factor. Most of the time that number is in the right range, which is precisely what makes it dangerous: a wildly wrong factor gets caught, a plausibly wrong one gets booked.

The hallucinated factor arrives with three deceptions baked in. First, it is fluent: stated with the same confident tone as a correct answer, with no hedging to warn you. Second, it is plausible: close enough to a real factor that it passes a casual sniff test. Third, it is unsourced or falsely sourced: either it cites nothing, or, worse, it cites a database, version, and year that sound right but that the model invented, a fabricated citation that collapses the moment anyone opens the actual database. This third deception is the cruelest, because a fabricated provenance tag can fool a reviewer who checks that a source exists but not that the specific number lives in it.

The damage is silent and compounding. A single hallucinated factor corrupts every line that uses it, propagates into the category total, into the scope total, into the headline footprint, into the year-on-year trend, and into any target measured against that baseline. It can sit undetected through internal review precisely because it looks like every other number. It surfaces only when an assurer pulls the thread, and by then it is not a quiet correction; it is a restatement that calls every other number in the file into question. That is the asymmetry: the factor took one second to accept and can take an entire engagement to unwind.

It is worth understanding why ordinary review so often fails to catch this, because that is what makes the discipline non-negotiable rather than optional. Most internal review is a plausibility check: does this number look reasonable, is it in the right range, does it move sensibly from last year. A hallucinated factor is engineered, by the very way the model produces it, to pass exactly that check, because the model generated the most plausible-looking number in the first place. Plausibility review and hallucinated factors are tuned to the same frequency, so the review waves the factor straight through. The only review that catches a hallucinated factor is a provenance check: not does this look right, but where is this from, and can I open the source and see it. That is a different question, and it is the one an assurer asks, which is why building it into your own process is the difference between catching the problem at your desk and discovering it across a conference table.

Forcing the Model Back to the Database

The discipline that turns AI factor lookup from a liability into a genuine accelerator is simple to state and must be applied without exception: the model may help you find and shortlist a factor, but the factor that enters the inventory must be confirmed in the named database itself, and its full provenance tag must be recorded. The model is a research assistant pointing you at a shelf, never the shelf. Here is how that works in practice.

Ask for the source, not just the number. Never prompt "what is the emission factor for X." Prompt "what emission factor would apply to X, and tell me the specific database, version, year, unit, and geography I would need to confirm it in." This reframing does two things: it gets you a candidate plus the exact place to verify it, and it surfaces immediately when the model cannot name a source, which is itself the answer that you must not use that number.

Confirm in the database, not in the chat. Take the candidate provenance and open the actual factor set. Find the specific row. Confirm the number, the unit, the year, and the geography match what you intend to use. Only the confirmed-in-source value enters the inventory. The model's number was a pointer; the database's number is the factor. If the model's value and the database's value disagree, the database wins, every time, with no exception and no rounding the difference away.

Record the tag so it travels. Once confirmed, the factor never again appears in the file as a bare number. It appears with its provenance tag attached, database and version and year and unit and geography, so that anyone, including a future you and an external assurer, can re-confirm it without re-doing the research. The tag is not paperwork; it is the difference between a defensible factor and an indefensible one, and it costs almost nothing to record at the moment of confirmation and almost everything to reconstruct later.

Treat a missing source as a hard stop. If the model cannot name a database, or names one that does not contain the number when you check, the factor does not enter the inventory. There is no version of "the AI was probably right" that survives an assurance engagement. A gap you cannot source is a gap you disclose or fill from a real source, never a gap you let the model paper over with a confident guess.

A Worked Example: One Factor, Two Ways

Watch a single, real task go two different ways with the same AI assistant. The company burned 4,200,000 kWh of natural gas in its UK facilities this year, a Scope 1 figure traced cleanly to twelve months of gas bills. The accountant needs the emission factor to convert kWh into tonnes of CO2e.

Before (the unsourced shortcut, what almost shipped): The accountant asks, "What is the emission factor for natural gas?" The model answers, "Approximately 0.184 kg CO2e per kWh." The accountant multiplies: 4,200,000 kWh times 0.184 gives 772,800 kg, booked as 773 tonnes CO2e of Scope 1. It looks finished. But the factor entered the file with no database, no version, no reference year, and no confirmation that 0.184 is the gross calorific value figure rather than the net, a distinction that alone changes the answer by several percent. When the assurer asks "where is 0.184 from," the honest answer is "the AI said so," which is no provenance at all. The 773 tonnes is now an audit finding, and because the same loose method was used across the inventory, the finding does not stay contained to one line.

After (the sourced, tagged build): The accountant prompts instead, "I need the emission factor for natural gas combustion in the UK for this reporting year. Tell me the specific database, version, year, unit, and geography I should confirm it in." The model responds that the appropriate source is the relevant UK government greenhouse-gas conversion-factor set for the reporting year, that natural gas is listed by both gross and net calorific value, in kg CO2e per kWh, for the UK, and that the gross CV figure is the one to use against billed kWh. The accountant opens that published factor set, finds the natural gas row, and confirms the exact value, the unit (kg CO2e per kWh, gross CV), the publication year, and the geography (UK). Suppose the confirmed value is 0.18293. The accountant uses the confirmed value, not the model's rounded 0.184, and books the line with its tag: factor 0.18293 kg CO2e/kWh (gross CV); source: UK Government GHG conversion factors, 2026 edition; reference year 2026; geography UK; confirmed in source. The emissions come to 768.3 tonnes. The difference from the unsourced version is small in tonnes and total in defensibility. When the assurer asks "where is this factor from," the accountant shows the database, the version, the row, and the confirmation. The number is no longer a story; it is evidence.

That is the entire discipline in one comparison. The same model, the same activity data, the same one-second convenience, produces either a bare number that fails on the first question or a tagged factor that answers the question before it is asked. The accountant chooses which, by refusing to accept any factor that does not trace to a named, dated, authoritative source, and by making the provenance tag travel with the factor for the rest of the file's life.

Working Rules for AI-Assisted Factor Lookup

A short set of rules keeps AI on the right side of the line and lets you use it hard for the part it is good at. Use AI to shortlist candidate factors and to tell you where to confirm them, because that is fast and verifiable. Never accept the model's number as the factor; the database's number is the factor. Always ask for database, version, year, unit, and geography in the same breath as the number, so a missing source surfaces immediately. Confirm every factor in the actual source before it enters the inventory, and use the source value, not the model's recollection of it. Record the full provenance tag the moment you confirm, so it travels with the factor and never has to be reconstructed. Watch the units like a hawk, because a kWh-versus-MWh or gross-versus-net slip is a silent order-of-magnitude error. Match the geography to where the activity happened, not to where your headquarters sits. Treat a fabricated or unverifiable citation exactly as you treat a hallucinated number, because a false provenance tag is worse than none. And treat any factor the model cannot source as a hard stop, never a "probably fine." Follow these and AI gives you a faster path to a clean factor library with provenance baked in. Ignore them and AI gives you a faster path to a restatement.

Key Takeaways

• Every inventory line is activity data multiplied by an emission factor; the factor is the most dangerous input because one wrong factor silently multiplies error across an entire category and into the headline footprint.
• Provenance for a factor is a structured tag with five parts: database, version, year, unit, and geography. A factor missing any of these is not sourced; it is a number with a story.
• Authoritative sources fall into recognisable categories: national GHG inventory databases, government factor sets in the DEFRA or EPA style, LCA databases in the ecoinvent style, and IEA-style energy factors. Each is named, versioned, dated, and documented.
• The hallucinated factor is fluent, plausible, and unsourced or falsely sourced; the third deception, an invented but real-sounding citation, is the cruelest because it can fool a reviewer who checks that a source exists but not that the number lives in it.
• The rule is absolute: the model may shortlist a factor and point you to a source, but the factor that enters the inventory must be confirmed in the named database itself, and the database value wins over the model's recollection every time.
• Watch units and geography relentlessly; a kWh-versus-MWh slip or a wrong-country grid factor can move a number by a factor of ten with no visible warning.
• The provenance tag must travel with the factor for the rest of the file's life, so any reviewer or assurer can re-confirm the number without re-doing the research or needing you in the room.
• When an assurer asks for the provenance of a factor, you show the database, version, year, unit, geography, and the confirmed row in the source; "the AI suggested it" is not provenance and not a defense.