Whichever order your Development Bank of Saxony statement prints its columns in, each one still has to land in the right place once it reaches a spreadsheet. Column mapping works one way: the engine identifies the transaction table, reads every heading, and places each field into a standard column in the working grid. Date lands in the date column; description lands in the description column; debit, credit and balance each land in their own. You do not drag columns around or tell the system which is which. If a column is present on the statement but not needed downstream, leave it unmapped. It stays out of the export without disrupting anything else. If a column heading appears in an unexpected place because of the document’s layout, the engine still finds it by its content rather than its position on the page.
Once your Development Bank of Saxony statement is uploaded, what you get back depends on which export format you actually need next. Export is the moment the converted file leaves the tool and enters your workflow. Choose Excel for pivot-table analysis or for handing off to a colleague who works in spreadsheets. Choose CSV for a system that expects a flat, delimiter-separated feed with no formatting. Choose QBO when the destination is QuickBooks Online and you want the mapped columns to flow straight into the ledger. The exported file always carries a closing-balance figure that was verified against the statement’s own printed number, so there is no need to check the maths again after conversion.
If the Development Bank of Saxony 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. A photographed or office-scanned statement is still a statement. The engine reads it with OCR, pulls the transaction table from the image, and then applies the same running-balance check that it applies to a born-digital file. That check is the safety rail: any row where the figures do not add up is flagged, rather than silently accepted, so a smudged 8 that scanned as a 3 does not propagate into the export. You review the flagged row, correct the digit, and carry on.