When a Nedbank 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 are handled without extra input: the engine reads the entire document as one continuous record, stitching pages together in the background so every transaction arrives in a single table.
Should a description on your Nedbank 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 keeps the whole text together in the cell where it belongs. Split rows and orphaned detail lines are detected and re-joined during extraction, so a single payment is always one row regardless of how many lines its description occupies on the page.
Whichever order your Nedbank statement prints its columns in, each one still has to land in the right place once it reaches a spreadsheet. Mapping each column into the right place in the export is the last step before download, and it gives you full control. The engine separates a statement’s columns automatically, date from description from debit from credit from balance. You then review the fields it found and choose which ones to include in Excel, CSV or QBO, and in what order. This step is where you align the output with your own chart of accounts, renaming or excluding fields so the exported file matches the import spec of your ledger or accounting system. Column mapping is also where you catch any structural oddities in the layout: if a column has been split or merged during extraction, you can correct it here rather than later in the spreadsheet. The export itself writes clean, transaction-level rows, with one row per payment or deposit and no summary rows, no embedded headers, and no hidden characters that would break a CSV import or QBO upload.