When your Attijariwafa 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 or photographed statements are read with OCR. The engine identifies each digit and character in the transaction table, then rebuilds the ledger columns from the image. A misread digit can throw off the whole reconciliation, so every row is checked against the statement’s own running balance. When a figure does not add up, that row is flagged for review without discarding the rest of the file.
If a transaction description on your Attijariwafa 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 transaction description wraps across several lines in the original statement, the extractor groups those lines back into a single record. It recognises where one transaction ends and the next begins by tracking the printed running balance and the date column, so a large block of wrapped text does not get split into multiple phantom entries in your export.
If the running balance on your Attijariwafa 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 running balance on the statement acts as the ground truth. The engine checks every extracted row’s balance against what the statement itself prints, line by line. If the closing balance on the converted file matches the printed closing figure exactly, the extraction is verified. If any row fails that check, it is flagged for correction before you export, so a single misread never cascades into an undetected error in your ledger.