Why bookkeeping cleanup always takes longer than you quoted

Cleanup overruns because it is scoped by transaction count, and transaction count does not predict the work. What drives the hours, and how to scope against that.

Every firm that takes on catch-up work has the same story. The engagement was quoted at a number that seemed generous, it ran to twice that, and the write-off was absorbed quietly because re-opening the conversation with the client felt worse than eating the hours.

It is worth being precise about why this keeps happening, because the usual explanations — the client was disorganised, the scope crept, we were optimistic — describe the symptom rather than the cause. The cause is that cleanup is almost always scoped against the wrong variable.

In a survey of 725 US accounting and bookkeeping professionals, close to a third named manual data cleanup as the single biggest obstacle to doing higher-value advisory work — placing it ahead of staffing shortages, which roughly a quarter named, and well ahead of app overload. The figures come from Intuit’s 2026 accounting technology survey, as reported by CPA Practice Advisor.

That finding is usually read as a complaint about volume. It is better read as a complaint about unpredictability. Work you cannot estimate is work you cannot schedule, cannot staff at the right level, and cannot price — and unpredictable work is what pushes advisory to the bottom of the week, every week.

Transaction count does not predict the work

The near-universal scoping method is to count the records. Eighteen months of a small business, four thousand transactions, so many hours per hundred, add a margin, quote.

The arithmetic is clean and the premise is wrong. The hours in a cleanup do not come from reading transactions. They come from the transactions that are wrong, and from how many different reasons they are wrong for.

Two sets of books with an identical transaction count can differ by a factor of five in effort. One was coded consistently by someone careless — a single systematic mistake, repeated, which is discovered once and then corrected in bulk. The other was coded by four people over two years with a change of software in the middle, and contains a dozen unrelated small problems, each of which has to be found separately because none of them looks like the others.

Volume bounds the worst case. It does not estimate the expected case, and a quote is an estimate of the expected case.

What actually drives the hours

Three variables, none of which appear on the transaction count.

The exception rate. The proportion of records that need any intervention at all. In practice this ranges from a low single-digit percentage in books that were merely neglected, to a substantial fraction where an import went wrong or a rule misfired. The difference between those two ends is the difference between a fortnight and a quarter.

The number of distinct mechanisms. Each separate cause of error costs a fixed investigative amount to identify, largely independent of how many records it affected. Finding that a coding rule matched inside a longer word takes the same afternoon whether it corrupted forty transactions or four hundred. A book with one mechanism affecting a thousand records is cheaper to fix than a book with ten mechanisms affecting a hundred.

Evidence availability. Whether the source documents that would settle an ambiguity are actually present. A questionable transaction with the invoice attached is a two-minute decision. The same transaction with no document is an email to the client, a wait, a follow-up, and a decision made on worse information. This is the variable that most reliably destroys a schedule, because the delay is not yours to control.

Why the overrun is discovered so late

Cleanup errors are systematic, and systematic errors hide inside totals.

A ledger that balances is not a ledger that is right. Internal transfers recorded as costs will double a year of spending while every reconciliation still ties. A refund whose sign was stripped on import produces a difference that is exactly twice the true error, which looks like a missing entry of a different size and gets hunted as one. A statement set can contain the correct number of files and still be missing a month, because the file naming is regular and nobody counted the periods.

None of these are visible at the point of quoting, when what you are looking at is a trial balance and a folder listing. All of them are visible in week three, when someone has finally read enough to notice the pattern — by which point the number has been given.

Scope against the exception rate instead

The change that fixes this is small, and it is a change in what you measure before quoting rather than a change in how you work.

Run detection across a sample of the real books before committing to a number. Not a review — a set of specific mechanical checks, each of which either passes or produces an exception:

• Duplicate detection on document content, not on file name or checksum. A photographed receipt and the supplier’s emailed PDF of the same expense share no bytes and no file name. They share the supplier, an amount within OCR tolerance, a date within a few days, and a line structure. Matching on those four together finds what filename deduplication cannot. This is covered in more depth in detecting duplicate invoices when receipts arrive as photographs.
• Arithmetic validation on every document total. Subtotal plus tax should equal total. Where it does not, one of the three was misread or the document contains a label that does not mean what it says. Checking the arithmetic the document itself asserts is free and catches a surprising proportion of extraction error.
• Statement continuity, in dates and in money. Each period’s closing balance should be the next period’s opening balance, and the periods should be contiguous. A gap in either is a missing statement, regardless of how complete the folder looks.
• Transfer identification before coding. Payments between accounts the client controls are not costs. They are individually obvious and collectively easy to miss, and they inflate expenditure without unbalancing anything.
• Coding rule audit by outcome. For each rule, list what it actually captured rather than what it was written to capture. A rule intended to match a supplier name will also match that string inside longer words, and it will do so silently for as long as nobody asks.

What comes back is the exception rate and the mechanism count — the two variables that actually predict the hours. That is a defensible basis for a quote, and it takes a fraction of the time the overrun would have cost.

What this changes commercially

A firm that can measure an exception rate before quoting can do three things it could not do before.

It can quote fixed price on work that was previously hourly, because the uncertainty has been resolved rather than priced in. Clients prefer this, and it removes the awkward conversation that open-ended cleanup billing eventually produces.

It can decline the engagements that are genuinely not worth taking, early and with a reason. Some backlogs are better rebuilt from source than repaired, and identifying those in week zero rather than month three is worth the assessment on its own.

And it can staff the work correctly. Once the exceptions are identified and ranked, most of the remaining effort is judgement on a small, ordered queue — which is senior work, done efficiently, rather than senior people reading four thousand rows to find the eighty that matter.

That is the actual prize here, and it is not really about cleanup. It is that the hours currently disappearing into unpredictable remediation are the same hours the advisory work needs.

We build this detection layer as bookkeeping cleanup automation — run against a sample first, so the number you quote is one you can hold.