Whichever order your One Swiss Bank statement prints its columns in, each one still has to land in the right place once it reaches a spreadsheet. When you export, you control where every column lands. The engine maps the extracted transaction table into a clean grid: date, description, debit, credit, and running balance each sit in their own column. You can reorder the columns before exporting, and you can choose to drop any column you do not need, such as a balance column when the destination ledger tracks its own. The mapping is stored with the export, so the same shape repeats for the next statement you convert.
If your One Swiss Bank statement runs to several pages, uploading it starts the same layout detection Convert·Into applies to any statement document, page by page. A statement that runs several pages is treated as a single logical table. The engine reads across page breaks and continues the transaction list without inserting blank rows or restarting the column headers. Duplicate header rows printed at the top of each page are recognised and suppressed, so the exported file contains one continuous set of transactions from the first row to the last. The closing balance from the final page is the figure verified against the running total.
If a transaction description on your One Swiss Bank statement is long enough to wrap across two or three lines, it still needs to land in a single row once converted. Long transaction descriptions that wrap across multiple lines are reassembled into a single cell during extraction. The engine distinguishes a wrapped line from a new transaction row by reading the date column: a new row always begins with a date, and any text beneath it without a date belongs to the description above. The result is one row per transaction, with the full narrative preserved in the description field, ready for categorisation or narrative search inside your ledger.