Whichever order your OTP Bank statement prints its columns in, each one still has to land in the right place once it reaches a spreadsheet. During export, you assign source columns to the target fields your system expects. The mapping interface lists the fields the engine found: date, description, debit, credit and balance, along with any optional columns present in the statement. You drag each one to its counterpart in the export template or let the automatic suggestion handle the common placements, so dates land in the date column, debits in the debit column and so on. Every mapping is visible before you confirm, and you can override any assignment if the output layout calls for a different column order.
Should a description on your OTP Bank statement break across multiple lines of the printed page, that line break is not the same thing as a new transaction. When a transaction description wraps across several lines, a generic parser often treats each line as its own row, splitting one payment into two or three phantom entries that break the running total. The engine reconstructs the row by reading the statement as a table, not as a flat stream, anchoring each line to its parent amount and date row. If the reconstruction is in doubt because a wrapped line also looks like a valid new transaction, the row is held for review rather than silently merged or split, so your export stays clean without losing the full description text.