If a transaction description on your 365.bank statement is long enough to wrap across two or three lines, it still needs to land in a single row once converted. When a transaction description is too long to fit on one printed line, the text wraps and the statement document will show a blank amount and date column on the overflow line. The engine reads the full block of text, recognises the continuation by the empty fields, and reassembles the description back into a single row. The extracted record carries the complete text that appeared across the wrapped lines, so no fragment is left behind or treated as a separate transaction. The running-balance check runs on every row as usual: a split description that was misread as an extra debit would break the balance immediately, and the row would be flagged.
However your 365.bank statement lays out its columns, that layout is only useful to you once it is mapped correctly into the export. Every column the engine finds in the statement is mapped into a matching field in the export layout: date, description, debit amount, credit amount, and the running balance that was printed on the original document. You are not locked into a fixed template. Before the export is written, you can review the mapping and drag any column to a different position, rename the header, or exclude it from the output entirely. The engine preserves the pairing it detected, so a column that held debits in the statement does not drift into the credit slot in the exported file unless you deliberately reassign it. The mapped layout is what you get in the Excel workbook, the CSV file, or the QBO-ready data, with every transaction sitting in the column you chose for it.
When a 365.bank statement you need to convert spans more than one page, Convert·Into merges every page into a single transaction table rather than treating each page as its own file. A statement that spans several pages is handled as one continuous document, not as a series of unrelated images. The engine reads the transaction table across all the pages, carries the column headers forward wherever the layout repeats them, and picks up the running balance from the closing figure printed on the final page. That final balance figure is the anchor: every intermediate row's running balance is verified against it, line by line, from the first transaction through to the end. If a row's printed balance does not add up given the prior balance and the transaction amount, the discrepancy is flagged for review. The full reconciled list stays intact; nothing is discarded just because one line needs attention.