If a transaction description on your Equitable Bank statement is long enough to wrap across two or three lines, it still needs to land in a single row once converted. When a statement document wraps long transaction descriptions across multiple lines inside the same row, the engine recognises the continuation and keeps the detail in the same record instead of splitting it into separate phantom rows. It reads the full text block, identifies where the narrative ends and the next transaction begins, and preserves the relationship. A bookkeeper reviewing the extracted table sees one coherent memo per transaction, not fragments scattered across rows that must be reassembled by hand. The process handles descriptions that span two lines, three lines, or more, so long as the statement itself prints them together. Structured fields such as dates, cheque numbers and amounts anchor the row boundaries; the engine uses those anchors to decide what belongs to the current entry and what starts the next one.
If the running balance on your Equitable Bank 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 column against the statement’s own printed closing figure, line by line, for every page it processes. It reads the closing value from the final record on the statement and compares it to the cumulative sum of the transactions extracted from that same file. If a single digit was misread, a sign reversed, or a row skipped, the arithmetic no longer ties, and the row that breaks the balance is flagged. You see exactly where the mismatch occurred, not a blanket rejection that forces you to recheck the whole file. This running-balance check catches both optical misreads on scanned pages and structural errors in text-based documents, so the export is built from a verified set of figures and not from the output of an unchecked extraction.
Whichever order your Equitable Bank statement prints its columns in, each one still has to land in the right place once it reaches a spreadsheet. Column mapping fits the export to your workflow. The engine presents the fields it found: date, description, debit, credit, balance, possibly a cheque number or a reference code. You review the column headers and decide which ones go where in the output. A credit column in the source can land in the credit field of the export template; a memo that the statement labelled “particulars” can become the description column in your CSV or QBO file. The mapping step runs once per statement layout, and the engine remembers your choices for the next upload. After mapping is confirmed, the data goes out to Excel, CSV or QBO with the columns in the order your process expects.