If a transaction description on your Barclays statement is long enough to wrap across two or three lines, it still needs to land in a single row once converted. Transaction descriptions can wrap across several lines. The engine reads the full block of text that belongs to a single entry, so nothing is truncated or split into a phantom second row. Even when the narrative part of a transaction is taller than the data cells around it, the engine keeps the date, amount and balance on the same line in the output.
If the running balance on your Barclays statement does not add up row by row, that is exactly the kind of mismatch Convert·Into is built to catch rather than pass through silently. The running balance is verified against the statement's own printed closing figure, line by line. Any discrepancy, a 3 misread as an 8 or a row that does not add up, is flagged for review rather than silently accepted. The whole file is never rejected because of one suspect figure; you get a clean alert on the specific row so you can correct it and move on.
If the Barclays 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. Scanned and photographed statements are read with OCR, and the same running-balance check applies: anything the scan misread is caught against the arithmetic. Once the extraction passes verification, the columns are mapped into the export layout you choose. Every transaction keeps its original date, description, debit, credit and balance fields, ready to save as Excel, CSV or QBO with no rekeying.