A disclosure lead is in a contract review when the vendor's account manager says the sentence that should set off every alarm in the room: "Don't worry about the emission factors, the platform keeps them current for you, it's all handled." It sounds like a feature. It is, quietly, a transfer of the one thing that must never leave your hands. Twelve months later an assurer asks why a particular factor changed between reporting years, who approved the change, and on what basis, and the honest answer is that nobody inside the company knows, because the platform updated it overnight and no one was watching. The number was published under the company's name, assured under the company's engagement, and defended by no one. This lesson is about the obligations that do not transfer to the platform, and how to keep factor governance in-house when the tool is external.

The Obligation Does Not Move When the Work Does

The most expensive misunderstanding in reporting AI is treating a platform as a place to put a responsibility down. You can outsource the work of looking up a factor, parsing a supplier file, or drafting a narrative. You cannot outsource the accountability for the result. When a number appears in your sustainability statement, it is your number. The assurer holds you to it under the engagement, and a regulator can reopen the filing and hold you to it under the law. "The platform calculated it" is no more a defense than "the AI estimated it." The vendor faces none of the consequences of a misstatement; you face all of them. That asymmetry is the whole reason governance has to stay where the accountability is.

This is not an argument against buying tools. Tools are good and necessary. It is an argument for being precise about what the tool is for. A platform is a place where work happens faster under your governance, not a place where your governance ends. The failure mode is silent and seductive: the platform handles more and more, the team watches less and less, and one day the company is publishing assured numbers whose basis it cannot explain because the explanations live inside a vendor's black box. The discipline is to keep, deliberately and contractually, the obligations that are yours, while letting the tool carry the labor that is genuinely transferable.

You can hand a platform the work. You cannot hand it the accountability. Every number it produces is published under your name, assured under your engagement, and defended by you alone.

The Four Obligations That Stay In-House

Four responsibilities must never sit with the vendor, no matter how capable the platform. Naming them precisely is the start of governing them.

One: Emission-Factor Governance

An emission factor is the coefficient that converts activity data into emissions, and which factor you use, from which source, of which version, is a methodological choice with disclosure consequences. Factor governance is the in-house control over that choice: an approved factor library, a documented basis for each factor, a change-control process when factors are updated, and a named owner. When a vendor "keeps factors current for you," it is making your methodological choices invisibly, and a silent factor change between years can move a number, break comparability, or trigger a restatement, all without your knowledge. The control is to own the factor library yourself: you decide which factors are approved, you record why, and any change, whether the vendor proposes it or not, passes through your change-control and your sign-off before it touches a published number. The platform may suggest and apply factors from your approved library; it may not be the library.

Two: Data Ownership

The activity data, the supplier responses, the source documents, and crucially the lineage that ties numbers to their origins, are your assets, not the vendor's. Data ownership means you retain the right and the practical ability to hold, export, and reuse all of it, including the provenance, in a form that survives leaving the platform. The danger is the platform that ingests your data and returns it only as dashboard views, so that the moment you switch tools or an assurer wants history from a system you no longer use, the lineage is gone. Own the data and its provenance contractually and technically: full export on demand, full export on exit, in a readable standalone form, with the primary and secondary tags and the factor sources intact. A number whose evidence you cannot take with you is a number you do not really own.

Three: The Basis-of-Preparation

The basis-of-preparation is the document that states how the report's numbers were produced: the boundaries, the methods, the factor sources, the estimation approaches, the assumptions. It is the spine the assurer follows, and it is a statement the company makes about its own methodology. A vendor cannot write your basis-of-preparation for you, because it is your methodological narrative, not theirs, and an assurer reads it as the company's own account of its choices. A platform can supply inputs to it, the factor versions it applied, the methods it used, but the company authors, owns, and stands behind the document. If the basis-of-preparation is effectively whatever the platform did by default, the company has let a vendor define its methodology, which is exactly what an assurer will probe and what a regulator will not accept.

Four: Accountability for the Number

