When your Handelsbanken 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 so a paper printout or a phone photo works the same as a native file. The engine processes the pixels and reconstructs the transaction table, and the running-balance check catches any misread digit before the data leaves the page.
Whether you need your Handelsbanken statement in Excel, CSV or QBO, the underlying extracted table stays the same; only the export step differs. The export step maps every extracted column into the format your next tool expects: Excel, CSV, or QBO. You control which columns land where and in what order. Date formats, decimal separators, and header labels are all remapped during the mapping pass so the output file slots straight into your ledger, reconciliation software, or tax-prep workflow without a separate cleanup step. CSV exports use a consistent delimiter and encoding; QBO exports align to the QuickBooks transaction schema so the import rejects nothing on structure.
If your Handelsbanken statement runs to several pages, uploading it starts the same layout detection Convert·Into applies to any statement document, page by page. A statement that runs several pages long is treated as one continuous ledger. The engine stitches the pages end to end, picks up the carried-forward balance from the last row of each page, and verifies it against the opening line of the next. If a page break splits a transaction across two pages, that row is joined back together before the running-balance check runs. The verification works line by line across the full document: a row that does not add up is flagged individually, not as a wholesale rejection, so a single anomaly on page four does not block export of the rest of the file.