If the running balance on your FMO 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 reads the printed closing balance on the statement and checks it against every row that came before. It recalculates the running total line by line: opening balance plus each credit, minus each debit. If the figures do not add up, the affected row is flagged for review rather than the whole file being rejected. That means a single misread number never forces you to restart the conversion from scratch.
Whichever order your FMO statement prints its columns in, each one still has to land in the right place once it reaches a spreadsheet. Column mapping is handled automatically. The engine identifies which column holds the date, which holds the description, and which holds the amount, then places each field into the matching export slot. You can review the layout before you export. If a transaction narrative has been split across two fields, you can merge them, and if a supplementary reference column was captured, you decide whether to include it or drop it before the file is written.
If your FMO statement runs to several pages, uploading it starts the same layout detection Convert·Into applies to any statement document, page by page. Multi-page statements are handled as one continuous ledger. When the engine encounters a page break it resumes extraction on the next page and stitches the transaction table together without duplicating the header row or dropping the carry-forward balance. The running-balance verification is performed across the full, joined record, so a mismatch that first appears on page three is caught and traced back to its source row the same way it would be in a single-page document.