Lloyds Bank Statement to Excel Converter

With separate money in and money out columns, a type code and a running balance, re-keying a Lloyds statement into Excel is slow and easy to get wrong — a misplaced figure breaks the balance.

FlowParse reads the whole statement at once, signs every amount, keeps the type code, and validates the running balance, so the task becomes a quick, reliable conversion.

A Lloyds statement carries Date, Description, Type, Money In, Money Out and Balance. It is one continuous table, and the Type column is the feature that distinguishes it from most non-UK layouts.

The two money columns work the way they do across UK banking: direction is carried by which column a figure sits in rather than by a sign, and on most rows one of the two is empty. Merging them during extraction is the classic failure — every amount survives, direction does not, and the reconciliation misses by exactly twice the affected total.

The Balance column provides a per-row anchor, so the row-to-row check is available: each balance minus the previous one should equal that row's signed amount. That localises a misread figure to a specific row instead of leaving you to search the statement, which is a real advantage over block-grouped layouts that print no running balance.

FlowParse merges Money In and Money Out into one signed amount, keeps the Type code as its own field rather than folding it into the description, excludes the Balance column from the transaction list, and checks the result both row to row and against the opening and closing balances printed on the statement.

UK statements carry a short type code against each transaction — a two- or three-letter abbreviation distinguishing direct debits, standing orders, faster payments, card payments, cheques, cash machine withdrawals and transfers. The exact codes vary between banks, so it is worth reading your own statement's key rather than assuming a universal set.

It is easy to treat this as clutter and drop it. That is a mistake, because the type is frequently the only reliable signal of what a transaction actually was. A direct debit to an energy supplier and a card payment to the same supplier are different events with potentially different accounting treatment, and the description alone often cannot tell them apart.

The type also carries information the description does not. A standing order is a fixed instruction you control; a direct debit is a variable one the recipient controls. When reviewing costs, the distinction tells you which payments can be changed unilaterally and which require contacting the counterparty — genuinely useful when someone asks where money is going.

For automated categorisation the type is more stable than the description, which is why it is worth preserving as a separate column rather than appending it to the text. Bank descriptions change format without notice as payment systems are updated; the type code is a much smaller vocabulary and changes far less. A categorisation rule keyed on both is considerably more durable than one keyed on description alone.

There is a practical caveat worth stating: a type code tells you the payment mechanism, not the purpose. It distinguishes a direct debit from a card payment, and it has nothing to say about whether either was a business cost, a personal one, or a transfer between your own accounts. That judgement stays with a person, and no bank-side code will ever supply it. What the type does is remove the mechanical half of the guesswork, leaving the half that actually requires knowing the business — which is the right division of labour, and the reason a converted statement should carry the code rather than an opinion about what it means. Keep the raw code in the export and put your own categorisation in a separate column beside it, so the two never get confused and the original is always there to re-derive from.

FlowParse keeps Type as its own field in the export, so it is available for filtering and for rules rather than buried inside a description string.

Four failures account for most of the trouble, and each leaves output that looks reasonable.

Money In and Money Out merged. Direction disappears, payments read as receipts, and the difference is exactly twice the affected total — the clearest arithmetic fingerprint there is.

The Type column folded into the description. Nothing looks broken and the categorisation downstream is quietly worse, because the most stable signal about what a transaction was has been buried in a text field.

The Balance column read as an amount. A position imported as a movement, inflating the file by the size of a balance. Usually large enough to notice, which makes it one of the more forgiving errors.

Rows lost at a page break. Column headings repeat at the top of each page; where they are not recognised as repeated furniture, either they are imported as transactions or the genuine first rows of the page are dropped along with them. The row-to-row balance chain cannot see this — it closes over the gap and stays continuous — so it is the document-level check that catches it.

For a year end, a mortgage application or a bookkeeping catch-up, run two checks, because they answer different questions and have different blind spots.

Within each statement: opening balance plus every transaction should equal the printed closing balance. That proves the document is whole — nothing lost at a page break, no balance figure imported as a transaction.

Between statements: each closing balance should equal the next statement's opening balance, exactly, right through the period. That proves the series is unbroken. A folder can contain twelve perfectly balanced statements and still be missing a month, and the gap is invisible from either side because every surviving document reconciles on its own terms.

Keep current accounts, savings and credit cards as separate series when you do this. They are separate balance chains, and joining them produces a comparison with no meaning. Where money moves between two of your own accounts, that is an internal transfer rather than income or expenditure — booked as trading it inflates turnover and costs by the same amount while leaving profit untouched, which is precisely why the error survives a review that only looks at the bottom line.

On retention: how far back Lloyds makes statements available differs between online banking and the mobile app, and the figures change over time. Their public help pages did not return a citable answer at the time of writing, so rather than repeat a number we cannot verify from Lloyds' own published page, check the current window in your own banking — and download what you need while the account is open, since closing it removes self-service access at every bank.