Whichever order your TD Bank statement prints its columns in, each one still has to land in the right place once it reaches a spreadsheet. Columns are mapped into the export so that every field lands in the proper place. The engine identifies the transaction table and assigns amounts, dates, payees and references to the correct columns. The result matches a structured ledger, with no transposed fields or merged cells. Before you export, you can review the column assignments and adjust them if the statement uses a layout you prefer to remap.
Should a description on your TD Bank statement break across multiple lines of the printed page, that line break is not the same thing as a new transaction. When transaction descriptions run long and wrap across multiple lines, the engine keeps each entry whole. It reads multi-line narratives as a single transaction row instead of splitting them into phantom entries. The wrapping is recognised by the relationship between the description cell and the adjacent fields, so a four-line description stays tied to its date, amount and balance. This preserves the transaction count and prevents misaligned rows in the final export.
Whatever the running balance looks like on your TD Bank statement, Convert·Into checks it against the statement's own printed closing figure before you export anything. The running balance is verified against the statement's own printed closing figure. Every row's arithmetic is checked line by line; a mismatch is flagged for review without rejecting the file. This means a single misread digit or a stray character that throws the balance off is isolated to that row, and the rest of the conversion proceeds intact. When the closing balance in the export matches the one printed at the foot of the statement, you have confirmation that the ledger is complete.