Why your bank reconciliation takes a week (and how to finish it by Friday)

Month-end at an SMB rarely gets stuck in accounting. It gets stuck earlier, in bank reconciliation. Someone downloads the bank statement, pastes it into a spreadsheet, adds formulas, eyeballs it against the ledger, and fights the differences until it "ties out." A week later, the accountant can finally start closing.

If that sounds familiar, the problem isn't your treasurer. It's the method. Reconciliation is done the same way it was twenty years ago, with tools that haven't changed, for a transaction volume that has grown tenfold.

Here are the five reasons reconciliation eats the week, and what changes in each one when the system does it with you instead of watching you work.

1. Every bank sends its statement in a different format

One bank exports CSV with dates in dd/mm. Another gives you an OFX file. The third, a PDF you have to copy by hand. Before a single line gets reconciled, someone has already lost half a morning reformatting columns so the spreadsheet will accept them.

What should happen: the system has a profile per bank. You upload the file exactly as you downloaded it and it parses itself. If the bank changes its format, you change the profile once, not every month.

2. You match by eye what a rule could match on its own

Around 80% of the transactions on any statement are obvious: same amount, same reference, date within a day or two of the entry. Those should never touch a human hand.

With matching rules, the system proposes matches by amount, reference, and date. You confirm the doubtful ones and review what's left unmatched. The treasurer's time goes to the twenty odd lines, not the two hundred obvious ones.

What should happen before a person ever opens the statement.

Practical tip Count how many lines your last statement had and how many required thought. If more than 20% needed human judgment, it's not that your bank is unusual: it's that you have no rules. Rules get written once and work every month.

3. When something doesn't tie out, nobody knows where it came from

The spreadsheet tells you there's a 1,240 difference. It doesn't tell you which entry caused it, whether the bank charged a fee nobody recorded, or whether a payment was booked twice. Finding it is detective work, and the detective is the most expensive person on the admin team.

With two-way traceability, you go from a bank transaction to the entry that generated it, and from the entry back to the transaction. The difference stops being a number and becomes a short list of items with names on them.

4. Reconciliation lives in a spreadsheet and the ledger lives somewhere else

When you finish reconciling, the work isn't done. Someone has to go back into accounting and record what showed up on the statement but wasn't there: fees, interest, the check that finally cleared. Double entry, double chance of error, and a spreadsheet that no longer matches the ledger five minutes after you called it closed.

If reconciliation posts straight to the ledger, what you confirm is booked. There's no second pass.

5. Outstanding checks and deposits in transit are tracked from memory

Checks issued that nobody has cashed yet. Deposits the bank credited three days late. Transfers that left on the 31st and arrived on the 2nd. If all of that lives in the treasurer's head or on a separate tab, the day that person is out, reconciliation can't happen.

The system carries them as open items and closes them only when they show up on the statement. Nobody has to remember anything.

And if you also have an account in dollars and another in local currency, there's one more front: the exchange rate. A payment booked at the invoice-date rate and credited at the bank-date rate will never match to the cent, and that gap isn't an error: it's an exchange difference, and it has to be recorded as one. In a spreadsheet, that item gets "adjusted" by hand. In a system with multi-currency bank accounts, each account carries its balance in its own currency and the exchange difference is identified for what it is, not buried in an adjustment.

The underlying idea Reconciliation isn't a report you build at month-end. It's a state you keep current. If you load the statement every week, month-end becomes a one-hour task.

So what now?

The routine that works has four steps and fits in a Monday:

1. Download and upload the week's statements, using each bank's profile.
2. Let the system propose the matches.
3. Review the doubtful ones: thirty minutes of the treasurer's time, not three days.
4. Document differences on the spot, with the entry right there, not in an email nobody can find later.

By Friday, reconciliation is done. The accountant starts closing on the 1st, not the 8th. And when the auditor asks about a transaction from March, the answer is one click away, not in a folder of versioned spreadsheets.

If your close takes two weeks, measure how much of that is reconciliation. It's almost always more than half.

DoxBank does exactly this: a profile per bank (OFX, MT940, CSV), rule-based matching on amount, reference, and date, transaction↔entry traceability, and automatic posting to the DoxAccount ledger. If you want to see how many transactions from your own statement match on the first pass, request a demo and bring the file. And if a slow close is your situation, see how other companies live it.