If a transaction description on your Kroo 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 enough to wrap across several lines on the statement, a generic parser often breaks it into separate cells, duplicating the date and amount while scattering the narrative across rows. The layout engine reads the full block as one transaction: it groups every line that belongs to a single entry, so the description arrives whole in its own column and the row count matches the record count printed on the statement.
When your Kroo 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. A scanned or photographed statement adds an extra layer of risk: the engine must read characters from an image, and any misread digit can throw off the running balance. The same balance-verification step that runs on every statement catches that here too: if the printed closing figure does not match the sum of every extracted line, the offending row is flagged, not the whole file. You review the one suspect item, correct it, and the verified file is ready for export to Excel, CSV or QBO.