Introduction — The Column That Had Been Wrong for a While
Two hundred and sixty-six calculations, none of them ever checked, and a customer's accountant found the first one.
Rae had built a bookkeeping workbook for small service businesses. Two hundred and fourteen formulas, thirty-one validation rules, twelve named ranges and nine conditional formatting rules — two hundred and sixty-six calculations in all, put together across about seventy hours over five weeks. It looked professional. The dashboard was clean. It had a category summary, a quarterly view, a running profit figure and a chart that updated itself.
It sold. Not spectacularly, but steadily, and the reviews were kind. People said it was clear. People said it was exactly what they had been looking for.
In month six, one of them sent an email.
The email was not angry, which is part of why it took so long to arrive. It said that the quarterly totals column had "been wrong for a while," that they had noticed because their accountant queried a figure, and that they had gone back through it and thought the problem started somewhere around the second quarter. They wanted to know whether it was them or the sheet.
⚠ It was the sheet.
What was actually wrong
The quarterly summary used a formula that summed a column conditionally on the date falling inside a range. Rae had written it, looked at it, seen a plausible number appear underneath it, and moved on.
In Rae's own copy, with Rae's own sample data, typed on Rae's own machine, it was correct. It was correct because every date in the sample had been entered by Rae, in one format, on one system, in one application.
The customer's dates had been typed by a person who wrote dates the other way round. Some of them had been pasted in from a bank export. A handful had arrived as text rather than as dates and looked identical on screen.
The formula did not complain. It did not show an error. It did not turn red. It added up the rows it recognised as dates, ignored the ones it did not, and printed a total that was smaller than the truth by an amount neither Rae nor the customer could see.
⚠ That is the entire problem with this business, in one sentence: the failure mode of a spreadsheet is a confident wrong answer.
A broken image looks broken. A broken document looks broken. A broken layout looks broken. A broken spreadsheet looks like a spreadsheet, and the number in the corner is the one the customer is about to make a decision with.
The number Rae had never produced
After the email, Rae did something that took an afternoon and should have taken an afternoon five months earlier.
Rae sat down with a calculator, a sheet of paper and the workbook, and went through the formulas one at a time. For each one: what should this return, given this specific input, worked out by hand? Then: what does it return?
Not "does it look sensible." What is the correct answer, and does it produce it?
Two hundred and sixty-six calculations. It took most of two days spread across a week. And it was not one pass, because a formula that is correct with tidy data is not necessarily correct with the data a real person produces. So each formula was checked against five inputs that Rae came to think of as the hostile five:
- an empty cell where a number was expected
- text typed into a number column — a currency symbol, a word, a space
- a date entered in a different format from the one Rae uses
- a negative number
- the same sheet opened in the other application Rae had claimed to support
⚠ Thirty-one of the two hundred and sixty-six produced a wrong or misleading result under at least one of those five.
Not thirty-one that showed an error. Thirty-one that returned something — a number, a blank, a total — that was not the right answer and did not announce itself.
Some were small. A count that quietly excluded rows. A percentage that divided by a total that had itself been filtered. Some were not small at all. The quarterly summary was one of them, and so were three of the four figures on the dashboard, because the dashboard was built on top of the summary and inherited everything wrong with it.
⚠ The dashboard is the most dangerous sheet in the workbook, because it is the one the customer looks at and the one furthest from the data.
Hand-check coverage
Before that week, if you had asked Rae how many formulas in the workbook had been verified against an answer worked out independently, the honest number was zero.
Not zero because Rae was careless. Zero because there had never been a moment in the process where that was a step. Rae had built formulas, looked at the result, thought yes, that's about right, and moved on. Everybody does. The result appears instantly, it is formatted, it sits in a cell that looks authoritative, and the mind accepts it.
⚠ Looking at the output of a formula is not checking it. It is being told the answer by the thing you are trying to check.
So Rae started keeping a number, and it is the number this book is organised around.
Hand-check coverage: the share of the calculations in a template whose output has been compared against an answer worked out independently, under every one of the hostile inputs, in every environment you claim to support.
Rae's coverage in month five was zero per cent. By month eleven it was one hundred per cent — not because Rae had checked two hundred and sixty-six formulas, but because Rae had rebuilt the workbook to have sixty-eight.
The rebuild
The rebuilt workbook did the same job. It supported the same decision. It had one data table instead of four, a set of views built from that table, a much simpler quarterly summary, and a dashboard with five figures instead of eleven.
Sixty-eight calculations. It took about twenty-six hours instead of seventy. Every one of them had a written test case with an expected answer, recorded in a file that lived alongside the master.
And two other things changed, both of which are rules in this book.
Rae stopped claiming to support "any spreadsheet application" and named two, having actually opened the file in both and run the hand-check in each. The listing said so in the first three lines.
And Rae stopped shipping a workbook where the customer could type into a formula cell without noticing. The input areas were obvious and unprotected. Everything else was locked, and the sheet said so.
⚠ The version with sixty-eight calculations sold better than the version with two hundred and sixty-six, and generated roughly a third of the support.
Revenue per verified formula
There is an arithmetic that follows from all of this, and it is the second thing this book is organised around.
If a formula has not been hand-checked, it is not an asset. It might be right. It is untested, which means you do not know, which means it can produce a wrong number in a customer's hands at a moment you will not witness. In the arithmetic of this business it is worth nothing, and it is worse than nothing, because it carries a liability and a support cost and it has to be re-checked every time the application updates.
⚠ So the denominator is not the number of formulas you wrote. It is the number you have verified.
Rae's first workbook, on that basis, had a denominator of zero, which is not a number you can divide by. That is the correct answer. It is a product whose economic value per unit of verified work was undefined, because no verified work had been done.
The rebuilt workbook had sixty-eight verified formulas and produced more revenue than the original. That is the whole argument of this book compressed into two sentences.
What this book is
Thirty-seven chapters, sixty-eight resources and a hundred and forty-eight prompts, built on four rules:
Rule 1 — A broken spreadsheet does not look broken; it gives you a number. Wrong answers arrive with the same confidence as right ones, from a cell that looks exactly like every other cell. Chapter 5.
Rule 2 — They will type into it, and typing is how it breaks. The product invites the customer to edit the thing that makes it work. Chapter 6.
Rule 3 — It has to run somewhere you have never been. Different applications, versions, devices and locales — and a locale can change the correct answer without changing anything visible. Chapter 7.
Rule 4 — You never see the data it runs on. It is their money, they will not send it to you, and you cannot reproduce a fault you cannot see. Chapter 8.
The economic unit is revenue per verified formula. The leading indicator is hand-check coverage, which you must produce yourself, which takes an afternoon, and which moves a season ahead of refunds, fault reports and reviews.
What this book will not do
It will not name an application, a marketplace or a function. It will not tell you what a formula should be, because a formula you did not verify is not yours regardless of who wrote it. It will not tell you what the law requires where you live, what your marketplace's terms currently say, or what your tax obligations are. And it will not tell you that two hundred and sixty-six formulas is a better product than sixty-eight.
⚠ What it will do is put a step into your process that almost nobody in this trade has: before you publish, you find out whether the numbers are right.
Rae's summary of the whole thing, given some two years later, was this:
⚠ "For five months I had a product whose central feature was arithmetic, and I had never once checked the arithmetic. It took two days to find out that thirty-one things were wrong. The customer who told me had already sent the figures to their accountant."
©2026 James Henderson / https://localhandyman.work