Once your S-Bank statement is uploaded, what you get back depends on which export format you actually need next. A single export step produces the exact file your ledger, spreadsheet or accounting package expects next. The converted data lands in the output format you pick: Excel (XLSX), CSV or QBO. No intermediate clean-up run, no second pass to re-map columns. The shape of the table in the export matches the shape of the transactions on the statement, and the closing balance block is carried through verbatim so the top-of-file reconciliation figure is right where you need it.
If the S-Bank statement you have is a scanned image or a phone photo instead of an exported file, that alone does not stop Convert·Into from reading the transaction table off it. Scanned paper statements and phone photographs of a printed page are read with OCR before extraction, so a physical piece of paper or a camera snap becomes the same structured transaction table as a born-digital file. The engine's own running-balance check does the heavy lifting to catch any character the scan misread: a 3 mistaken for an 8, a decimal point that bled into a neighbouring digit. When the numbers do not reconcile, the row is flagged for review right where it sits, rather than the whole file being rejected. You correct the one misread digit and move on.
If the running balance on your S-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. Every statement that passes through the engine has its running balance verified line by line against the closing figure printed on the document. The arithmetic is checked independently: each row's balance must equal the prior row's balance plus the row's own transaction amount. If a row does not add up, it is flagged so you can inspect it before the data reaches your ledger. This is not a spot-check or a sample; it runs on every line of every statement, and the only rows you need to look at are the ones that fail.