It is March, and a carbon accountant is staring at a problem that did not exist last week. The emission-factor database she relies on has just published its annual update, and the electricity grid factor for one of her largest operating countries dropped by 9% because the underlying grid decarbonised. That is good news for the planet and a headache for the file, because last year's published Scope 2 number used the old factor, this year's will use the new one, and somewhere a comparison is going to look like the company suddenly improved when really the factor moved. Worse, the AI-assisted prompt template her team used to draft last year's methodology note has been edited three times since, so she can no longer be sure which version of which instruction produced the figure that sits in the published report. The assurer is going to ask her to reconstruct last year's number exactly. Without versioning, that request is a crisis. With it, it is a Tuesday.

Why a Disclosed Number Is Never Just a Number

A figure in a sustainability disclosure looks like a single value, but it is the visible tip of a stack of choices, each of which can change between periods. The published Scope 2 figure depends on the activity data (the kilowatt-hours), the emission factor applied to them, the method used to source that factor (location-based or market-based), the boundary that decided which sites were in scope, and, increasingly, the AI prompt or template that helped draft or calculate it. Change any layer and the number can move without any change in the real-world emissions at all. This is the trap of disclosure: a number that moved because a factor was revised looks, on the page, exactly like a number that moved because the company emitted differently. Only the version history can tell them apart.

This matters because sustainability reporting is inherently comparative. A disclosure is not a snapshot; it is one point in a trend, measured against a baseline, judged against targets, and read year over year by investors, regulators, and assurers who care intensely about whether a change is real. The whole edifice of climate target-setting rests on comparability: a company claiming a 30% reduction against a 2020 baseline is making a claim that only means something if the 2020 number and today's number were built the same way, or if every difference in how they were built is documented and explained. The moment you cannot say why this year differs from last year, your trend is unassurable and your target claim is exposed.

AI sharpens this problem rather than softening it. When a prompt, a template, or a grounded knowledge base is part of how a figure was produced, it becomes one more layer that can silently change. A model updated, a prompt reworded, a factor file swapped underneath a retrieval system: any of these can alter an output while the workflow looks unchanged. If you cannot pin down which version of every input produced a published number, you cannot reconstruct it, and a number you cannot reconstruct is a number you cannot defend.

The Versions You Must Track

Versioning in a reporting context means keeping a dated, identifiable record of each layer that feeds a disclosed figure, so that any published number can be tied to the exact versions of everything that produced it. Four families of version matter most.

Data versions

Data versions track the activity data and source records themselves. A utility bill is restated, a supplier resubmits a corrected figure, a meter reading is found to be misread: the activity data underneath a figure changes. You need to know which version of the underlying data a published number used, and when a later correction arrived, so you can tell whether a movement came from better data or from real change. The principle is that source data is dated and never silently overwritten; a correction is a new version that sits beside the old one, not on top of it.

Factor versions

Factor versions track the emission factors and their releases. Factor databases publish annual or periodic updates, and a factor's value, its reference year, and even its method can change between releases. Every factor in a published inventory must carry which release of which database it came from, so that when the database updates, you can see exactly which lines would move and by how much. The 9% grid-factor drop in the opening scene is invisible and dangerous without factor versioning, and a documented, expected movement with it.

Method versions

Method versions track the calculation methods and the choices behind them: spend-based versus activity-based for a Scope 3 category, location-based versus market-based for Scope 2, the boundary and consolidation approach, the estimation method for a gap. A method change is one of the most consequential things that can happen to a number, because it can move a figure substantially while every input stays the same. Method versioning records not just the current method but when it changed and why, because a method change between periods is itself a disclosure that the assurer will expect to see explained.

Prompt, template, and model versions

In an AI-assisted workflow, the prompt, template, and model versions are a real layer. The system prompt that constrains the model, the template that structures an extraction, the version of the model itself, and the knowledge base it retrieves from all shape the output. Treat them as versioned inputs: a dated prompt library, a recorded model version, a versioned knowledge base, so that you can say which configuration produced a given output. This is not paranoia; it is the same discipline you apply to a spreadsheet formula, extended to the AI components that now sit in the workflow.

A number you cannot reconstruct is a number you cannot defend. Versioning is the practice of making every published figure rebuildable from the exact data, factor, method, and prompt that produced it, so that next year you can prove not just what the number was, but why it was that and not something else.

What Restatement Means and Why It Is Normal

A restatement is a formal revision of a previously published figure. It happens when you discover that a prior-period number was wrong, or when a change in method or boundary means the prior number is no longer comparable to the current one and must be recalculated on the new basis so the trend stays honest. Restatement is not an admission of failure; in mature financial reporting it is a routine, governed event, and sustainability reporting is converging on the same posture as assurance deepens. A company that restates a figure cleanly, with a clear explanation of what changed and why, demonstrates control. A company that quietly changes a prior number, or cannot explain why this year does not match last year's published figure, demonstrates the opposite.

The difference between those two outcomes is almost entirely versioning. Consider a method change: this year the team moves a Scope 3 category from a spend-based estimate to a more accurate activity-based calculation. That is an improvement, but it breaks comparability, because the prior year used the old method. The honest response is to restate the prior year on the new method (or at minimum disclose the break and quantify it), so that the trend reflects real change rather than a method artifact. To do that, you have to be able to rebuild the prior year with the new method, which means you needed the prior year's data versions, factor versions, and method documentation preserved. Versioning is what makes the restatement a controlled recalculation instead of a guess.

