Whichever order your Lombard Odier & Cie statement prints its columns in, each one still has to land in the right place once it reaches a spreadsheet. The statement is read and each column in the transaction table is categorised by its content: dates, descriptions, amounts, and balances are identified by their data type and position, not by fixed templates. You can then review the mapping in a preview pane, drag or reassign any column that needs a different home in your export, and rename headers so your accounting package or spreadsheet model receives exactly the fields it expects. Once the layout is set, the same mapping is reapplied automatically to future statements from the same layout, which keeps the export consistent across months without rework.
When your Lombard Odier & Cie 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. When a statement document arrives as a scan or a photograph rather than as a digitally generated file, the engine uses optical character recognition to lift the transaction table off the page. Every line runs through the same running-balance verification that applies to all converted statements; a misread digit that breaks the running total is flagged at the row level so you can correct a single value instead of rechecking the whole document.
Whatever the running balance looks like on your Lombard Odier & Cie statement, Convert·Into checks it against the statement's own printed closing figure before you export anything. Every row of the extracted transaction table is checked against the statement’s own printed closing balance. The running balance is calculated from the opening figure and each subsequent transaction, and any row where the calculation does not match the printed balance is flagged for review. You see the discrepancy while the rest of the file remains intact, so you can resolve a single mismatch and proceed to export a reconciled Excel, CSV, or QBO file.