Every bookkeeper has a version of the same afternoon. The client has sent through the bank statement — a PDF this time, scanned sideways, with the last page cut off. The accounts package says the closing balance is €18,432.17. The statement says €17,994.66. The difference is €437.51, which is suspiciously close to a supplier payment that may or may not have cleared, and now the next two hours are gone.
That is bank reconciliation. The job is small. The mess around it is not.
What bank reconciliation actually is
Strip it back and it is four checks:
- Opening balance in the accounts matches the opening balance on the statement.
- Every line on the statement is in the accounts.
- Every line in the accounts for that bank account is on the statement (or explained — uncleared cheques, payments in transit).
- Closing balance in the accounts matches the closing balance on the statement.
If all four agree, the bank account is reconciled for that period. If they do not, something is missing, duplicated, miscoded, or sitting in suspense.
That is the whole job. Everything else — the categorising, the chasing, the journal entries — is in service of those four checks.
Why a small job takes a long afternoon
The checks themselves are quick. The work around them is not. In a typical practice, the time goes here:
- Getting the statement in a usable form. Clients send PDFs, phone photos of paper statements, CSVs in formats their bank invented, screenshots of mobile apps, and occasionally the email body itself with the figures pasted in. None of it is consistent.
- Splitting multi-page statements. A 40-page business current account statement is one document but forty pages of transactions. The accounts package wants rows; the PDF gives you a layout.
- Handling weird balance markers. Overdraft balances on Irish and UK statements show up as
OD,DR, parentheses around the number, or a trailing minus. Get one wrong and the running balance silently breaks. - Matching transactions to invoices and receipts. This is the part the package can help with, but only if the data is in there. Until the statement is loaded, there is nothing to match against.
- Investigating the differences. Bounced direct debits, bank charges nobody coded, a standing order the client forgot to mention, a transfer between accounts posted to the wrong side.
The actual reconciliation — the four checks — is maybe ten minutes. Everything before it is the rest of the afternoon.
The data entry trap
Most practices try to solve this by typing. Open the PDF on one screen, open the accounts package on the other, key the lines in. For a 50-line monthly statement that is 30–45 minutes of typing per account, per period, per client. Multiply by twelve clients on monthly bookkeeping and the practice is spending the better part of a working week just getting bank statements into the system before any reconciling starts.
Bank feeds help when they work. They do not always work. Older bank accounts, accounts at smaller banks, foreign accounts, savings accounts, credit cards held by directors, and accounts where the client refuses to enable open banking all still arrive as PDFs. The bank feed solves the easy half of the problem and leaves the awkward half where it was.
What good looks like
A sensible reconciliation workflow does three things:
- Ingests the statement in whatever shape it arrived — PDF, photo, scan, multi-page bundle — and produces clean transaction rows with running balances that match.
- Preserves the awkward bits: overdraft markers, multi-currency lines, reversed entries, opening and closing balances on every page.
- Hands the rows to the accounts package in a format it will accept — CSV in the bank's column order, or directly into Xero / Sage / QuickBooks if a feed is unavailable.
Once the statement is in, the four checks above happen in minutes. The argument the bookkeeper has with the PDF is the part that has to go.
The judgement calls a machine should not make
Worth being clear about what automation will not do:
- It will not decide that an unexplained €437.51 is a supplier payment that has not cleared yet versus a duplicate that needs reversing. That is a judgement call against the rest of the ledger.
- It will not chase the client for the missing page of a statement.
- It will not decide whether bank charges go to a specific nominal or get split.
- It will not sign off the reconciliation.
The point of automating the front of the workflow is to give the bookkeeper back the time to do these judgement bits properly, rather than burning the afternoon on data entry and discovering the suspense item at five o'clock.
Where KrinoDoc fits
We built KrinoDoc to handle the ingestion bit — the part before the four checks. Drop in the statement in whatever format the client sent it: PDF, photo, scan, multi-page bundle, overdraft balances marked with OD or in parentheses, foreign currencies, the lot. The structured rows come out the other side with opening and closing balances preserved, ready to drop into the accounts package as a CSV or to match against transactions already there.
The reconciliation itself stays where it belongs — with the bookkeeper, with the judgement. The afternoon of typing does not.
That is the trade we are aiming at. The four checks in ten minutes, not three hours.