Whichever order your Kutxabank statement prints its columns in, each one still has to land in the right place once it reaches a spreadsheet. Mapping each column into the right place in the export works because the engine structures the data the same way every time, regardless of how it was originally laid out on the page. Once the transaction table has been extracted and the running balance verified line by line, every field is available as a clean, typed column: date, description, debit, credit, balance. You assign each source column to the corresponding field in your target template, and that mapping is remembered for the next statement you upload from the same layout. If a statement includes extra columns you do not need, you can leave them unmapped; nothing extraneous lands in the export.
Once your Kutxabank statement is uploaded, what you get back depends on which export format you actually need next. Getting the file into the exact export format needed next is a single step. When the mapping is confirmed, you choose Excel, CSV, or QBO. The exporter writes clean, machine-readable rows: no merged cells, no hidden characters left behind by a PDF renderer, no spaces that break a VLOOKUP. The output is ready to import into your accounting package or spreadsheet without further cleanup.
If a transaction description on your Kutxabank statement is long enough to wrap across two or three lines, it still needs to land in a single row once converted. Statements whose transaction descriptions run long and wrap across multiple lines are a common source of broken rows in a manual copy-paste. The engine reads wrapped text as a single cell: it follows the line breaks back to the correct transaction row instead of treating each wrapped line as a new record. The description lands intact in one field, and the balance check confirms that nothing was split or lost in the process.