Where bookkeeping firms actually lose time in monthly close

For a stretch of months at Scale CPA, our own close reviews kept turning up the same uncomfortable shape: client files open for a week or more while carrying only a few hours of logged work. We had assumed the close was slow because the work was heavy. The logs disagreed. The work was a small island in a long stretch of elapsed time, and nearly all of that elapsed time was spent waiting for something to arrive.

So the first useful move, if your close takes too long, is to stop treating close time as one number. It is two numbers reported as one. Working time is the hours your team spends reconciling, adjusting, and reviewing. Waiting time is the days a file sits blocked on an input nobody in your office controls. On our own book the losses stack in a consistent order: waiting on inputs first, by a wide margin, then rework from wrong or missing statement periods, then the context switching that comes from documents trickling in across two weeks.

One disclosure before the teardown. We build a statement retrieval product, so we walk in biased toward finding that statements are the problem. The measurement exercise at the end is vendor neutral. Run it and trust your own numbers over our framing.

Elapsed days versus worked hours

A monthly close is a dependency chain. Reconciliation cannot start until statements exist. Review cannot start until reconciliation finishes. Delivery waits on review. Chains like this have a property worth staring at: the calendar length of the whole thing is set by its slowest link, and the slowest link does not have to be one where anyone is working.

Most advice about speeding up close attacks working time. Better checklists, reconciliation tooling, review templates, more staff. All of it shortens the hours. None of it touches the days a file spends waiting, because your team does not produce the waiting. A ten business day close is frequently three days of work suspended in seven days of waiting, and every fix aimed at the three days leaves the seven intact.

Waiting on inputs is the deep end

Among the inputs a close waits on, bank and card statements dominate. The reason is structural: they are the only inputs produced entirely outside your firm, on schedules set by banks, delivered through the memory of clients.

Walk the path one statement travels. The account’s cycle closes on whatever day the bank assigned it, often not month end. The bank generates the PDF some days after that; retrieval channels such as Plaid’s statements API can only hand over a document the bank has actually published. Then a person at the client has to notice the request, log in, download, and forward it. Any link can stall. The cycle may close mid month, so the document flagged as missing does not exist yet. The client may sit on the request for a week. A connection that worked for a year may have broken silently, or a security hold at Wells Fargo, Chase, Bank of America, or Citi may have frozen access until someone approves it. Every one of these failure modes adds calendar days while adding zero hours of work.

The loss stays invisible because nobody logs time against “waited for Chase.” It shows up only when you compare dates, which almost nobody does. The document bottleneck post walks the critical path math in more detail.

Rework: paying for the same month twice

The second sink is smaller but meaner, because it burns working time you already spent. It recurs in a few standard shapes.

A card that cycles on the 14th gets its May 15 to June 14 statement filed as June, and the reconciliation quietly ties out to the wrong window. When someone catches it, the month gets redone. Statement periods that ignore calendar months are the standard trigger.

A client sends a screenshot or a transaction export instead of the official PDF. Under deadline pressure it gets accepted. Months later a lender, auditor, or tax preparer asks for the real document, and someone reopens the file to reconstruct the period from scratch.

A statement lands after the file was closed, balances shift, and a finished reconciliation gets unpicked.

The common thread: reopening a file costs more than the original work, because whoever does it must first rebuild the context of what was done and why. Rework also detonates on a delay, surfacing weeks or months after the mistake, which makes it hard to attribute to its cause.

Trickle arrivals and the context-switch tax

The third sink hides inside working time itself. When documents dribble in over two weeks, no client file can be worked start to finish. The bookkeeper opens Client A, reconciles the two accounts whose statements exist, parks the file, moves to Client B, and returns to Client A twice more as stragglers land. Each return trip pays a reload toll: which accounts were done, what the open questions were, where the notes live. Task switching research consistently finds that even brief mental shifts carry a real cost, and a close run out of an inbox is an interrupt driven close.

The individual interruptions are small. Multiplied across a full client list and two or three revisits per file, they are why a close can feel crushing while the timesheet totals look modest.

Measure it before you fix it

You should not take the ordering above on faith, least of all from a vendor. The instrument is a spreadsheet and one quarter of patience. For every account on every client, log four dates:

Three gaps fall out. Received minus period end is waiting on inputs; subtract a few days for normal bank posting lag to keep it fair. Recon started minus received is internal queueing, your own triage delay. Delivered minus recon started is working time plus review. One month gives you a suspicion. A quarter gives you a distribution, including the variance, which matters as much as the average: unpredictable arrivals are what whipsaw staffing between idle and buried.

Our own close stalled waiting on statements more months than we care to admit, and the stalls concentrated in a minority of accounts, mostly cards on mid month cycles and accounts at hold-prone banks. Expect your data to be lumpy in the same way.

What to do with the numbers

Match the fix to whichever sink your quarter of data indicts.

If waiting dominates, take collection away from human memory. A fixed request calendar and standardized intake help at the margin; the complete guide to collecting client bank statements covers that playbook. The structural version is retrieving statements directly from each bank after a one time client consent, which is the model StatementFlow implements: it learns each account’s real posting cycle, fetches the official PDF when the bank publishes it, and files it into the firm’s own Google Drive, with a coverage board flagging gaps and needed reconnects before close starts. It collects documents only. Data extraction and the bookkeeping itself remain your existing stack’s job, and it covers US banks.

If rework dominates, fix period tracking and intake standards first. Track coverage by statement period rather than calendar month, refuse screenshots as statement support, and pick one filing convention.

If context switching dominates, batch. Set a start gate for each file, hold work until the file is fully workable, and run stragglers as a named exception list instead of an inbox.

Waiting is usually the biggest number and also the cheapest to reclaim, because the hours it releases are hours already on your payroll. If your quarter of tracking shows a close that mostly waits on statements, that is precisely the problem we built for. Request early access and we will put the coverage board up against your own client mix.