What is bank statement analysis?

A bank statement is a chronological record produced by your bank: an opening balance, a list of debits and credits, and a closing balance. It is authoritative, which is what makes it useful, but it is also deliberately plain. There are no categories, no totals by type of spend, and merchant names arrive as truncated processor strings rather than the shop you actually visited. Analysis is the work of turning that raw record into something you can reason about.

Extraction

The first job is getting structured rows out of the file. A CSV or Excel export is already tabular, so this is mostly a mapping problem: find the date column, the description column, and whether amounts sit in one signed column or two separate debit and credit columns. A PDF is harder. A digitally generated PDF has text objects that can be read directly, but the column boundaries are usually implicit whitespace rather than actual lines, so the layout has to be inferred. A scanned PDF has no text at all and must go through optical character recognition first.

Reconciliation

Extraction is only trustworthy if it can be checked, and bank statements come with their own check built in. Take the opening balance, add every credit, subtract every debit, and you should land exactly on the closing balance. If you do, no rows were dropped, duplicated or misread in the amount field. If you do not, something is wrong and it needs to be found before any conclusion is drawn from the data. Skipping this step is the single most common reason an analysis quietly produces wrong numbers.

Categorization

Once the rows are known to be complete, each one gets a category: groceries, rent, payroll, software, fuel, loan repayment, transfer. This is what converts a list into an analysis. Categorization can be done by hand, by rules that match patterns in the description, or by a model that predicts a category. Rules are the workhorse because they are reproducible: the same description always produces the same category, and you can point at the rule that made the decision.

Interpretation

With categorized data, the questions become answerable. What is the average monthly income and how stable is it? What proportion of outgoings are fixed commitments rather than discretionary? Which recurring charges are still running? Are there months where outgoings exceeded income, and what caused them? Is there evidence of gambling, of returned direct debits, of an undisclosed loan? Different readers want different answers from the same data, which is why the categorized transaction set, not the summary, is the real deliverable.

Three readers, three different analyses of the same twelve months of statements.

A lender assessing a loan application

The lender wants to know whether the declared income is real and whether the applicant can absorb a new monthly commitment. They look for regular credits matching the stated salary, count existing loan and credit repayments, check for unarranged overdraft usage and returned payments, and calculate what is left after committed spending. A single missed direct debit is not fatal; a pattern of them changes the decision.

An accountant preparing a small company's year end

The accountant reconciles the statements against the sales ledger and purchase ledger, categorizes anything that has not already been matched, separates capital purchases from revenue expenses, and flags personal spending that has gone through the business account so it can be treated as a director's drawing. The output is a clean, reconciled set of transactions coded to the chart of accounts.

A freelancer preparing a tax return

The freelancer needs total income by client, total deductible expenses by category, and a defensible split where an account has been used for both business and personal spending. The analysis produces category totals that map onto the tax return's expense boxes, and a transaction-level export that supports each figure if it is ever questioned.

• It uses the authoritative record. Statements come from the bank. Unlike a self-maintained spreadsheet, there is nothing missing and nothing invented.
• It works retrospectively. You can analyze a period that ended two years ago, or an account that has since been closed. No live connection can do that.
• It surfaces what you forgot. Dormant subscriptions, duplicated insurance, fees you did not know you were paying. These only become visible when a year of transactions is grouped by merchant.
• It produces evidence, not just a number. A category total that is backed by the exact rows behind it can be defended to an accountant, a lender or a tax authority.
• It requires no credential sharing. Statement files are exported by you, so no third party needs access to the account itself.

• Skipping reconciliation. If the opening balance, the transactions and the closing balance do not agree, every total downstream is wrong. Check this first, every time.
• Counting transfers as income or expense. Moving money from savings into checking is not income. Double-counting internal transfers inflates both sides and is the most common error in a first-pass analysis.
• Categorizing by merchant alone. The same shop can be groceries one week and a gift the next. Amount thresholds and account context matter, and some transactions genuinely need a human.
• Analyzing a single month. One month hides annual charges, quarterly tax payments and seasonality. Conclusions drawn from thirty days are usually wrong about the year.
• Ignoring sign conventions. Banks differ on whether a debit is negative or sits in its own column. Getting this wrong flips the entire result and is surprisingly easy to miss when the totals still look plausible.
• Trusting OCR output unchecked. On a poor scan, an 8 becomes a 3 and nothing warns you. Only the balance check catches it.