Whichever order your Bank of America statement prints its columns in, each one still has to land in the right place once it reaches a spreadsheet. When the transaction table has been extracted, its columns are mapped into a standard structure so the data lands exactly where you need it. The system identifies the date, description, debit amount, credit amount and running balance columns by their headings and content patterns, not by a fixed template. You can review the suggested mapping and adjust any column assignment before export. The export always includes every transaction the statement lists, with no rows silently dropped. The date format and number separators are normalised during mapping so the exported file is ready for import without further cleanup.
If your Bank of America statement runs to several pages, uploading it starts the same layout detection Convert·Into applies to any statement document, page by page. For statements that run several pages long, the engine reads across the page breaks and stitches the table back into a single continuous ledger. It does not treat every page as a separate extraction or require you to specify where the break falls. The column layout must stay consistent across pages; if a footer, a subtotal line or a carried-forward annotation interrupts the table, the engine skips it and resumes reading the transaction rows that follow. The result is one table per statement, with a single running balance that is verified end to end right through the closing figure printed on the last page.
If a transaction description on your Bank of America statement is long enough to wrap across two or three lines, it still needs to land in a single row once converted. When a transaction description is long enough to wrap across multiple lines inside the statement, the engine holds the row open and reads the wrapped lines as a single description cell. It does not split the wrapped text into ghost rows or merge the spill onto the next transaction. This matters when descriptions contain invoice numbers, counterparty details or payment references that must stay intact for categorisation and audit. The running balance check acts as a guard here: if a wrapped line were ever misinterpreted as a new transaction, the balance would break, and the row is flagged for your review rather than let a miscount pass through.