How Exact-Copy Extraction Works — Any Bank, Typed or Scanned

Geometry first, text second

Most converters work from templates: they recognise a known bank layout and map it into fixed output columns. That breaks the moment a bank redesigns its statement, and it quietly rewrites your data on the way through.

Statement Converter works from the page itself. Every word on the page is extracted with its coordinates — from the embedded text layer on digital PDFs, or from OCR coordinates on scans. Words are grouped into visual lines, the bank's own header row is detected, and each column's horizontal range is derived from where the bank actually printed it.

One row per printed transaction

Statements wrap long descriptions onto continuation lines. A naive converter turns one transaction into two or three rows, which breaks counts and sums. The parser recognises continuation lines — no date, no amount in an amount column, text landing in description-like columns — and merges them back into their parent row.

The no-loss invariant

Every workbook carries a Full_Text sheet: page number, line number, source, and text for every visual line of every page, in reading order. Account headers, footers, summary blocks — everything the table view filters out stays recoverable. The rule is simple: every extracted line appears in the workbook at least once.

That is also why the output deliberately avoids normalisation. Amounts stay as printed text (£1,234.56 stays £1,234.56, 1.234,56 stays 1.234,56), dates are never reinterpreted, and columns keep the bank's own names. You decide what to clean up — with the original always in view.

Scanned statements

Scans route through OCR into the same layout reconstruction. Multi-word OCR boxes are split so each token lands in its own column, and tokens snap to the column holding most of their width. Very poor scans are flagged so you can retry in high quality.