Whichever order your Jyske Bank statement prints its columns in, each one still has to land in the right place once it reaches a spreadsheet. When the table is extracted, each column in the statement is mapped into the correct field in your export. The engine assigns transaction dates to the date column, descriptions to the memo field, debits and credits into separate amount columns, and any running balance into its own column. If the statement labels its columns in a local language the engine recognises, those headers are resolved automatically, so there is no manual drag-and-drop to reorder fields. You can review the mapping before export; anything that landed in the wrong slot can be corrected with a single click, and the correction sticks for every row in the file.
If your Jyske 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 document that runs several pages long is handled as one continuous extract, not as a stack of separate tables. The engine stitches tables across page breaks, dropping repeated header rows and joining split rows so that a transaction that begins at the foot of one page and continues onto the next is reassembled into a single row. Closing balances are taken only from the final page, and the running-balance verification checks every line against that figure, regardless of how many pages the statement spans.
If a transaction description on your Jyske Bank statement is long enough to wrap across two or three lines, it still needs to land in a single row once converted. Transaction descriptions that wrap across two or three lines inside the statement are collapsed into a single cell in the output. The engine detects when a description line is not a new row but a continuation of the row above, using spacing, alignment and text position to make the call. This keeps the row count in your export aligned with the actual number of transactions, so you are not left merging fragments later.