If a transaction description on your Hamburger Sparkasse 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 runs long, the text wraps into several lines inside the cell. The engine reads the description across all of its wrapped lines, preserving the complete memo, then aligns the figures and dates in their own columns. Nothing is cut off, and a split description does not push the next row's data out of place.
If your Hamburger Sparkasse 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 long is treated as one continuous table. The engine stitches the pages together automatically, repeating the running-balance check from the final line of one page to the first line of the next. The closing balance on the last page is the sole figure that must match the statement's own printed total.
Whichever order your Hamburger Sparkasse statement prints its columns in, each one still has to land in the right place once it reaches a spreadsheet. During export, you map each column to the field layout your workflow expects. Date, amount, payee, reference and memo can each be placed in the exact order and header format required, whether the destination is an Excel template, a CSV import for another system, or a QBO file. The mapping is set once and applied to every statement you convert afterwards, so the same column structure arrives in your ledger with no manual reshuffling. If a column contains extra detail the statement prints but your downstream system ignores, you can leave it unmapped and it is simply omitted from the export.