If a transaction description on your NIBC 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 spans several lines, the risk is that the text wraps into what looks like a new row, splitting one entry into two or more fragments in the export. The engine reads the table structure rather than the line breaks. It recognises that a description line without a date or amount belongs to the entry above it, and it stitches those lines back into a single row before writing the output. You see one transaction per row, with the full narrative kept together.
If the running balance on your NIBC Bank statement does not add up row by row, that is exactly the kind of mismatch Convert·Into is built to catch rather than pass through silently. Every statement is verified against its own printed closing figure. The software reads the ending balance exactly as it appears on the page, then walks down the transaction list line by line, adding deposits and subtracting withdrawals to recalculate the running total. If any row would push the calculated balance out of agreement with the printed one, that row is flagged for review. The rest of the statement continues to export cleanly, so a single misread does not block the whole file.
When an NIBC 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. Statements that run several pages long bring their own challenge: page headers and footers, repeated column labels and continuation marks that a naive parser treats as fresh data. The engine identifies these repeating elements and suppresses them, joining the transaction tables across page breaks into a single continuous list. The result is a clean ledger where the rows flow in order, regardless of how many pages the original statement spanned.