Turning bank statement PDFs into spreadsheet rows you can reconcile

[bankstatementcvr]

Most small-business bookkeeping does not fail on arithmetic. It fails on transcription. A statement already exists as a PDF, and someone reads it carefully and retypes 200 rows by hand. That is where a digit slips, a date shifts by a day, and the closing balance no longer matches the figure the bank printed.

The practical fix is to remove the retyping step while keeping the checking step. Those are two different jobs, and treating them as one is why people either trust an extraction blindly or reject it out of habit.

Start with the input. A PDF exported from online banking has a real text layer laid out as a table, so a converter reads structure rather than guessing. A scan of a scan has no text layer and depends entirely on optical recognition. A phone photo sits between the two: lay the page flat, keep the camera parallel to it, and keep all four corners in frame, because perspective and shadow cluster their errors near the row boundaries.

Then match the export to what happens next. Excel when a person will open the file. CSV when it feeds an accounting import or a script, because nothing needs configuring. JSON when the rows merge with another source and the numeric types have to survive the round trip. Separate files keep each account distinct; a merged export is fastest for a period summary but loses the account boundary unless you add a source column first.

Keep the columns you will check against: transaction date, description, debit, credit, and a running or closing balance, plus currency and account identifier so one workbook cannot quietly mix two accounts. If the statement prints a running balance, keep it, because that turns verification from a judgement into arithmetic.

Then reconcile without sorting or tidying. Take the last exported row and compare it against the printed closing balance. Matching to the cent means the table is very likely right. A mismatch means find the difference first, because every total below it inherits that error.

The usual causes are worth knowing in advance: a duplicated transaction where a statement wraps across a page boundary, a multi-line description split into two rows, a currency conversion read from the wrong column, and a bank fee sitting in a separate summary block rather than inside the transaction table. Spot-checking the largest amount, the earliest date, the row nearest the balance, and anything the tool flagged as uncertain is enough.

Categorise with restraint. Work the largest, least ambiguous lines first, derive the rule, apply it to the rest, and leave what you cannot classify visible. An unclassified row is information: a new subscription, a one-off charge, a bank fee, or a row the tool mis-read.

And keep the originals. Store each statement next to its export under the same base name. Six months later the answer is a folder lookup rather than a re-download the bank may no longer offer.

Some statements should be entered by hand: very old archival formats, layouts that depart from the norm, and pages shot at an angle severe enough that a line-by-line check is cheaper than a second extraction. If the balance does not reconcile after two careful passes, manual entry is the honest answer, and recording which files needed it tells you which sources are worth re-exporting next quarter.

If you want to see the shape of the output before committing a month, this browser tool converts a statement PDF or photo into Excel, CSV or JSON: https://bank-statement-converter.online/

The habit matters more than the tool: a recurring slot, every account processed in one sitting, and each balance reconciled before moving on.