Missing receipts after bank reconciliation: how to chase only what is actually missing
Bank reconciliation always leaves a short exception list of unmatched transactions. Here is how that list becomes a precise, automatic client request instead of a vague "send me your receipts" email.
Bank reconciliation rarely ends in a clean sweep. Most transactions match an invoice or a receipt on their own; a handful do not — a card payment with no attached document, a transfer nobody can immediately place. What happens to that short exception list is where firms quietly lose the thread: someone copies a few lines into an email, sends it to the client, and waits. The client answers three of the five lines, forgets the rest, and the same missing receipts reappear at the next close.
This is about what should happen to that list the moment reconciliation produces it — and why turning it into a precise, automatic request changes the outcome more than any improvement to the reconciliation engine on its own.
The exception list already exists — the problem is what happens to it
A reconciliation engine's most useful output is not the matches; it is the short, exact list of what did not match. Bank reconciliation without the spreadsheet covers how that list gets built — OFX and CSV import, automatic one-to-one and grouped matching, a human confirming the rest. Once confirmed, the unmatched lines are a precise, dated, amount-exact record of what is missing: not "some receipts from March," but a dated £340 transfer, with whatever counterparty name the bank statement itself provided.
That precision is usually thrown away at the exact moment it matters. A staff member manually retypes three or four of those lines into an email, and the file-level accuracy the reconciliation engine just produced degrades back into a vague request the instant a human has to relay it by hand.
Turning the list into a request, without retyping it
Missing-receipt detection closes that gap by treating the unmatched list itself as the request. Each unmatched transaction — date, amount, direction, and the counterparty when the bank statement resolved one — is recorded against the client folder it belongs to, scoped so tightly that a transaction from one client's bank statement can never surface under another client's request, even inside the same firm's account.
Once transactions are recorded as missing, the client receives a link — no account, no password — to a page listing exactly those lines and nothing else. Not a folder, not a portal home screen: the specific missing receipts the firm cannot yet post.
Two ways to close a line, both final
A client resolves a line one of two ways:
- Attach the document. It uploads like any other document — extracted, checked, coded — and the line is marked resolved the moment the file lands.
- Explain there is nothing to attach. A card fee, a bank charge, an internal transfer — the client leaves a short note instead of hunting for a receipt that never existed. The line still closes.
Both count as a resolution. The alternative — silently expecting a document for a line that was never going to have one — is exactly the kind of exception that used to sit open for months.
A reminder that stops on its own
Send one email and most clients act within a few days, or not at all. The follow-up is what actually closes the gap, and it is also the part staff time most often skips once volume climbs. An automatic reminder fires every three days for whatever is still outstanding — not a daily nag, not a second forgotten email — and stops the moment the last line is resolved. Nobody has to remember to chase, and nothing chases once there is nothing left to chase.
Precision vs. a general reminder
| "Please send your missing documents" | An automatic missing-transaction request | |
| What the client sees | A vague ask, no specifics | The exact transaction: date, amount, and counterparty when known |
| Who has to compile it | A staff member, by hand, from the reconciliation screen | Generated from the reconciliation result itself |
| Follow-up | Remembered manually, or forgotten | Automatic, every 3 days, until resolved |
| Scope | Whatever the staff member typed | Exactly the unmatched lines, nothing else |
| When it stops | When someone remembers to stop | The moment every line is resolved |
What this does not replace
Missing-receipt detection reuses the reconciliation engine's own output — it has no judgment of its own about which transactions matter or which client relationships need a softer touch than an automated reminder. A transaction a client genuinely cannot explain still needs a human conversation; the system's job is only to make sure that conversation starts from a precise, current list instead of a stale email thread nobody reread before the call.
Related reading
- Bank reconciliation without the spreadsheet: OFX, BAI2 and grouped payments
- Stop chasing client documents: a calmer intake workflow for accounting firms
FAQ
Does this replace bank reconciliation?
No — it starts from the reconciliation result. The engine that matches transactions to invoices is unchanged; this is what happens next to the transactions that do not match.
What if a client has no email on file with the firm?
Nothing is sent automatically. The missing transactions are still recorded and visible to the firm, which can chase manually or add a contact email later to start automatic requests.
Can two different clients' missing transactions ever get mixed up?
No — every missing transaction is scoped to a single client folder from the moment it is recorded, the same isolation the firm's own reconciliation and reporting already rely on.
Does the client need to create an account to respond?
No — the link is a signed, time-limited token that opens directly to that client's outstanding list. No password, no portal to remember, no account to lose.