When an M&T Bank statement you need to convert spans more than one page, Convert·Into merges every page into a single transaction table rather than treating each page as its own file. The extraction works across pages automatically, so there is no practical limit on statement length. A year of transactions across dozens of pages is processed in the same upload as a single-page month. Pagination breaks, repeated headers, and page footers are identified and stripped before the table is assembled, which keeps stray boilerplate text out of the transaction rows. The assembled dataset preserves the original sort order and column structure, and every running-balance figure is checked against the values that precede and follow it, including across page boundaries. If a carry-forward total on page three fails to match the opening balance on page four, that mismatch is flagged at the specific row, not buried in a bulk error log.
When your M&T Bank statement arrives as a scan or a photo of the page rather than a clean export, the numbers on it are just pixels until they are extracted. Scanned and photographed statements are read with OCR, and the same running-balance verification applies to the output. A smudged digit, a skewed camera angle, or a folded corner can cause a misread, and a single misread character is enough to break the running balance. The engine reports the row where the arithmetic no longer adds up rather than rejecting the whole file, so you can review and correct one value instead of rekeying an entire month. The transaction table is reconstructed with the same column mapping that a clean electronic statement receives.
Whatever the running balance looks like on your M&T Bank statement, Convert·Into checks it against the statement's own printed closing figure before you export anything. The closing balance printed on the statement is treated as the authoritative figure, and every line in the extracted transaction table must reconcile to it. The engine computes a running balance from the opening figure and the transaction amounts, then compares that computed total to the printed closing balance. If they do not match, the point of divergence is flagged at the specific row rather than silently accepting a misread statement. This check catches OCR errors, layout misinterpretations, and any row-level data gap introduced during extraction, so the exported file always reflects a verified ledger.