The bank statement, line by line

Why this chapter matters most

The bank statement is where the books meet the outside world. It is also where most small-business bookkeeping errors live, because coding a bank line is a judgement made quickly, hundreds of times.

Get this screen right and the rest follows: the GST return falls out of the coded transactions, the reports are sums of real rows, and the reconciliation tells you whether you are finished. Get it wrong and every later figure is wrong in a way that is hard to see.

Import

Download a CSV from your internet banking, then drag it onto Bank & coding and say which account it came from. ByteBook reads the columns, works out which is the date, the description and the amount, and skips anything that has already been imported, so importing the same file twice does not double the books.

If your bank's export looks unusual, the page offers a CSV template showing the shape ByteBook expects.

Code each line

Every imported line is a question: what was this for? You answer by choosing an account. ByteBook guesses from the description, and you confirm or correct it.

Three answers are possible:

• Code it to an account. The line becomes a real transaction in the books.
• Mark it as not business. The line stays on the statement and out of the reports. A personal coffee on the business account belongs here, or better, it belongs in drawings.
• Leave it waiting. Nothing in the reports moves until you decide.

The screen tells you how many lines are waiting. Until that number is zero, the books are incomplete, and a report run now is a report on part of the period.

Does it agree with your bank?

There is a second half to the screen, and it is the one that turns coding into assurance. Enter the closing balance and the date from your bank statement, and ByteBook compares its own bank balance with the bank's figure.

Two agreements matter.

The bank agrees. The balance ByteBook holds for the bank account equals the balance on the statement at the statement's date. If it does not, either something has not been recorded, or something has been recorded twice, or the date is wrong. This is bank reconciliation, and it is procedure A03 in chapter 13.

Every line has been dealt with. The number waiting to be coded is zero, and nothing has been left in a half-finished state. A reconciliation that matches on the balance but has twenty unceded lines is not a reconciliation.

Why the reconciliation is evidence

An auditor treats a bank confirmation as strong evidence, because the answer comes from outside the business. The auditing standard on external confirmations deals with the auditor's use of a confirmation request, and requires further evidence where the reliability of a response is in doubt ISA (NZ) 505.10. The statement you import is the same kind of evidence: it was produced by the bank, not by the business.

That is why the reconciliation is worth doing even when the balance already looks right. It is not arithmetic housekeeping. It is the test that ties the books to something outside them.

Common mistakes

• Coding a line to the wrong side. A payment received coded as an expense cancels the error in the total while leaving the GST and the customer balance wrong.
• Coding GST-inclusive bank amounts as exclusive. The bank line is what left the account, GST included. ByteBook needs to know whether that figure includes GST so it can split it.
• Reconciling to the wrong date. Agree the balance at the statement's date, not at today's date.
• Marking a business line as not business to clear the list. The waiting count goes down and the books get worse. If you are unsure, leave it waiting and find out.