Twelve numbers in a column and one control total. Summing them is trivial — until you notice the machine read four of the cells wrong. The fix isn't a better formula; it's a second, independent count that has to agree.
You're handed a column of dollar amounts exported from some other system, and a control total from the document's footer: $5,653.25. Your job is the simplest task in data work — add the column — and the only acceptance test that matters: your sum must equal the control total. If it doesn't, something is wrong, and the discrepancy itself tells you where to look.
Ask Claude to parse and sum the column and it will — but a naive
parse silently mangles anything with a comma, a currency symbol, or
accounting-style parentheses. "1,250.00" becomes
1. "(120.00)" becomes nothing. The sum runs
without error and is badly wrong. The skill isn't summing; it's
refusing to trust a total that doesn't reconcile.
Below: the raw cells, what a naive parseFloat makes of each,
and the correctly cleaned value. Rows where the two disagree are flagged.
Two totals at the bottom — only one ties to the control.
The naive total is off by thousands — and crucially, it didn't complain. No error, no warning, just a confident wrong number. Reconciliation against the control total is the only thing that catches it, and the per-row mismatch column points straight at the four cells the parser fumbled.
A second, independent path to the same number is the whole game. Here the control total is that second path; the cleaned sum must hit it exactly.
"1,250.00" → 1250.00, not 1. If you can't explain a cell's value, don't sum it.Parsing errors here are silent: no exception, no NaN in the total if NaNs get coerced to zero. The code “works.” Only the reconciliation reveals it lied. Never accept a total that has no independent check.
Thousands separators, currency symbols, trailing spaces, and parentheses-for-negative are the usual suspects. Strip $ , and whitespace; treat (x) as -x; decide what N/A means (skip, or zero) before you sum.
$ as currency, parentheses as negative, and N/A as excluded. Sum it, and tell me whether it ties to a control total of 5653.25 — if not, list each row where your parsed value differs from a naive parseFloat and the resulting delta.
Two free levers worth setting. Turn the reasoning effort up
for the hard part — Claude Code's /effort (see
Feed it documents for the
model and effort controls); a transcription wants it low, an analysis like
this one wants it high. And end your prompt with an explicit
self-check — “before you finish, tie the cleaned total to the control total, to the cent”
— which is exactly why the prompt above asks Claude to verify itself.
Naming the oracle is the highest-value line in the prompt. And keep the
expensive model's context light — route transcription and formatting
to cheaper tools (see Spend
tokens well).
N/A means for your books. The machine will hand
you a number; only you can refuse to trust one that doesn't tie out.
Cleaned correctly, the column sums to $5,653.25 —
exactly the control total. The naive parse gives
$2,226.25, short by $3,427.00. That
gap is fully explained by four cells: "1,250.00" read as 1
(−1,249), "2,000" read as 2 (−1,998),
"(120.00)" dropped to 0 (the +$120 we actually owe back
flips the sign, costing 120 against the clean figure), and
"$300" dropped to 0 (−300). 1,249 + 1,998 + 120 +
300 = 3,427. The reconciliation didn't just say “wrong” —
it handed us the exact list of cells to fix.
Same two moves — see explore in HTML, deliver in PDF.