When your Bankmed 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. A statement that has been scanned or photographed starts as an image, not as a data table. The engine applies OCR to the document and identifies the transaction columns by their position on the page, the same way it reads a born-digital statement. Once the rows are extracted, the running-balance check catches any digit the scan misread: if a 3 became an 8 and the numbers no longer add up, that row is flagged for review. The rest of the file stays intact, so correcting a single OCR slip does not stall the whole conversion.
If a transaction description on your Bankmed statement is long enough to wrap across two or three lines, it still needs to land in a single row once converted. Long transaction descriptions that wrap across two or three lines in the original document can split a single row into fragments in a naive export. The engine reads the statement layout holistically, recognising that a wrapped line belongs to the transaction above it rather than starting a new row. The result is a single, complete record per transaction, with the full description kept in one cell. No stray line fragments appear as separate, empty rows in the final file.
Once your Bankmed statement is uploaded, what you get back depends on which export format you actually need next. Once the statement is extracted and verified, you choose the export format and the column order that fits your workflow. Map the date, description, debit, credit and balance columns into the arrangement your ledger or software expects, then export to Excel, CSV or QBO. A reconciliation readout shows the verified closing balance alongside any flagged line, so you know exactly what passed the running-balance check before the file goes anywhere else. The verified balance travels with the export, giving you a clean starting point for the next step in your process.