Bank Reconciliation in an ERP: Proving the Ledger Against the Bank

The bank reconciliation is the strongest single piece of evidence that a set of books is true. Every other working paper rests on the ledger itself; this one tests the ledger against an outside witness. Doing it inside an ERP changes the mechanics of matching, but not the proof. It is worth being precise about what that proof is, because a reconciliation can be finished and still prove nothing.

The claim a reconciliation has to prove

The reconciliation asserts one thing: your bank ledger balance and the bank's own record of the account agree at a date, once items legitimately in transit are listed. Note the mirror. Your bank account is an asset on your books; to the bank it is a liability, so the statement shows it in credit and charges appear as debits. We see that sign flip cost bookkeepers hours.

The proof is a short walk. Take the statement closing balance, add deposits you recorded but the bank had not yet credited, subtract payments the bank had not yet processed, and you should land exactly on the ledger balance. If agreement only comes from plugging a difference, the reconciliation is not done. It is forced.

Work from the statement, not from the ledger

Fix the cut-off date first, then get the statement for it. Work statement to ledger, line by line: for each line the bank reports, find the entry in the books and match it. The direction matters. Working from the ledger tempts you to tick what the books say happened, and the bank is a witness precisely because it does not care what your books say.

Every line has two possible outcomes. It matches an entry, or it matches nothing and needs a posting. Bank charges, interest, direct debits, and returned items arrive on the statement before anywhere else. Those are postings to make, not items to hunt for, and they belong in this period if the statement date says so.

The work an ERP changes

An ERP such as ERPNext holds the ledger and the matching tool in one place. Statement lines are imported or keyed, matched to payment and journal entries, and the match is stored against the voucher. Reconciliation state becomes data: you can report the unreconciled balance of the bank ledger as at any date, which is exactly what the statement walk needs.

Demand a few mechanics from whatever tool you use. One statement line must be matchable to several entries, and one entry to several lines, because card settlements and batched payouts ignore one-to-one tidiness. Unmatching must be recorded, not achieved by deleting history. Automated rules that create entries from a feed still leave you the matching, and a rule that misposts surfaces here first.

Add-on reconciliation tools exist, and the fair test of any of them is the same short list: import, one-to-many matching, reversible links, ageing of unmatched items. Judge on those, not on the demonstration.

Deposits in transit and outstanding payments

After matching, whatever is left unreconciled should be pure timing. A deposit recorded on the last day that clears on the next statement is in transit. A payment you issued that the bank has not yet presented is outstanding. Both belong on a dated listing, not on a mental list of things to chase next month.

Ageing is the test. In-transit items older than one statement cycle need an explanation. An unpresented payment from months back may be stale, lost, or cancelled; whether you can stop and reissue it, and after how long, depends on jurisdiction and client policy. Check rather than assume.

Separating timing from error

A small worked difference shows the method. The statement closes at 12,480.55. You recorded a deposit of 1,905.00 on the final day that cleared after the statement date, and payments totalling 682.45 are unpresented. The walk: 12,480.55 plus 1,905.00 minus 682.45 gives 13,703.10, so that is the balance the ledger should show.

It shows 13,749.60, a difference of 46.50. On the statement sits a merchant fee of 46.50 with no entry in the books, because the sales rule posted the settlement gross. Post the fee, dated in the period, and the walk lands exactly. Where the difference is untidy, hunt by signature: divisible by nine points to a transposition, divisible by two to an entry posted on the wrong side.

The first reconciliation after a move between systems

A reconciliation in a new system depends on what came across. The opening bank balance is not enough; the conversion must also carry the reconciliation state, or at least a dated list of unreconciled items at cut-over, or the first statement walk cannot tie. Check this before the old system goes cold.

Preserve the evidence first. Keep the statements, the prior reconciliation papers, and the old system's unmatched items list before anyone touches either file. If the conversion dropped or duplicated bank history, no amount of matching will fix it, and at that point it has stopped being bookkeeping. It is a migration repair, and it belongs with a specialist in ERP data conversions, evidence attached.

What belongs in the working paper?

The statement, the matched line listing, the dated in-transit and outstanding items, the adjustments posted, and who prepared and who reviewed. That bundle lets the next person, or an auditor, re-perform the walk in ten minutes. It is what we prepare before calling any bank account clean, and it is what the close deserves in place of an opinion.