If a transaction description on your MeDirect statement is long enough to wrap across two or three lines, it still needs to land in a single row once converted. When the transaction descriptions run long and wrap across multiple lines, each continuation can look like a new row to a naive extraction. The engine groups those continuation lines back into their parent transaction before parsing, so the amount, date and payee all stay in their proper columns. The row count then matches the statement's own line count, which means the running-balance check has the correct number of items to verify against the printed closing figure.
When your MeDirect 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 add a layer of risk that clean source files never carry: pixel noise, skew, a 3 misread as an 8. The engine applies OCR to raster images, then runs the same row-by-row balance verification it uses for every other document. If a misread digit breaks the running-balance check, that specific row is flagged for review; you correct the one value, not the whole export.