Bank transactions, and how they reach your statement

A bank transaction is any movement of money into or out of an account. That is the whole definition, and it is not the part people get stuck on.

What causes trouble is everything around it: why the date is not the date you spent, why a payment sits in limbo for three days, and why your deposit is called a credit when the bank’s own ledger calls it a debit.

Credit and debit are relative to who is speaking

On your statement, money in is a credit and money out is a debit. This feels backwards to anyone who has used a debit card to spend, and it is backwards, in the sense that it is written from the bank’s point of view.

Your current account is a liability to the bank. It owes you the balance. When you deposit money the bank owes you more, so it credits your account. When you spend, it owes you less, so it debits your account. In the bank’s own books the entries are the other way around, because every entry has two sides.

You do not need double entry bookkeeping to read a statement. You need to know that on the statement you receive, credit means in.

The eight types that cover almost everything

Type	What it is	Typical delay to post
Card purchase	Debit or credit card at a merchant	1 to 3 business days
ATM withdrawal	Cash out	Same day, often instant
Direct debit	A company pulls a variable amount you authorised	Same day
Standing order	You push a fixed amount on a schedule	Same day
Bank transfer	Push payment to another account	Seconds domestically, days internationally
Cheque	Paper instruction, still alive in the US	2 to 5 business days to clear
Fee	Charged by the bank: maintenance, overdraft, foreign use	On the charge date, or batched at period end
Interest	Paid to you, or charged on an overdraft	Once per statement period

The distinction that matters in practice is between a push payment, which you initiate, and a pull payment, which someone else initiates against your authorisation. Direct debits are pulls, and that is why they can change amount without you doing anything, and why they are the ones to look at when a statement has something unexpected on it.

The life of a card purchase

Card transactions explain most of the confusion on a statement, because there are four moments and only one of them appears.

An authorisation can also expire. If a merchant never claims it, typically within a week, the hold drops and the money comes back without any transaction ever appearing. Hotels and fuel pumps do this constantly: the pump authorises a round amount and claims the real one days later.

Two dates, and which one your statement uses

The transaction date is when you spent. The posting date is when the money moved. Bank statements usually show the posting date and nothing else. Credit card statements often show both, because the transaction date decides which billing period a charge belongs to.

This matters when you are matching receipts to rows. A receipt dated the 31st can legitimately appear on the following month’s statement, and that is not an error to chase.

What the description field is actually telling you

The description is not free text written by a human. It is assembled from fields the payment network passes along: a merchant name truncated to a fixed length, a location, a terminal or store number, and sometimes a scheme prefix.

That is why you get SQ *ARDEN COFFEE, where SQ marks a Square terminal and the real business name follows, or TFR FROM J MORLEY, or a card number fragment on the end. Prefixes like POS, ACH, DD, SO, FPI and BGC are network and product codes rather than anything the merchant chose. They are worth learning: the codes on a statement resolve most mystery rows in a few seconds.

How transactions come out in an export

When a statement becomes a spreadsheet, the transaction structure has to survive, and three things commonly do not:

The sign. Some statements use one amount column with negatives, others use separate debit and credit columns. Collapsing two columns into one is where refunds turn into spending. Check a known refund after any conversion.

The description. Long merchant strings wrap onto a second line in the PDF. If the wrap is not rejoined you get a row with a description and no amount, followed by a row with an amount and half a description.

The running balance. Not every statement has one, but if yours does, it is the only thing that proves the export is complete. Each balance should equal the one before it plus that row’s amount. Our converter walks that chain and tells you where it breaks, which catches a dropped row that no amount of reading down the page will.

The practical version

For reading a statement, three rules cover it. Credit is money in. The date is when it posted, not when you spent. And anything you do not recognise is nearly always a merchant trading under a different name from the one on the shopfront, which a search for the exact description string will usually settle before you call the bank.