If a transaction description on your KredoBank 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 onto the next line, the converter reads the whole block as one entry, so a split line does not become a ghost row or a duplicate.
However your KredoBank statement lays out its columns, that layout is only useful to you once it is mapped correctly into the export. Mapping each column into the right place in the export is the second half of a reliable conversion. After the table is extracted and the running balance is verified line by line, the engine identifies the standard fields: a date column, a description column, a debit or credit amount, and the running balance itself. You review this mapping on screen before you export. If the statement's layout groups debits and credits into a single amount column with a sign, the converter preserves that sign. If it splits them into separate credit and debit columns, those are kept as two columns in the output. You can accept the engine's mapping as-is, or you can reassign a column manually: drag the transaction description to its own field, for instance, or confirm that the closing balance row is excluded from the transaction table. The export then produces exactly the columns you reviewed, in the order you reviewed them, with no extra fields inserted and no data shifted out of place. The result is a clean file, ready to import into your ledger or accounting system without post-export cleanup.
If the KredoBank statement you have is a scanned image or a phone photo instead of an exported file, that alone does not stop Convert·Into from reading the transaction table off it. A scanned or photographed statement is read with optical character recognition, and the same running-balance check applies as with a clean digital file. If the scan is faded or the photograph is taken at an angle, a digit may misread: a 3 becomes an 8, or a decimal point disappears. The converter flags any row where the balance does not add up, so you can correct the OCR read rather than discover the error during reconciliation.