If a transaction description on your SpareBank 1 Østlandet 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 wraps across several lines on a printed statement, standard copying and pasting often breaks the table: the second line becomes a new row, the amount lands in the wrong column, and the running balance no longer tracks. The engine reads the full transaction entry as a single logical record, even when the description spans two, three, or more lines. It recognises where the description block ends and the next line of numbers begins, so the date, narrative, amount and balance all stay together. A long merchant name, a narrative with an extended reference code, or a multipart transfer detail remains attached to its own figures. You do not need to manually stitch split cells back into place or guess where each value belongs; the extraction holds the original grouping.
However your SpareBank 1 Østlandet statement lays out its columns, that layout is only useful to you once it is mapped correctly into the export. During export, you map each detected column into the position your downstream system expects. The tool presents the fields it has found: transaction date, value date, description, debit, credit, running balance, and any extra reference columns. You drag each one into the order you need for a CSV import, an Excel workbook, or a QBO template. The mapping is saved with your conversion profile, so the same statement layout produces the same output columns on the next run. No fields are hard-coded to a fixed destination; the output matches your own reconciliation process, not a generic default.
Whatever the running balance looks like on your SpareBank 1 Østlandet statement, Convert·Into checks it against the statement's own printed closing figure before you export anything. The conversion verifies the running balance against the statement's own printed closing figure before the file is ready to export. Every row is checked: the engine recalculates what the balance should be after each transaction and compares it to the figure shown on the statement. If a single digit is misread, a row is split incorrectly, or a transaction amount is placed in the wrong direction, the final balance will not match the declared total. The row that fails the check is flagged for review rather than silently accepted. You can inspect and correct that one entry while every other transaction, already verified, remains intact and ready for export.