This is the line that turns a restatement from a crisis into a process. The crisis version: a regulator or assurer flags that a published number looks wrong, the team cannot reconstruct how it was built, cannot isolate what changed, and ends up restating in a panic with a vague explanation that invites more scrutiny and reads, externally, like a greenwashing correction. The process version: the team already holds the full version history, can rebuild the prior number exactly, can isolate precisely which layer changed (a factor release, a method, a data correction), can quantify the effect, and can restate with a clean, specific explanation that demonstrates control rather than confessing chaos. Same underlying event, opposite consequence, and the only difference is whether the versions were tracked.

Defining the Restatement Trail

The restatement trail is the documented record that connects a revised figure back to the original, explaining what changed, why, and by how much. It is to a restatement what the handoff log is to a verification: the artifact that makes an otherwise invisible event provable and controlled. A workable restatement trail captures, for each restated figure, a defined set of elements.

The trail's power is that it lets the company tell the difference, in public, between the two kinds of change that look identical on the page. When the grid factor dropped 9%, the restatement trail records: layer changed, factor version; reason, factor database annual release; quantified effect, Scope 2 down X tonnes attributable entirely to the factor revision, not to any change in consumption. That single explanation converts a suspicious-looking improvement into a documented, expected one, and it is exactly the explanation an assurer needs to wave the movement through. Without the trail, the same movement is an unexplained drop that invites the assurer to pull every thread behind it.

A Worked Example: The Grid Factor Drop, Two Ways

Return to the carbon accountant in March, and run her year both ways.

Without version control

Last year's inventory recorded grid factors as bare numbers, with no note of which database release they came from. The AI prompt template that helped draft the methodology has been edited repeatedly with no version history. This year the team applies the updated factors, and the consolidated Scope 2 number falls noticeably. In the report, the drop appears as an improvement, and someone in investor relations is tempted to tell that story. Then the assurer asks the unavoidable question: reconstruct last year's number and explain this year's movement. The team cannot pin last year's factors to a release, cannot say which prompt version produced the methodology note, and cannot cleanly separate the part of the drop that is the factor revision from any part that is real. They restate in a hurry, with a fuzzy explanation, and the assurer, now uncertain whether anything else in the file is similarly untraceable, widens the scope of testing. A routine factor update has become an engagement-wide problem.

With version control

Last year's inventory recorded every factor with its database release, year, unit, and geography. The prompt template was versioned. This year, before publishing, the team runs the comparison deliberately: holding consumption constant, they apply the new factor release and see exactly the 9% grid movement, isolated and quantified. They decide to restate the prior-year comparison figure on a like-for-like basis and document it in the restatement trail: original figure, restated figure, layer changed (factor version, named release), reason (annual database update reflecting grid decarbonisation), quantified effect (the precise tonnes attributable to the factor, with consumption flat), signed by the named owner, dated. The published report now shows the movement with its cause attached, so a reader can see what is real change and what is factor revision. When the assurer asks, the answer is the trail. The factor update is a documented Tuesday, not a crisis, and the team's credibility on every other number goes up, not down, because they just demonstrated exactly the control the assurer was hoping to find.

The two versions of her year are not separated by effort or intelligence. They are separated by whether, a year earlier, the team recorded which release each factor came from and versioned the prompt that helped draft the note. That small discipline, applied before anyone knew it would matter, is what stands between a controlled recalculation and a panicked one.

Building Version Control Into the Workflow

Version control is not a heroic year-end reconstruction; it is a habit baked into the workflow so that the history accumulates on its own. The operating principles are few and strict. Date and identify every version of every layer the moment it enters the workflow: each data submission, each factor release, each method choice, each prompt and model configuration. Never overwrite; a correction or update is a new version that sits beside the old one, so the prior state is always recoverable. Tie every published figure to the specific versions that produced it, so reconstruction is a lookup, not an investigation. And govern restatement explicitly: a named owner decides it, the restatement trail records it, and the change is disclosed with its cause and magnitude rather than slipped in.

For the AI layer specifically, this means maintaining a versioned prompt and template library, recording the model version used for material outputs, and versioning the grounded knowledge base so that a retrieval-based answer can be tied to the exact evidence base it drew from. The reward for all of this is reconstructability, which is the quiet foundation of the entire assurance relationship. An assurer's deepest question is always some form of "can you rebuild this number without me having to trust your memory," and a versioned workflow answers yes by default. The same discipline that lets you survive the factor update lets you survive the method change, the data correction, the model upgrade, and the regulator who reopens a filing two years later. Versioning is unglamorous, it costs a little at every step, and it is the difference between owning your numbers and merely having published them.

Key Takeaways

• A disclosed figure is the tip of a stack of choices: activity data, factor, method, boundary, and increasingly the AI prompt or knowledge base. Change any layer and the number can move without any change in real-world emissions.
• Sustainability reporting is inherently comparative, judged against baselines and targets year over year. The moment you cannot say why this year differs from last, your trend is unassurable and your target claim is exposed.
• Track four families of version: data versions, factor versions (which database release), method versions (and when and why they changed), and prompt, template, and model versions for the AI layer.
• A restatement is a formal revision of a previously published figure, triggered by a discovered error or a method or boundary change that breaks comparability. It is a normal, governed event, not an admission of failure.
• The difference between a clean restatement that demonstrates control and a panicked one that invites scrutiny is almost entirely versioning, because only version history lets you rebuild the prior number and isolate what changed.
• The restatement trail records the original figure, the restated figure, the layer changed, the reason, the quantified effect, the named approver, and the date, so the company can tell the public the difference between a real movement and a methodological one.
• The same factor update is a crisis without versioning and a documented Tuesday with it, and the difference was a small discipline applied a year earlier, before anyone knew it would matter.
• Build version control into the workflow as a habit: date and identify every version, never overwrite, tie every figure to its exact inputs, and govern restatement explicitly. The reward is reconstructability, the quiet foundation of the assurance relationship.