Whichever order your La Banque Postale statement prints its columns in, each one still has to land in the right place once it reaches a spreadsheet. Start by mapping the columns into the export. When a statement arrives, the engine identifies every column header it finds: date, description, money out, money in, and the running balance. Every column is presented to you so you can confirm which field goes where before the export is built. You can reorder columns, rename a header for your ledger’s naming convention, or exclude a column that is not needed. If the statement splits a single transaction across two rows, merges cells, or repeats the description only on the first line of a multi-line entry, the engine reassembles the fragment into one row. The column mapping step lets you check that reassembly, correct any misfire, and produce a file where every transaction lands in the right column every time.
When your La Banque Postale 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 and photographed statements are read with OCR. The text layer the OCR produces is run through the same extraction pipeline as a native digital file: the engine finds the transaction table, pulls the columns, and reconstructs the running balance. If the scan introduced a stray mark that turned a 7 into a 1, the running-balance check flags the row where the numbers stop adding up, so you are not left chasing a mismatch later. You review the flagged row, correct the one misread digit, and the rest of the file exports cleanly. A low-contrast photocopy or a creased receipt snap will still produce usable output, and the verification step catches what the scan could not read perfectly before the numbers ever reach your ledger.