What a bank statement can prove, and what it cannot

Someone has asked you to prove something and you have reached for a bank statement. A tax authority wants proof of an expense, a landlord wants proof of income, opposing counsel wants proof that a transfer happened. The statement is genuinely strong evidence, but of a narrower fact than most people assume, and the distance between the fact it carries and the claim it is being asked to support is where applications get rejected and disclosures get challenged.

A bank statement is the bank's record of what moved through an account. That is its whole content and its whole authority. It carries weight because a third party with no stake in your claim produced it in the ordinary course of its own business, from a system it relies on for its own accounts.

What the document actually records

Every line asserts four things on the bank's own authority: the date the entry posted, the amount, the direction of the movement, and the balance that resulted. The header asserts the account holder, the account number, the period covered, and the opening and closing balances for that period.

That is a substantial set of facts. A statement is good evidence that a payment of 4,200.00 left the account on 14 March and that the balance afterwards was 6,318.90. If the dispute is whether money moved at all, the statement usually settles it.

One of those fields is less literal than it looks. The posting date is when the bank recorded the entry, which is not always the date the transaction occurred: a card payment made on a Friday evening can post on the Monday, and a cheque posts when it clears. If your claim depends on a transaction falling inside a specific period, the posting date is what the statement gives you and it may not be the date that matters.

What it does not establish

The statement is silent on everything that happened outside the bank's ledger.

• Purpose. A 4,200.00 payment to a builder proves the builder was paid. It says nothing about whether the work was a repair to a rental property or a new kitchen at home, and that distinction is the whole question in a deduction dispute.
• What was received. No line item, no quantity, no description of goods. A single payment can cover a mixed basket, and the statement cannot split it.
• Who ultimately benefited. Money paid to an intermediary looks identical to money paid to the end recipient.
• Whether a deposit is income. A loan drawdown, a refund, a transfer from your own second account and a client payment all arrive as credits in the same column.
• Gross figures. When a fee is deducted at source, the statement shows the net. The deposit is real and the gross amount is invisible, which is the usual reason a 1099 total disagrees with what actually landed.

The description field is the weakest thing on the page

Card and transfer descriptions are strings assembled by the payment network and the bank, not identifications of a counterparty. The name that appears is often the acquiring entity, a parent company, a payment aggregator, or a trading name registered years ago. The same merchant can appear three ways in one month depending on whether the payment went through a terminal, an app or an online checkout.

This matters when someone is reading your converted spreadsheet to identify a relationship. A description is a pointer to the underlying document, and that is the level of confidence to put on it. Where a matter turns on who received money, the reliable route is to pair the amount with a date window across the accounts involved, which is how transfers between accounts are traced in practice.

A converted spreadsheet is a derivative

Converting statements into a workbook does not change what the underlying evidence is. The spreadsheet is a working copy, and its authority runs entirely through the document it was extracted from. Three habits keep that link intact and are worth building in from the first file: keep the original statement documents unaltered, record how the conversion was done, and carry a source file and page reference on every row so any figure can be walked back to the page it came from. That is the substance of keeping a converted record defensible when the other side asks how the numbers were produced.

What the arithmetic check proves

The strongest automatic check available on a converted statement is the running balance. Recalculate it line by line: opening balance plus credits minus debits, row after row, and compare each result against the balance the document prints. That catches the error class that matters most, a wrong digit in an amount, because a misread amount breaks the chain arithmetically. A 3 read as an 8 in the units place moves the amount by 5.00; the same misread in the hundreds place moves it by 500.00. Either way every balance from that row onward is out by exactly that difference, and the break points at the row that caused it.

A row that vanishes entirely is caught by the same equation. Drop the 4,200.00 line and the row printed underneath it no longer follows from the row above: the document's own balance column has fallen by 4,200.00 that your recomputed column never lost, and every row from the omission onward carries that gap until the file rejoins the printed figures. Duplicating a row does the same in the opposite direction. This is precisely the difference between recomputing each row and merely confirming that the closing balance ties. A closing-figure check is defeated by any two errors that cancel, and a dropped 4,200.00 with a duplicated 4,200.00 cancels exactly: the closing figure agrees while the file is wrong twice. Row by row, that same pair has nowhere to hide, because every row between the omission and the duplicate fails its own equation.

Be precise about the limit, because overstating it is how a converted file loses credibility under scrutiny. The recomputation is a statement about the amount column and about nothing else on the row. It has no view on whether 14 March is the date the statement printed, no view on whether the description names the builder or the acquirer that processed his terminal, and no view at all on whether the 4,200.00 bought a repair or a kitchen. A row whose amount is zero passes it without being read, because nothing in the equation moves. So does a row where the amount and the balance beside it were misread consistently, leaving the equation true on wrong figures. And the whole check is unavailable on statements that print no running balance next to the transactions, which leaves the weaker comparison of a closing figure against the sum of the movements. Say that the amounts reconcile against the balances the bank printed. Do not say the file is correct.

Match the document to the question

Before you send a statement, write down the exact proposition it is meant to support, then read the statement and ask whether the bank asserts that proposition. If the proposition is "I paid 4,200.00 to this contractor on 14 March", the statement carries it. If the proposition is "that 4,200.00 was a deductible repair", the statement carries the payment half and the invoice carries the rest, which is the distinction that decides whether a statement line substantiates a deduction.

Run the propositions you actually need through that test before you send anything. The sorting is usually obvious once the question is written down.

Everything in the first two rows is asserted by a third party in the ordinary course of its own business, which is where the statement's weight comes from. Everything below them needs a document produced by whoever actually knows the answer, and the right-hand column is the pairing rule written out.

Converting a run of statements into a clean, verified spreadsheet is what makes that comparison quick across hundreds of rows, because the arithmetic is settled before anyone reads a line.

Held to that standard, a hand-keyed spreadsheet is the weakest option in the room: it has no arithmetic check at all, so a transposed figure enters the record silently and the first person to notice is the reviewer who was deciding whether to believe you.