Reconciling multiple client bank statements every month: a workflow that scales

Most advice about bank reconciliation assumes one company reconciling one account. A practice doesn't work that way. It works through a queue: twenty, fifty, sometimes a couple of hundred client accounts, each with a different bank, a different statement layout and a different level of cooperation about sending the file on time.

The reconciliation arithmetic is the same in both cases. What differs — and what actually determines whether month-end is three days or ten — is everything around it. Here is a workflow built for the queue.

Fix intake before you fix anything else

Ask most firms where month-end time goes and the answer isn't reconciliation. It's waiting: for the client to send the statement, then sending a reminder, then receiving a photograph of a laptop screen instead of the PDF.

This is worth solving structurally rather than through willpower. Agree the format once, in writing, at engagement: the PDF downloaded from net banking, not a scan, not a photo, for the full period, by a fixed date each month. Send the reminder on a schedule rather than when you notice it's missing. Where a client repeatedly sends unusable files, price that in or fix it — it's not a small cost.

The reason this matters more than it sounds: a text-based PDF from a bank portal converts cleanly and needs light checking. A photographed page needs character-level verification on every amount. The intake decision determines how much work the rest of the month is.

Batch by bank, not by client

The instinct is to work client by client — finish Sharma & Co entirely, then move to the next. For reconciliation specifically, that's the slower order.

Statements from the same bank share a layout, so they fail in the same ways. If you process all eight HDFC statements together, you learn the quirk once — the wrapped narration, the column that drifts, the brought-forward row — and apply the fix eight times. Spread across three weeks and interleaved with other banks, you rediscover it eight times.

Group the month's files by bank first. Process each group in one sitting. The consistency gain is real and it compounds as the client list grows.

The per-client loop

For each statement, the same four steps, in the same order, every time.

Convert. Get the statement into rows — whether by a tool or by hand.

Verify against the statement's own balances. Before looking at the ledger at all, confirm the extraction is faithful to the source: opening balance, plus each transaction in order, should equal the stated closing balance. This catches dropped rows and inverted debit/credit signs, and it takes one formula column. Do not skip it because the file “looks fine” — an inverted sign looks fine.

Match against the ledger. Only now compare to your books. Because step two already confirmed the statement side is complete and correct, anything that doesn't match is a genuine reconciling item rather than an extraction artefact. That distinction saves an enormous amount of confused investigation.

Post and flag. Post what's clean. Everything unresolved goes to the exceptions list — it does not stay in your head, and it does not hold up the rest of the queue.

The important property of this order is that step two separates “the conversion was wrong” from “the books are wrong.” Firms that skip it end up investigating ledger discrepancies that were never ledger discrepancies. The mechanics of getting a clean conversion matter mainly because they make step two pass.

Triage exceptions by type, not by client

By the end of the batch you have a list of unresolved items across many clients. Sorting that list by client feels natural and is the wrong cut.

Sort by type instead. Unpresented cheques go together. Bank charges not yet booked go together. Unidentified receipts awaiting client confirmation go together. Handled this way, you'll usually find that half the list is three recurring categories, and each category has one fix you apply across every client at once. You'll also spot the systemic ones — a standing instruction nobody booked, a bank charge that's been mis-posted for four months.

Client-by-client triage hides those patterns completely, because each instance looks like a one-off.

Log what you learned

Keep a short register: bank, account type, statement layout quirk, the fix. Two lines per entry is plenty.

This is the difference between a process that gets faster each month and one that doesn't. Bank layouts change — a redesign in March breaks something that worked in February — and without a register you rediscover every quirk from scratch, usually under time pressure. It also means a new joiner inherits the knowledge instead of rebuilding it.

It's the least glamorous item in this workflow and reliably the highest-return one.

How you know it's working

Three signals worth watching. The proportion of statements arriving in the agreed format by the agreed date — this is the one that most improves everything downstream. The share of files that pass the balance check first time. And the size of the exceptions list at month end compared to last month.

If those are moving in the right direction, the queue is under control. If exceptions keep growing while the other two hold steady, the problem is in your postings rather than your intake — which is useful to know, because it's a different fix entirely.

Most of this workflow is process rather than software, but the per-file balance check is the part worth automating first. That's what we built StatementProof for accounting firms to do.