Whichever order your BBVA Mexico statement prints its columns in, each one still has to land in the right place once it reaches a spreadsheet. When you map columns for export, the engine presents the extracted transaction table with each column labelled according to its role: date, description, debit, credit, balance. You can review those assignments and move a column to a different field if the statement used an unusual heading. The export writes every row into the columns you chose, so your ledger software or spreadsheet receives the data in the structure it expects. No column is dropped unless you explicitly exclude it, and the mapping you create for one statement is remembered for the next one from the same layout family.
If the running balance on your BBVA Mexico statement does not add up row by row, that is exactly the kind of mismatch Convert·Into is built to catch rather than pass through silently. The engine verifies the running balance line by line against the printed closing figure on the statement document. If a debit reads as an 8 instead of a 3, the arithmetic breaks at that row and the discrepancy is flagged for review. That verification happens on every statement, regardless of layout, so a balance that does not add up is caught before it reaches your accounts. The file is not rejected whole; only the row that fails the check is highlighted, and all other transactions remain intact.