Whichever order your EBank statement prints its columns in, each one still has to land in the right place once it reaches a spreadsheet. Each column in the export pane is mapped to the correct data type automatically: dates stay as dates, amounts are recognised as numbers with the right sign for debits and credits, and descriptive fields remain plain text. If your accounting software expects a particular column order or header name, you can drag columns to match that layout before you download the file. The mapping logic handles the most common transaction-table structures without any template to configure, so the export lands in your working format already aligned with the categories you need.
Should a description on your EBank statement break across multiple lines of the printed page, that line break is not the same thing as a new transaction. When transaction descriptions wrap across two or more lines inside a statement document, the engine groups those lines back into a single record rather than treating each line break as a new row. It uses cues from the table structure such as a blank first column or a missing amount field to recognise continuation lines and stitch the full description together. A single invoice reference or narrative that spans several printed lines stays whole in the exported row, ready for your categorisation workflow.
When an EBank 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 three pages, thirty pages, or more are handled as one continuous file. The engine starts reading from the first page and works through to the final page, so a single upload produces one consolidated output with all transactions in sequence. If a page break falls in the middle of a transaction row, the reader picks up the remainder on the next sheet automatically, and the running-balance check continues across every page boundary without interruption.