Whichever order your JAK Members Bank statement prints its columns in, each one still has to land in the right place once it reaches a spreadsheet. Column mapping begins as soon as the statement is read. The engine detects the transaction table, recognises which columns hold the date, description, debit, credit and running balance, and assigns each one to the correct field in the export. You can review and adjust the mapping before the file is written: drag a column to a different field, skip a column you do not need, or combine two columns into one. The mapping screen shows a live preview of the first few rows mapped against your chosen export structure, so you can see exactly what will land in the spreadsheet or ledger before you commit. When the mapping is correct, the full statement exports with every transaction in its proper place.
When your JAK Members Bank statement arrives as a scan or a photo of the page rather than a clean export, the numbers on it are just pixels until they are extracted. Photographed and scanned statements follow the same pipeline as digital originals. The engine applies OCR to read the image, then runs the same layout detection and transaction extraction it uses on a clean file. The running-balance verification becomes even more valuable here: if the OCR misreads a digit, the running total from that row onward will not match the printed closing figure on the statement, and the row is flagged for your review. You can correct the flagged value without reprocessing the whole statement, and the balance logic recalculates from that point forward so the verification stays intact.