Reading a bank statement: every column explained

A bank statement is not your record of your money. It is an extract from the bank's own books, written from the bank's point of view, and almost every confusion about it starts there.

From the bank's side, your deposit is a liability: it owes you the balance. So money you pay in increases what the bank owes you and appears as a credit, and money you take out reduces it and appears as a debit. Anyone who has kept books in the ordinary way, where cash received is a debit to cash, reads the columns and finds them inverted. They are not wrong and neither is the statement; they are two parties recording the same event from opposite sides.

This is also why the statement is authoritative about some things and silent about others. It knows exactly when the bank's records moved and by how much. It does not know why. It cannot tell you which invoice a receipt settles, whether a debit was authorised by you or by someone with your credentials, or whether a charge is correct. Everything useful you can extract from a statement comes from combining what it records with information it does not hold, which is what makes reconciliation a separate activity from reading.

Most statements carry two dates and the difference between them is the most commonly misread thing on the page.

The transaction date, sometimes labelled the posting or booking date, is when the entry was recorded. The value date is the date from which the amount counts for the purpose of interest and available balance — in effect, the date the bank treats the money as genuinely yours or genuinely gone.

They diverge whenever an instrument or a system introduces a delay between the entry appearing and the funds being realised. A cheque deposited late in the day may be posted on that day with a later value date. A transaction executed after a cut-off can carry the next working day's value date. In accounts where interest is calculated on daily balances, the value date is the one the calculation uses, so an account can show a healthy posted balance and still be treated as having had less available.

The practical consequence is specific: when you are checking whether a payment was made in a particular month or a particular financial year, the transaction date is usually what your books need to agree with, and when you are questioning an interest or charge calculation, the value date is the column the bank will point at.

The narration or description column carries whatever the originating system wrote, and it is the only column that tells you what a transaction was. It is also the column with no common format, because each rail structures it differently.

A few patterns make it readable. A UPI entry typically embeds the transaction reference along with the payer or payee's virtual payment address and often a note, which means the counterparty is usually identifiable from the narration alone. NEFT, RTGS and IMPS entries carry a reference number — the unique transaction reference, commonly called a UTR — and typically the remitter's name and the originating bank. That reference is the single most valuable string on the whole statement: it is what a bank traces a disputed or missing payment by, and quoting it turns an enquiry from a description into a lookup.

Cheque entries carry the cheque number in its own column or inside the narration. Charges tend to be terse and abbreviated, which is why bank charges are the entries most often left unidentified in a reconciliation. Where a narration is genuinely opaque, the bank can supply the underlying detail against the reference, and it is worth asking rather than guessing, because a misattributed entry survives in the books far longer than an unexplained one.

The three amount columns are the arithmetic of the statement, and the running balance is the column that lets you check the other two.

The running balance after each entry should equal the previous balance plus that row's credit or minus its debit. That is a trivially checkable property, and it is worth checking on any statement you have received in a form that could have been altered — a spreadsheet, a retyped extract, a scan of unknown provenance — rather than downloaded directly from the bank. A statement whose balances do not chain is not a statement.

The opening and closing balances are the joins to the adjacent periods. The closing balance of one statement must be the opening balance of the next, and a break there means a period is missing, which is the commonest reason a set of statements assembled from downloads does not add up.

One detail on order: entries with the same date are not necessarily listed in the sequence they occurred, and the running balance follows the statement's order rather than the clock. For most purposes that does not matter. It matters when you are trying to establish whether a balance was sufficient at a particular moment, and for that the sequence on the page is not reliable evidence on its own.

Certain problems have recognisable shapes, and knowing the shape is most of finding them.

A duplicate debit appears as the same amount to the same counterparty, usually on the same or the following day, sometimes with different references. Two genuine identical payments do happen, which is exactly why duplicates survive review — they are individually plausible.

A failed transaction that was debited and not reversed appears as a debit with no corresponding credit within the following few days. Reversals normally arrive automatically, and the absence of one is the thing to look for rather than the original debit.

Standing instructions and mandates produce regular debits of similar amounts on similar dates. The ones worth examining are those you no longer recognise: a mandate given for a service long since stopped continues until it is cancelled, and it is the statement, not the provider, that will tell you it is still running.

Charges are the category most often accepted without checking. Non-maintenance charges, cash-handling charges beyond a free allowance, cheque return charges and transaction charges all appear as small debits with abbreviated narrations, and the only way to know whether one is correct is to read it against the schedule of charges for that specific account variant.

This is the case where the statement stops being a bookkeeping document, and where the mechanics are worth knowing before you need them.

The Reserve Bank has a customer-protection framework limiting a customer's liability for unauthorised electronic banking transactions, and its central mechanic is that liability is not determined by the amount but by two things: where the fault lay, and how quickly the customer reported it. Where the loss arises from a third-party breach and the customer is not at fault, the framework provides for zero liability if the transaction is reported within three working days of receiving communication about it. Beyond that, liability is tiered by the delay in reporting, with caps that depend on the type of account, and further delay is dealt with under the bank's own board-approved policy.

Two consequences follow. Reporting speed is the variable the customer controls, and it is measured from the communication about the transaction — which is a reason for keeping transaction alerts switched on and read. And banks are required to have a documented complaint channel and to credit reversals within specified timelines.

The tiers, caps and timelines are set out in the Reserve Bank's own circular on limiting customer liability and have been amended, so the current text of that circular and your bank's published policy are the authorities, not a summary.