Santander Statement to Excel Converter

Separate money in and money out columns and a running balance make manual re-keying slow and error-prone — one misplaced figure breaks the reconciliation.

FlowParse reads the whole statement at once, signs amounts correctly, and validates the balance, turning the job into a quick, reliable conversion.

Santander uses the UK grid — date, description, the two money columns and a running balance — as one continuous table. Direction comes from which column a figure sits in rather than from a sign, and the balance column supplies a per-row anchor for checking.

The practical consequences are the familiar UK ones. Merging the two money columns destroys direction while leaving every amount intact, which produces a plausible-looking file and a reconciliation out by exactly twice the affected total. The balance column is a position rather than a movement and belongs in the verification rather than in the transaction list.

Where Santander differs from most banks on this list is not the statement layout but what else it offers alongside it — and that is worth understanding before you decide whether to convert a PDF at all.

Santander offers a real transaction export, and we would rather point you at it than pretend otherwise. In Online Banking you choose either all available transactions or only those since your last download, pick a format, and download. The formats Santander lists are Microsoft Excel, Quicken, Adobe Acrobat (PDF) and Microsoft Money.

There is one hard limit, and it is specific: you can only download 600 transactions per download. Santander's own guidance notes that if you have a lot of transactions you may need to limit the date range and perform more than one download.

For a quiet personal account that is no constraint at all. For a busy current account or a business account it is a real one — six hundred transactions can be a couple of months — and it turns a single export into a series of them, which is where the problems start.

The since-last-download option deserves particular care. It is stateful: it depends on the system's record of what you previously took, not on a date range you chose. Run it from two different sessions, or after somebody else has run it, and you can silently get a partial set. A date range you specify yourself is reproducible; a since-last-download is not.

Verified against Santander UK's own download-transactions help page, August 2026.

Once the 600-row cap forces more than one download, you have the same problem as anyone merging sources: overlap in one direction and gaps in the other, neither of which announces itself.

Overlap happens when consecutive date ranges share a day. Every transaction on that day is then counted twice, which inflates turnover and expenses together while leaving the closing balance looking plausible. Gaps happen when consecutive ranges leave a day uncovered — and a missing day is invisible, because the transactions either side of it are all perfectly correct.

Do not try to fix this by removing duplicate-looking rows. Two identical rows can be entirely genuine: the same amount at the same merchant on the same day is an ordinary occurrence, and deduplicating on similarity creates a gap where there was a duplicate. Compare the periods each download covers instead, which is unambiguous.

The check that settles it is the balance. Within any statement, opening plus every transaction should equal the printed closing figure. Across a series, each closing balance should equal the next opening balance. If your stitched-together exports reconcile against the statements for the same period, the join is right; if they do not, the size of the difference tells you whether you are looking at a duplicated day or a missing one.

This is the argument for using the statements as the spine even when an export exists. A statement carries printed opening and closing balances, so it can prove its own completeness. A CSV of transactions carries no such thing — it is a list, and a list has no way of telling you that something is missing from it.

Four failure modes, three of them shared with UK banking generally and one specific to the export route.

The two money columns merged. Direction lost, payments read as receipts, difference of exactly twice the affected total.

The balance column imported as a transaction. A position treated as a movement, inflating the file by the size of a balance.

Rows lost at a page break, where repeated column headings either enter the data or take the genuine first rows of a page with them. The row chain closes over that gap and stays continuous, so it is the document-level check that finds it.

And the export-specific one: a 600-row download silently truncated. If a period genuinely contains more than six hundred transactions and only one download was taken, the file is short and nothing in it says so. Count the rows against what the account shows for the period, and reconcile the total against the statement — the two together catch a truncation that neither catches alone.

The six-hundred-transaction limit is a minor detail on a personal account and a genuine operational constraint on a busy business one, because it scales in exactly the wrong direction: the more activity an account has, the more separate downloads a period requires, and the more joins there are to get wrong.

A retail or hospitality business taking card settlements daily, or any business paying suppliers weekly, can pass six hundred transactions in a matter of weeks. Assembling a financial year then means many downloads rather than a handful, each with a date range someone chose by hand, and every boundary between them is a chance to overlap by a day or leave one uncovered.

Statements do not have this problem, which is the practical argument for using them as the backbone of a year end. A statement covers whatever period the bank issued it for, contains every transaction in that period by construction, and prints the opening and closing balances that let you prove it. Twelve monthly statements are twelve self-verifying units; twenty-odd hand-ranged exports are twenty-odd opportunities for a boundary error.

A reasonable working pattern for a business account is to use the export for the current period, where it is quick and the volume is small, and the statements for anything historic or anything being reported on. Then reconcile the two against each other for any period where both exist — if the export and the statement for the same month agree on the total and the count, both are sound.

And keep a source column throughout, recording which download or which statement each row came from. When a figure is questioned months later, the first thing anyone needs to know is where it came from, and a merged sheet without provenance turns a two-minute answer into an afternoon of re-opening files.