When your Akbank 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 that arrives as a photograph or a scan presents extra hurdles: the numbers must be read from the pixels of an image rather than parsed from a file’s internal table. The engine applies OCR to locate the transaction table and pull every row into structured fields. Because the scan is never perfect, a 3 may register as an 8 or a column delimiter may shift, so the extracted data is cross-checked against the statement’s own closing figures before any export leaves your hands.
Whether you need your Akbank statement in Excel, CSV or QBO, the underlying extracted table stays the same; only the export step differs. Once the file is inside Convert·Into, the columns detected in the statement are mapped to a clean export schema automatically: date, description, money out, money in, and balance. You can export the result directly to Excel (XLSX), CSV, or QBO. No manual column reordering or format finessing is needed; the same mapping logic that recognised the layout in the upload stage organises the output fields so the file slots into whatever system you keep next.
If the running balance on your Akbank 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. Every statement passes through a running-balance verification step. The engine recalculates the balance column line by line, comparing its own arithmetic against the printed closing figure on the document. A single row that would push the tally out of alignment is flagged for review instead of letting the whole file proceed with hidden drift. When the recalculated total matches the statement’s stated final balance, the exported rows are ready for reconciliation.