It's 4:52pm on a Friday and the report is done. You have the email drafted, the file attached, and a weekend that starts the second you hit send. This is the exact moment the last mistake happened — the one where the client replied Monday with "the North total looks doubled," and you spent an hour proving it was a duplicated source row you could have caught in thirty seconds. Five minutes now is cheaper than that hour, and far cheaper than the client's quiet downgrade of how much they trust your numbers. Here is the check I run before every send, no exceptions.
The one check that catches the most: reconcile a total
Before anything else, tie one number to something the client already knows. Say your cleaned file totals revenue and you get £482,610. The client's finance summary says £474,300. That £8,310 gap is not rounding — it's a signal. Reconcile it with a quick difference:
=SUM(Revenue) - 474300 = 8310 <- investigate before sending
Nine times out of ten the gap is a duplicated row, a test record the client forgot about, or a currency column that still has three text-formatted cells excluded from the sum. Find it now. A report whose headline number doesn't match the client's own books is the fastest way to lose an account, and the slowest thing to explain after the fact.
The example: a duplicate that survives a glance
Row counts lie when duplicates hide in plain sight. Suppose your orders table should have one row per Order ID. Check it in one formula instead of scrolling:
Rows: =COUNTA(A2:A5000) -> 4,812 Unique Order IDs:=SUMPRODUCT(1/COUNTIF(A2:A4813,A2:A4813)) -> 4,798
4,812 rows but only 4,798 unique IDs means 14 orders appear twice, and every revenue total is inflated by those 14. That is exactly the "doubled North total" from Monday, caught on Friday. If the two counts don't match, you have duplicates to resolve before the file is safe to chart.
The six-point check, in order
- Row count — does the cleaned file have roughly the rows you expect? A file that dropped from 5,000 to 3,900 lost something.
- Reconcile one total against a number the client already trusts, to the penny.
- Unique key check — rows versus distinct IDs, to catch hidden duplicates.
- Blanks in required fields — =COUNTBLANK() on the columns that must be populated.
- Date range — sort the date column; the min and max must fall inside the reporting period. A stray 1900 or 2099 is a parse failure.
- Outlier scan — sort each key numeric column ascending then descending and read the top and bottom five rows. A negative quantity or a £2m order jumps out instantly.
Six checks, five minutes, and every one of them targets an error a client can see. None of it requires a fancy tool — COUNTA, SUMPRODUCT, COUNTBLANK, and a sort. What it requires is doing it every single time, including the Friday you're sure the file is fine.
Make it a habit, not a hope
The analysts who never send a broken report are not luckier. They turned this into a ritual they run on autopilot, the way a pilot reads a checklist on a route they've flown a hundred times. The value isn't the five minutes; it's that the five minutes happens whether you feel like it or not. Tape the six checks to the corner of your monitor and run them before every send until you stop needing the tape.
There's a commercial reason to run it, too. When you can tell a client "I reconciled the totals against your finance summary before this went out," you stop being the person who makes charts and become the person who guarantees the numbers. That guarantee is what justifies a higher rate — you are selling reliability, and reliability is the one thing a rushed in-house team can rarely promise about its own spreadsheets.
Dotwave runs these six checks on every file automatically and flags the mismatches — the duplicate IDs, the unreconciled total, the date outside the period — before you ever attach it to an email.
Get early access →