Five ways to get bank statements into a spreadsheet

You have a stack of statement documents and a spreadsheet that needs to contain them. Every route from one to the other produces something that looks like a ledger. The difference between them is not how the output looks. It is whether anyone can prove the output is complete.

That is the standard worth applying, because a converted statement with twelve missing transactions can look exactly like a converted statement with none. There are five realistic routes, and they separate sharply once you judge them on proof rather than appearance.

Before any of them, check what your own bank hands you directly. If the online banking portal will export CSV, OFX or QBO covering the exact period you need, take it: that is free, it comes out of the bank's records rather than off a page, and it is the shortest path there is. Route two below is where to start, and the rest of this piece is about what to do when the export does not reach.

The standard: a conversion you can prove

A bank statement carries its own audit trail. The opening balance, the transactions, and the closing balance are bound together by one piece of arithmetic:

opening balance, plus total credits, minus total debits, equals closing balance.

Take a statement that opens at 4,182.55, records credits of 9,310.00 and debits of 7,846.20. The arithmetic gives 5,646.35. If the bank printed 5,646.35 as the closing balance, the extracted rows are arithmetically consistent with the period the bank declared. If a withdrawal of 412.80 was dropped during extraction, the computed closing comes out at 6,059.15, exactly 412.80 too high, and the gap names the size of what is missing.

Be exact about what this buys, because the honest version is still the strongest argument available. A reconciling balance chain catches the error class that does the most damage, a wrong digit in an amount, because a misread amount breaks the chain arithmetically and cannot stay hidden. It does not check that a date parsed correctly or that a description survived intact, and two errors that offset each other exactly will pass it. Within those limits it is the only check that runs across every row on its own, which is why it is worth building a method around.

The check is cheap, decisive on amounts, and almost never run. Every method below either performs it for you or leaves it as homework, and that single distinction predicts which ones survive contact with real work.

1. Retype the transactions by hand

Fully general and fully unverified. Typing handles any document, including scans, photographs and layouts no software has seen, and there is no upload to think about.

The problem is that the accuracy of retyping is entirely a function of the proofing pass, and the proofing pass is what disappears under deadline. A transposed digit in a description is harmless. A transposed digit in an amount is a reconciliation you will chase for an hour next month. Cost also scales badly: forty transactions is a coffee break, a few hundred is an afternoon, and two years across three accounts is a project rather than a task.

2. The bank's own transaction export

Downloading CSV, OFX or QBO from the bank gets you data straight out of the bank's records, so nothing is being recognised from a page. That is a genuine strength, it costs nothing, and when it covers your period it beats every other route here. Check it first, every time.

It is also narrow in ways that show up late. Download windows are commonly capped, 90 days on some portals and 18 months on many others, while the statement archive behind the same login goes back years, so the history you need for catch-up work, a loan file or a disclosure request frequently sits outside the export. Exports often omit the running balance entirely and truncate long descriptions at a fixed width, which removes both the reference field that identifies a transfer and the column you would have read the arithmetic off. A closed account exports nothing at all. And the export covers the period the bank chooses to expose, which is not always the period you were asked to produce.

You can still check an export against the statement, by comparing counts, dates and the printed opening and closing figures. Without a balance column you are doing that by hand instead of reading it off a column, which is fine for one month and painful for two years. Test it on a single statement before relying on it. If the balance column is absent or the range stops short, you are back to the documents, which is where the remaining routes start.

3. A generic PDF to Excel converter

These tools detect a table: they find ruling lines or columns of aligned whitespace, cluster text into cells, and write the cells out. On a clean single-page grid that works.

Statements are not clean grids. Descriptions wrap onto a second line and become a second row with no date and no amount. Page headers and carried-forward subtotals are structurally indistinguishable from transactions and get emitted as rows, which double part of the period. Sign conventions arrive as text, so a trailing minus or a DR suffix lands in a column that will not sum. Debit and credit column pairs get collapsed into one, or split where the statement changes section.

None of that is the core issue. The core issue is what this category does not tell you. A table extractor reports that it found a table, not that the table is a whole ledger. Some document processing products do expose confidence scores, and some let you build validation rules on top, which is worth asking about before you dismiss one. What almost none of them do unprompted is treat the statement's own opening and closing figures as the thing the rows have to satisfy. So the question to put to any general converter is simple: after extraction, does anything compare the result to the printed closing balance? If nothing does, success means it wrote cells. The gap between detecting a table and understanding a ledger is exactly where statements fall through.

4. A desktop OCR or document suite

Heavier commercial recognition tools sit one step up. They cope with scanned pages, they let you draw the table region by hand when detection fails, and they usually run locally.

The cost is that the tuning is per document and sometimes per page, and it evaporates the moment a bank redesigns its statement. The deeper cost is that character recognition is scored on characters, not on what the characters are for. A suite that reads 1,890.00 as 1,390.00 hands you a plausible figure with a high confidence score attached, because confidence in a glyph is not the same as agreement with a balance. Ask what the tool does with the difference; in most of this category, nothing. General assistants land in similar territory with a different failure profile, covered in what happens to a long statement handed to a general assistant.

5. Statement-aware conversion

The last route is the only one built around the standard. Because the input is known to be a bank statement, the tool carries knowledge no general extractor can: which column is a running balance and which is a transaction amount, that the document declares an opening and a closing figure bounding everything between them, that a wrapped description belongs to the row above, that DR and CR are directions rather than text, that a cheque image is not a transaction.

That knowledge is what makes the arithmetic check automatic rather than aspirational. Convert·Into identifies the issuing bank and its layout without a template, verifies the running balance line by line on every statement, and flags any row that does not add up instead of returning a clean-looking file. Extraction accuracy is 99.6%, and the balance check is what makes the remainder visible rather than silent. The reconciliation is not a feature bolted to the end of the pipeline; it is the reason the pipeline exists.

Volume is where this route separates hardest. A forty page business statement is the case where every other method is weakest, because it is exactly where dropped rows hide and where nobody counts. An automatic balance check does not get bored at page thirty, which is the whole of its advantage over a careful person doing the same job at the end of a long week.

Running the standard yourself

Whatever route you take, the file is not finished until it reconciles.

1. 1

   Take the anchors from the document

   Note the opening balance, the closing balance and the transaction count if the statement gives one. These come from the printed page, never from the tool's output.
2. 2

   Count the rows

   Compare the rows in your spreadsheet against the transactions on the statement. A shortfall here is the most common defect and the easiest one to miss.
3. 3

   Total the credits and debits separately

   Keep the two sides apart. A sign error shows up as a pair of subtotals that are individually wrong even when the net figure looks plausible.
4. 4

   Compare against the printed closing balance

   Add credits to the opening balance, subtract debits, and compare with the bank's figure. Nothing else in the process substitutes for this comparison.
5. 5

   Localise any gap by page

   If the two disagree, split the period in half and check each half. Two or three passes narrows a discrepancy to a single page and usually to a single row.

Once the rows reconcile, the remaining choice is the export format, which depends entirely on the software receiving it: Excel, CSV, QBO and OFX are built for different jobs and the wrong one produces its own class of import failure. What should never vary is the order of operations. Verify first, export second, import last.