If a transaction description on your UniCredit statement is long enough to wrap across two or three lines, it still needs to land in a single row once converted. When a transaction description runs long and wraps across multiple lines inside the statement table, a simple text scrape cuts the row in half: half the description lands in one row, and the rest drifts into the next, dragging the amount or running balance out of alignment. The engine reads the table structure, not the text flow. It recognises that a wrapped line still belongs to its parent row and stitches the description back together before the row is finalised, so the amount column and the running balance stay in place.
When your UniCredit 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 statement documents introduce a different failure mode: a 3 misread as an 8, a decimal point lost in shadow, a crease that splits a digit. The engine applies OCR to the image and then runs the same running-balance check it uses on every statement: the printed closing figure on the document is the arbiter. If a line’s numbers do not add up against that known total, the row is flagged for review rather than passed through silently, so a single misread digit does not force you to hunt through every transaction by hand.
Whichever order your UniCredit statement prints its columns in, each one still has to land in the right place once it reaches a spreadsheet. Each statement layout maps its columns differently: the date in one position, the description in another, the debit and credit amounts split across two columns or folded into a single signed column. The engine identifies those column roles automatically during extraction and maps them into the export’s expected fields. Before you download, you can review the column mapping and adjust any assignment: drag the description into the right slot, confirm that debits and credits have not swapped, and verify that the closing balance column is pointed at the correct field. The export then writes every row in the same consistent order, ready for Excel, CSV or QBO.