When your Absa 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. A statement document captured with a phone camera or desktop scanner starts as a photograph of a page, not as a structured data table. The engine reads the image with OCR, locates the transaction grid by its visual layout, and isolates the columns that hold dates, descriptions, amounts and the running balance. Because every row is read optically, small misreads are possible, and a 3 can look like an 8 on a creased or shadowed page. When that happens, the arithmetic of the running balance catches it immediately, so the discrepancy appears as a flagged row rather than a hidden error that propagates into the final export.
Whatever the running balance looks like on your Absa Bank statement, Convert·Into checks it against the statement's own printed closing figure before you export anything. The printed closing figure on the statement is the authoritative yardstick. Convert·Into sums every transaction against every opening balance and checks that the running total arrives at exactly the figure printed at the bottom of the document. If the two disagree, the affected row is flagged and the file is held for review, so the export never contains a balance that fails to match the source document.
If your Absa Bank statement runs to several pages, uploading it starts the same layout detection Convert·Into applies to any statement document, page by page. When a statement runs across several pages, the engine stitches them into a single continuous ledger. Carry-forward balances at page breaks are matched to the opening of the next page, and the running balance is checked from the first row through to the last, so a multi-page document is treated as one consistent record rather than as separate fragments.