The reason supplier carbon data collection fails is rarely the suppliers. It is the container the data travels in. A spreadsheet emailed to eighty suppliers comes back as eighty different spreadsheets: renamed columns, pasted-over formulas, units changed midway, and no record of who changed what. The collection round ends, and the work of reconciling it all begins, which is where the quarter goes.
Most sustainability teams know this cycle by heart. Send the template in March. Chase through April. Reconcile in May. Discover in June that a third of the responses used the wrong reporting period, and start the follow-up round. By the time the numbers reach a report, nobody can say with confidence which file version a given figure came from.
That last sentence is the part that matters for anyone facing CSRD or third-party assurance. The problem is not only that spreadsheets are slow. It is that they destroy provenance.
What an assurer will actually ask
Third-party assurance of Scope 3.1 or a product carbon footprint comes down to a chain of questions. Where did this number come from? Who supplied it, and when? What reporting period does it cover? Was it primary data from the supplier's own operations or a secondary factor from a database, and if secondary, which database and which version? What changed between the draft and the final figure?
A spreadsheet trail answers none of these cleanly. An inbox full of "PCF_template_v3_FINAL_revised.xlsx" is not an audit trail, it is an archaeology project.
Regulation is moving the same direction. ESRS E1 asks companies to disclose the share of Scope 3 calculated from primary data. You cannot report that share defensibly if primary and secondary inputs are blended in cells with no source labels.
The workflow that survives audit
The fix is less about software category and more about four properties. Any collection process that has them will hold up; any process missing them will eventually be rebuilt.
One request, one record. Each supplier data request is a tracked object with an owner, a due date, and a status, more like a ticket than an email. When the response arrives, it attaches to that record permanently. Six months later, the question "where did this number come from" has a one-click answer.
Evidence bound at the moment of intake. The supplier's submission, whether a PCF report, a utility bill, or a completed form, is stored as the document it arrived as, hashed and versioned. The number extracted from it points back to it. If the supplier revises the figure, the old version stays in the chain with a timestamp instead of being pasted over.
Primary and secondary data labeled at entry, not at reporting time. Every value carries its classification from the moment it enters. The ESRS primary-share disclosure then falls out of the data instead of being reconstructed under deadline.
Gaps treated as work items. A missing supplier response is not a blank cell; it is an open item with an owner and an age. This is the difference between a dashboard, which tells you the average, and an inbox, which tells you what to do next. Collection programs run on the second kind of tool.
What to ask suppliers for, in order
Teams often stall by asking every supplier for a full PCF on day one. A staged request ladder gets more back with less friction:
First, activity data they already have: electricity consumption, fuel use, production volumes for the relevant period. Most suppliers can export this in an afternoon, and it upgrades your estimate from industry-average to supplier-specific.
Second, existing certificates and reports: an energy audit, an EPD, a PCF they produced for another customer. Documents they have already paid for cost them nothing to share.
Third, and only where the spend justifies it, a product-level PCF against a stated standard such as ISO 14067 or the PACT methodology, with its calculation boundary documented.
Each rung is also a piece of evidence in its own right, which is the quiet advantage of collecting this way: the request history itself demonstrates the good-faith engagement that regulators and assurers increasingly expect to see.
The spiral, named
The spreadsheet spiral is a provenance problem wearing a productivity costume. Faster spreadsheets, better templates, and stricter naming conventions all treat the symptom. The cure is a collection process where every number stays attached to its source document, its version, its classification, and its requester from intake to report.
That is the principle CarbonSKU is built around, an evidence ledger rather than a collection folder. But the principle stands on its own, whatever tooling you use: if you cannot replay where a supplier number came from, you do not really have it yet.