How to Convert a Scanned Bank Statement to Excel or CSV

Why are scans and photos harder to convert than digital PDFs?

A digital PDF downloaded from online banking contains actual text: every character and its position on the page is stored in the file. Conversion is a matter of reading structured data that is already there. A scan or phone photo contains none of that — it is only a picture, and every digit, date, and description has to be recognised from pixels.

That recognition step introduces failure modes that native PDFs never have. Skew and perspective distortion make table rows drift, so an amount can end up attributed to the wrong transaction or the wrong column. Uneven lighting puts shadows across figures or glare on glossy paper, hiding parts of characters. Low resolution blurs the difference between a 6, an 8, and a 0, and can make decimal points and thousands separators vanish entirely. Physical artefacts — bank stamps, handwritten notes, highlighter, hole punches, fold creases — sit on top of the very text that needs to be read. Photocopies of photocopies compound all of this.

The uncomfortable part is that a misread digit usually looks plausible. A description with a garbled letter is obvious; £1,840.00 read as £1,340.00 is not. That is why, for scanned statements, verification is not a nice-to-have — it is the core of the workflow, and it is worth choosing a scanned statement converter that checks its own output rather than one that simply hands you a table.

How do you photograph a bank statement so it converts well?

Most conversion failures are capture failures. A minute of care with the phone camera saves far more time than fixing misread rows later. The rules are simple:

• Lay the page flat on a dark, contrasting surface. Press out fold creases with your hand or a book for a few seconds first — a page curling at the edges distorts the columns nearest the fold.
• Get all four corners in frame. Cropped edges are a leading cause of missing transactions, because the first or last rows of the table are simply not in the image.
• Hold the phone parallel to the page, directly above it. Shooting at an angle creates perspective distortion that makes columns converge, which is exactly what row-and-column recognition struggles with.
• Use even, indirect light. Daylight near a window works well. Avoid flash on glossy paper (glare wipes out whole regions) and watch that your own shadow is not falling across the figures.
• One page per shot. Do not photograph a two-page spread in a single frame — resolution per character halves and the centre fold distorts both pages.
• Fill the frame and check legibility. Zoom into the smallest printed digits on your photo. If you cannot read them clearly, no software can either. Retake rather than hope.

The same logic applies to flatbed scanners and scanner apps: scan flat, scan straight, and use a reasonable resolution — 300 DPI is the common-sense standard for documents with small print. A clean, straight scan at sensible settings removes most of the failure modes that make images harder to read than native PDFs.

How do you verify the numbers from a scanned statement?

Proofreading every row against the image is slow and unreliable — after fifty rows your eyes glaze over. The efficient check is arithmetic: the opening balance, plus every credit, minus every debit, must equal the closing balance to the cent. A single misread amount breaks that chain, so a statement that reconciles end-to-end gives you strong evidence that the transaction amounts were read correctly.

BankStatementWise runs this check on every conversion automatically: each statement is reconciled against its own printed opening and closing balances, and every extracted row carries a confidence mark. Where the image genuinely does not support a confident reading — a smudged digit, a stamp over an amount — the row is flagged rather than silently guessed. A digital PDF carries its text inside the file, so there is little uncertainty to flag. For scans and photos, the flags are the whole point: they tell you exactly which handful of rows to compare against the original image, instead of proofreading two hundred.

So the working routine for a scanned statement is: check the reconciliation result first, then review only the flagged rows against the source image, correct anything the paper contradicts, and move on. Descriptions deserve a lighter touch — a slightly garbled payee name is cosmetic, whereas dates and amounts are what your books depend on.

How should you handle multi-page scans and photos?

Photograph or scan pages one at a time, in order, and keep them in a single file if your scanner app can produce a multi-page PDF — most can. Order matters more for scans than you might expect: the running balance continues from page to page, and 'balance carried forward' lines are part of the arithmetic chain, so shuffled pages read like a broken statement.

If a page is missing from the middle, the reconciliation check will expose it — the balances simply will not connect — which is far better than discovering a gap at year-end. Statements that cover more than one account are kept separate in the output, with each account's transactions and balances in their own set, so a combined household or business statement does not turn into one merged jumble.

On timing: a typical single statement converts in around four to six seconds, and a large multi-month packet typically takes about thirty seconds. Uploading a twelve-page scan as one document is entirely normal.

When is a scan too degraded to convert?

There is a floor below which no tool reads reliably, and the honest test is your own eyes: zoom into the image, and if you cannot confidently distinguish the digits yourself, automated recognition will not do better. Common lost causes include thermal-paper printouts that have faded to grey, fax copies several generations removed from the original, heavy highlighter directly over amount columns, and photos so blurred that decimal points have disappeared.

Before giving up, work up the quality ladder. If you still have the paper original, re-photograph it with the technique above — most 'bad scans' are just bad captures of good paper. If the statement came from a bank, log in to online banking and download the digital PDF instead; most banks keep several years of statements available, and a native PDF sidesteps every problem in this guide. Failing that, rescan at higher resolution on a flatbed.

When part of a page is genuinely unrecoverable, partial automation still beats manual entry: the readable rows convert, the unreadable ones are flagged, and you key in the flagged handful by hand. Because you can upload a statement and preview the complete result for free, without creating an account, the cheapest way to find out whether a marginal scan is usable is simply to try it. There is no bank login involved at any point — you upload a file you already have, and documents are used only to produce your results, never sold and never used to train systems.

What do you get once the scan converts?

The output is the same as for any statement: a clean transaction table with dates, descriptions, amounts, and running balance. Amounts and balances export as real numeric cells, so SUM checks and pivot tables work immediately — no stripping of currency symbols or retyping. You can download the result as Excel, CSV, JSON, or OFX; OFX imports directly into Xero and QuickBooks Online, while CSV covers QuickBooks Desktop and ordinary spreadsheet work.

If the scanned PDF is password-protected, the password is used only to open the file and is never stored. And if you create a free account, your conversions stay in a workspace so you can re-export in a different format later without re-uploading the scan.