Someone inside the company signs the statement, and accountability for every figure in it traces to a human in the organization, not to a tool. This is the obligation that anchors the other three, because factor governance, data ownership, and the basis-of-preparation are all expressions of a company standing behind its numbers. The platform is a participant in producing the number; it is never the party accountable for it. The practical test is simple and uncomfortable: for any number in the report, can a named person in the company explain how it was produced and why, without saying "the platform did it"? If the only available explanation is the vendor's, accountability has quietly migrated to a party that does not bear it, and the company is exposed.

Keeping Governance In-House: Contractual and Operational Controls

Naming the obligations is not enough; you have to build controls that keep them home. They come in two layers: what you write into the contract, and what you run day to day.

Contractual Controls

The contract is where you stop the silent transfer before it starts. Insist on data ownership and full portability: your data, your lineage, and your provenance are yours, exportable on demand and on exit in a standalone, readable form, with tags and sources intact. Insist on factor transparency and change control: the platform must disclose the source, version, and date of every factor it applies, must not change factors silently, and must surface any proposed change for your approval. Insist on audit-trail export, so the assurance file does not depend on a vendor login. Insist on access for your assurer to whatever they need to reconstruct a number. And be wary of contract language that implies the vendor "manages" or "ensures" the accuracy or compliance of your disclosures, because that framing invites the dangerous belief that the obligation has moved, when legally and practically it has not.

Operational Controls

Day to day, the controls are about keeping a human in the loop on the things that are yours. Maintain your own approved factor library and run factor changes through your change-control with a named owner, regardless of what the platform offers to do automatically. Review and sign off on factor updates rather than letting them apply silently. Keep your own copy of source data and lineage, so your evidence does not live only inside the vendor. Author your basis-of-preparation as a company document, using the platform's outputs as inputs but never as the whole. And run the uncomfortable test regularly: pick a number, and confirm a named person can explain it without deferring to the tool. These controls feel like friction, and they are, but they are the friction that keeps the company able to defend its own disclosures.

The RACI of Factor Governance When the Tool Is External

The clearest way to stop obligations from drifting to a vendor is to write down, before the platform goes live, who is Responsible, Accountable, Consulted, and Informed for each part of factor governance. A RACI is not bureaucracy here; it is the artifact that makes "the platform handles it" impossible to say without someone noticing. The governing insight is simple and rarely violated on paper yet constantly violated in practice: the vendor may be Responsible for doing work, but the company is always Accountable for the result. Accountability is the one cell in the matrix that can never carry a vendor's name.

Work through the four core activities. For maintaining the approved factor library, the company is Accountable and its named factor owner is Responsible; the vendor is Consulted, because it can propose and surface candidate factors, but it does not decide what is approved. For applying a factor to a calculation, the vendor's platform can be Responsible for the mechanical application, but only of factors from the company's approved library, and the company remains Accountable. For approving a factor change, the company's factor owner is both Responsible and Accountable, the vendor is Consulted, and the assurer is Informed. For authoring the basis-of-preparation, the company is Responsible and Accountable and the vendor is at most Consulted as a supplier of inputs. The pattern is consistent: work can move to the vendor, decisions and accountability cannot.

The last row is the anchor. No vendor cell appears against signing the disclosure, because the signature is the physical embodiment of accountability, and it is a person inside the company who puts their name to the statement. When a RACI has any vendor entry drifting into the Accountable column, that is the early warning that the company is about to publish numbers it cannot defend. Reviewing the matrix at the start of the engagement, and again at each contract renewal, keeps the drift visible while it is still cheap to correct.

Contractual Clauses That Keep Provenance and Ownership In-House

A RACI describes the intended division of labor; the contract is what makes it enforceable when the vendor's incentives pull the other way. Vendors are commercially motivated to increase switching costs, and the quiet way to do that is to hold your data and your lineage inside their system. Specific clauses stop that before it starts. Treat the following as the non-negotiable spine of any reporting-AI contract.

Data and Provenance Ownership

State explicitly that all data the company supplies or generates through the platform, including activity data, supplier responses, source documents, and the lineage tying numbers to sources, remains the company's property. Ownership language must reach the provenance, not just the raw inputs, because a vendor can concede that your invoices are yours while treating the lineage it built as its proprietary output. If the lineage is not contractually yours, the evidence that makes your numbers defensible is not yours.

