Whichever order your Shawbrook Bank statement prints its columns in, each one still has to land in the right place once it reaches a spreadsheet. Column mapping follows the structure the engine detected during extraction. Date, description, money in, money out and balance are each recognised by their position and label on the statement document, not by a rigid template. That means the same layout logic that identified the transaction table also assigns each column to the correct field in the export, so reformatting after the fact is rarely needed. If the bank prints separate debit and credit columns, the engine keeps them distinct; if the bank prints a single amount column with a sign, that sign is preserved and the column is mapped accordingly. The result is a file where every column arrives in the place you expect, in the same order every time, ready for import into accounting software or for further work in Excel.
Should a description on your Shawbrook Bank statement break across multiple lines of the printed page, that line break is not the same thing as a new transaction. When a transaction description wraps across multiple lines, the engine groups those lines back into a single row. Statement documents often break long descriptions midsentence, and a parser that treats every new line as a new row will split a single transaction into fragments. The engine reads the layout of the full table and identifies which lines belong to the same row by checking alignment, indentation and the presence of amounts on the same line. A continuation line that carries only text is rejoined to the item above it before the row is written out, so a single payment to a supplier with a long reference arrives in your export as one row, not three.
If the Shawbrook Bank statement you have is a scanned image or a phone photo instead of an exported file, that alone does not stop Convert·Into from reading the transaction table off it. Scanned and photographed statements are read with OCR, and then the same extraction and verification rules apply. A blurry image or a slight skew can cause a digit to be misread, but the running-balance check catches the error: every row’s calculated closing figure is compared against the printed one, and any mismatch is flagged for review rather than silently accepted. This means a statement that started as a photograph on a phone still produces a structured, verifiable file. The column mapping and the multi-line grouping work on the OCR output just as they do on a clean digital original, so the export format is consistent regardless of how the statement arrived.