In short
- A broken carbon spreadsheet is almost always a versioning problem, not a formula problem.
- Freeze the file, find the version behind the number you published, and reconcile to that.
- Separate the three jobs the file was doing: collecting data, holding factors, reporting.
A carbon spreadsheet almost never crashes. It stops agreeing with itself: a total that no longer includes the new rows, a factor tab somebody updated in June, a site reporting in kWh next to one reporting in MWh, and a company figure that no longer matches what you sent a customer in March. This week, do three things: freeze the file, identify the exact version behind the last number you published, and reconcile the current total to it. What stops a recurrence is separating the three jobs the file was doing at once, collecting data, storing emission factors, and producing a reported figure.
Nobody built a bad spreadsheet on purpose. They built a small one that worked, and then the business added sites, years and people to it.
What has actually broken?
Six failures cover almost every case. Work down the list in order, because the early ones are the ones that change the number.
| Symptom | Usual cause | Check this first |
|---|---|---|
| Total moved but no data was added | Someone edited the emission factor tab mid-year | Version history on the factor tab |
| Two teams quote different totals | Copies of the file diverged months ago | Which file produced the figure you published |
| Recent rows missing from the total | A sum formula bound to a fixed range | The last row of every source range |
| One site is out by a factor of a thousand | Units mixed, kWh against MWh, kg against tonnes | The unit column on that site's tab |
| Nobody can explain last year's number | No method record, and the author has left | Whether any note of the boundary exists |
| The file is slow or links are broken | Volume beyond what a spreadsheet handles | Row count and external workbook links |
The most damaging of these is the first, because it is silent. Data errors get spotted. A quietly updated factor changes the whole series and looks like a real trend.
What do you do this week?
Five steps, in this order. It takes a day, not a project.
Freeze it. Save a copy named for today and stop editing the original. Everything else depends on having an unchanged reference.
Find the published version. Locate the file, or the email attachment, behind the number you last gave a customer, an auditor or a tender. That figure is the one with commercial consequences, so it is the anchor.
Reconcile. Compare the frozen file's total to the published total and list every difference by source. You are not fixing anything yet, only measuring the gap.
Classify each difference. Either the old number was wrong, or the new number is wrong, or the method changed. Those three demand three different responses, and mixing them up is what turns a small correction into a credibility problem.
Decide who needs telling. If a published number was materially wrong, say so early with the corrected figure and the reason. Late disclosure of a small error costs more than early disclosure of a large one.
How do you tell whether the published number is still defensible?
Ask four questions about it. If you can answer all four in writing, the figure stands even if the spreadsheet does not.
Which organisational boundary did it use, and which entities and sites were in it? Which emission factor set, from which source and which year? Which activities were measured, which were estimated, and how? And who checked it before it went out?
A number you can answer those four questions about is defensible with an apology and a correction. A number you cannot is a number to rebuild rather than to defend, and it is better to know that now than during a procurement challenge. If you need to rebuild from first principles, our beginner's guide to carbon accounting walks through the steps in order.
Should you repair the spreadsheet or move off it?
Repair it if the answer to all of these is yes: one person owns it, one site or entity is in it, the row count is in the hundreds, and the same person will still be here next year.
Move off it when any of these are true, because they are the conditions a spreadsheet cannot hold.
More than one person enters data. Concurrent editing and version control are the failure, not the formulas.
More than one entity or site. Consolidation across tabs is where the arithmetic silently stops reconciling.
A third party will inspect it. An auditor or a customer wants to trace an entry back to a source document, which a spreadsheet only supports if somebody maintained the discipline manually for a year.
Factors update annually and you need a comparable series. Restating a prior year while keeping the original is genuinely difficult in a workbook and is table stakes in a tool.
Be honest about the middle case too. Plenty of single-entity companies with a competent owner run this in a spreadsheet perfectly well, and being sold a platform they do not need is its own waste. If you do decide to look, the criteria worth scoring are in choosing carbon accounting software for SMEs.
What stops it happening again?
Separate the three jobs the file was doing.
Collection should sit with the people who own the source data, entered against their own site or category rather than emailed to a coordinator.
Factors should be a controlled set with a source and a year attached, not a tab anyone can edit.
Reporting should draw from a locked period. Once a year is closed, closing it should mean something, with a record of who reopened it and why.
Whether that lives in software or in a much stricter spreadsheet regime is a budget question. What is not optional is the separation. The workbooks that break tend to mix all three in one file, edited by whoever needed something that week.
What does moving to a platform actually involve?
More effort in the first year than the sales process suggests, and much less in the second. Worth knowing both halves before you decide.
The first year is data loading, and that is real work. A small-business customer wrote on G2 in August 2026 that everything works perfectly once the data is loaded, and that getting it loaded is the challenging part. Assume the historic year you want to keep will need re-entering rather than importing cleanly, because your workbook's structure is unique to you.
There is a trade to weigh honestly, too. A spreadsheet shows you every formula, and a platform does not by default. One of our own mid-market customers made exactly that point on G2 in July 2026, asking to see the conversion factor applied when their input in one currency became an entry in another. It is a fair question to put to every vendor you consider, ours included.
What you get back is the thing a workbook cannot give you: several people entering data at once, entities that consolidate without manual arithmetic, and a closed year that stays closed. The platform does entity management across locations and sites with roles for data owners, auditors and managers, guides GHG Protocol setup and reporting through an AI assistant, and carries over 20,000 spend-based and activity-based factors with the option to add your own. A free account needs no sales call, and Pro starts at EUR 1,200 a year.
What should you do today?
Freeze the file. Everything else can wait a day, and nothing else works until the reference version stops moving.
Then reconcile to the last number you published, because that is the one with a customer attached. Once you know the size of the gap, you can decide calmly whether this is a repair or a rebuild.
If it is a rebuild and you would rather not do it alone, you can start a free account and load one entity to see how far you get, or book a meeting and talk through the reconciliation with someone who has done it before.
Sources: Hedgehog platform and Hedgehog on G2, both read on 27 August 2026. Verified 16 September 2026.
Facts on this page were last verified on 2026-09-16.