Export and Portability, On Demand and On Exit

Require full export of data and lineage on demand during the engagement and, critically, on exit, in a standalone, readable, non-proprietary format with primary and secondary tags and factor sources intact. The exit clause matters most: a portability right that evaporates when you terminate is worthless precisely when you need history from a system you are leaving. Specify the format and the completeness, or you will receive a dashboard screenshot and a dead login.

Factor Transparency and Change Control

Oblige the vendor to disclose the source, version, and date of every factor it applies, to never change a factor silently, and to surface any proposed factor change to the company for approval before it touches a published number. This clause is the direct contractual counter to "the platform keeps them current for you." It converts a silent automatic update into a proposal that must pass through your change-control.

Audit-Trail Export and Assurer Access

Require that the audit trail be exportable offline so the assurance file never depends on a vendor login, and grant your assurer access to whatever they need to reconstruct a number. Add a clause obliging the vendor to support, not obstruct, an assurance engagement.

Language to Strike Out

Be as careful about what you remove as what you add. Delete or push back on any clause implying the vendor "manages," "ensures," or "guarantees" the accuracy or compliance of your disclosures. That framing is comforting and legally hollow: it cannot actually transfer your regulatory and assurance obligations, but it can seed the dangerous internal belief that it did. The obligation stays with you regardless of the marketing verb; the only thing such language changes is how surprised your team is when the assurer arrives.

The Emission-Factor Version-Control Obligation

Of all the in-house obligations, factor version control is the one most often lost to a platform and the one most reliably surfaced by an assurer, so it deserves its own treatment. An emission factor is not a constant; authoritative databases revise their coefficients as science and methodology improve, and each revision is a new version with a date. The obligation is to treat every factor the way finance treats a general-ledger entry: known version, known source, known date, known approver, and a preserved history of what was used in each reporting period.

Version control matters for three reasons the assurer will test. First, comparability: if a factor changes between years, a number can move on unchanged activity, and the company must be able to show whether a year-on-year shift came from real activity or from a factor revision. Second, reconstructability: to rebuild a prior-year number, you need the exact factor version used at the time, not today's version, which means you must retain the historical factor, not just the current one. Third, restatement discipline: when a factor change is material, it may require a disclosed restatement with a clear basis, and you cannot restate cleanly what you never versioned.

The practical control is a factor register the company owns, in which each factor carries its source, version, date, approver, effective reporting period, and rationale, and in which superseded versions are retained rather than overwritten. The platform may apply factors from this register, but the register is the company's system of record, not the vendor's. The test of whether you truly control versions is uncomfortable and precise: pick any published number from two years ago and ask whether you can name the exact factor version behind it and produce the approval. If the honest answer is "whatever the platform had at the time," you do not have version control, you have a vendor's changelog you cannot see.

A Worked Example: A Silent Factor Change Meets the Assurer

Walk a concrete scenario through both a governed and an ungoverned setup, to see where the obligation lands.

The setup. A company reports Scope 3 Category 1 emissions for purchased steel. Last year the platform applied a factor of 2.1 tonnes CO2e per tonne of steel. This year, the platform's factor library updated, and it now applies 1.8 tonnes CO2e per tonne. Reported emissions for that line fall by roughly 14% on an unchanged volume. The assurer, comparing years, asks the obvious question: why did this number drop when production did not?

The ungoverned setup. The vendor "kept factors current," so the change happened automatically and no one inside the company noticed. Asked why the factor changed, the team cannot say which database version drove it, when it changed, who approved it, or whether it is appropriate for their steel. The honest answers are: we don't know, the platform did it. To the assurer this is a methodology the company does not control and cannot explain, which is an assurance finding. Worse, the unexplained drop looks like exactly the kind of convenient, undocumented change that reads as greenwashing, and the company cannot prove it was anything else. The factor change may have been entirely legitimate. The company simply has no way to demonstrate that, because it governed nothing.

The governed setup. The company owns its factor library. When the vendor surfaced the proposed update from 2.1 to 1.8, it entered the company's change-control: the named factor owner reviewed the new factor's source, version, and date, confirmed it reflected an updated authoritative database appropriate to the company's steel, recorded the rationale, and signed off, noting the comparability impact for disclosure. When the assurer asks why the number dropped, the team answers in two sentences with a document: the factor was updated from this dated source to this dated source, here is the approval and the basis, and here is the comparability note in our basis-of-preparation. Same factor change, same number, completely different outcome. In one setup the change is a finding; in the other it is a documented, defensible methodological decision. The difference is not the platform. It is who governed the factor.

Why the Friction Is the Insurance

It is tempting to accept the vendor's offer to handle factors, because handling them yourself is work, and the platform's automation is genuinely faster. But the speed of an ungoverned factor is borrowed against a future finding. The moment a number is questioned, and under assurance numbers get questioned, the company that governed its factors answers in minutes and the company that did not cannot answer at all. The in-house controls are not bureaucracy for its own sake; they are the mechanism by which a company remains able to stand behind numbers published under its name. The platform carries the labor; the company keeps the obligation; and the controls are simply the line between the two, drawn on purpose and held.

An Audit-of-the-Vendor Checklist

Governance is not a one-time contract event; it is a posture you verify on a schedule. Once a platform is embedded, run a periodic audit of the vendor against the obligations that must stay home, ideally annually and always before an assurance cycle. The checklist below turns the abstract principle into a set of questions with observable answers. Score each row as verified, partial, or failed, and treat any failed row on a factor, provenance, or export item as a governance defect to remediate before the next disclosure, not a note for later.

The final two rows are the ones that most often expose a quiet drift. If no named person can walk back a sampled number without opening the vendor's product, accountability has already migrated in practice even if the contract says otherwise. And if any live document still says the vendor "ensures compliance," the belief that the obligation moved is one renewal away from becoming the team's working assumption. Auditing the vendor is, in the end, auditing your own governance: the platform is the mirror in which you check whether the obligations you promised to keep are still where you left them.

Key Takeaways

• You can outsource the work of producing a number to a platform, but you cannot outsource the accountability for it; the platform calculated it is no more a defense than the AI estimated it.
• Four obligations never transfer to the vendor: emission-factor governance, data ownership, the basis-of-preparation, and accountability for the number, and the fourth anchors the other three.
• Factor governance means owning your approved factor library, documenting the basis for each factor, and running every change, vendor-proposed or not, through your change-control and sign-off; the platform may apply factors from your library but may not be the library.
• Data ownership means retaining the practical right to hold, export, and reuse all data and its lineage in a standalone form that survives leaving the platform, with primary and secondary tags and factor sources intact.
• The basis-of-preparation is the company's own methodological narrative, which the vendor supplies inputs to but never authors; a methodology defined by platform defaults is one the company has effectively let a vendor write.
• Contractual controls lock in data ownership and portability, factor transparency and change control, audit-trail export, and assurer access, and avoid language implying the vendor manages or ensures the accuracy of your disclosures.
• Operational controls keep a human in the loop on what is yours: your factor library, signed-off factor changes, your own copy of data and lineage, a company-authored basis-of-preparation, and the regular test that a named person can explain any number without deferring to the tool.
• Write a RACI before the platform goes live: the vendor can be Responsible for work, but the company is always Accountable, and no vendor cell may ever appear against signing the disclosure.
• Contractual clauses are what make governance enforceable: data and provenance ownership, export and portability on demand and on exit, factor transparency and change control, audit-trail export and assurer access, and the deletion of any wording implying the vendor ensures accuracy or compliance.
• Factor version control is the most-lost and most-tested obligation: keep a company-owned factor register with source, version, date, approver, and rationale, retain superseded versions, and be able to name the exact factor behind any prior-year number.
• In the worked example a silent factor change from 2.1 to 1.8 is an unexplained 14% drop and an assurance finding when ungoverned, and a documented, defensible decision when the company owns the factor; the difference is governance, not the platform.
• Audit the vendor on a schedule against a checklist with observable evidence; the tells of quiet drift are a number no named person can walk back without the tool and any live wording that says the vendor owns compliance.