UK
The most common extraction errors across banks aren't random — they track the layout each bank uses. Merged debit/credit columns, descriptions that wrap onto a second line, dates printed only on the first transaction of the day, and a running-balance column that confuses the parser are the four that account for most broken exports we see. The error you hit depends far less on the converter and far more on whose statement you fed it. A running-balance reconciliation check is what catches all four, because a dropped or misread line breaks the maths even when the spreadsheet looks fine.
This is a field report, not a tidy theory piece. The patterns below come from converting and reconciling statements from UK, Australian, Irish, US and Indian banks, then checking every extracted line against the closing balance to see what slipped through.
How we looked at this
We grouped failures by the statement feature that caused them, not by bank brand, because the same quirk turns up everywhere. A two-column debit/credit layout from Barclays breaks the same way a two-column layout from NAB does. So the useful unit here is the format pattern, not the logo at the top of the page.
For each pattern we note: what the PDF looks like, how the parser gets it wrong, which banks tend to use it, and what the reconciliation check reports when it happens. Every claim here is about the conversion-then-import path — you convert the PDF to a clean CSV and import that file into Xero, QuickBooks or Zoho Books. None of this involves a live bank-feed API.
The errors, by format pattern
Most extraction problems fall into one of these buckets. Read them as a checklist against your own bank.
Merged debit and credit columns
Some statements print money in and money out in two separate columns; others put everything in one "amount" column and rely on a sign or a label. When a converter expects one shape and gets the other, it either drops the sign or files a credit as a debit. The total still looks plausible, which is the dangerous part.
- What breaks: a /$ figure lands in the wrong direction, so the balance moves the wrong way.
- Seen on: HSBC and Lloyds two-column layouts in the UK; Commonwealth Bank single-amount layouts in Australia; most Indian PSU bank statements (SBI, PNB) which use separate Withdrawal/Deposit columns.
- Reconciliation flag: the running balance diverges at the first misread row and never recovers — easy to spot, because the gap is exactly twice the transaction value.
Multi-line descriptions that wrap
A long payee or reference often wraps onto a second or third line in the PDF. A naive parser reads each visual line as a new row, so one transaction becomes two — the second a phantom with a description but no amount.
- What breaks: row count inflates; you get blank-amount rows, or the wrapped text gets attached to the *next* transaction.
- Seen on: business statements with long SWIFT/reference fields, Revolut and Wise exports with rich merchant strings, and Irish AIB/Bank of Ireland statements with multi-line counterparty details.
- Reconciliation flag: transaction count won't match, and a phantom zero-amount row leaves the balance technically intact but the line items wrong — which is why a count check sits alongside the balance check.
Dates shown only once per day
Plenty of banks print the date on the first transaction of a day and leave it blank for the rest. Extract that literally and every transaction after the first inherits a blank date, or worse, the wrong one.
- What breaks: transactions land on the wrong day; date-range filters and period totals go off.
- Seen on: Barclays and NatWest UK layouts, ANZ and Westpac statements in Australia and New Zealand, and many Indian bank PDFs that group by value date.
- Reconciliation flag: the balance can still reconcile while the dates are wrong, so this is one a balance check alone won't catch — date carry-forward has to be handled at extraction, and the extraction accuracy benchmark measures exactly this kind of silent error.
Running-balance column mistaken for an amount
Statements that show a running balance after every line give the parser two numbers per row. Pick the wrong one and you import the balance instead of the transaction value. Every figure is then enormous and nothing adds up.
- What breaks: the "amount" column is actually the balance; totals are wildly off.
- Seen on: statements that show a Balance column on every row — common across UK current accounts and Indian bank statements.
- Reconciliation flag: the very first reconciliation step fails loudly, because opening balance plus your extracted "transactions" lands nowhere near closing.
Multi-currency and thousands separators
Statements with foreign-currency lines, or numbers formatted as 1.234,56 versus 1,234.56, trip locale assumptions. A European-formatted figure read with US rules turns 1.234,56 into 1.234 or 1234.56.
- What breaks: decimal and grouping confusion scales an amount by 100 or 1,000, or merges a currency code into the number.
- Seen on: Irish and continental statements, Indian statements using the lakh grouping (1,00,000), and any account holding more than one currency.
- Reconciliation flag: a single mis-scaled figure throws the balance off by an obvious order of magnitude.
Scanned and photographed slips (OCR)
When there's no text layer — a scan, a phone photo, a faxed copy — the converter has to read pixels. OCR misreads similar glyphs (8/B, 1/7, 0/O), loses faint print, and struggles with skew or shadow.
- What breaks: a transposed or misread digit in an amount, a date, or a reference.
- Seen on: any statement supplied as an image rather than a born-digital PDF — common for older statements and for branch printouts in India.
- Reconciliation flag: a single transposed digit (say 81.00 read as 31.00) shifts the running balance by the difference, and the check pins the exact row.
A quick reference table
Format pattern | Typical symptom | Where it shows up | Caught by balance check alone? |
|---|---|---|---|
Merged debit/credit columns | Credit filed as debit | HSBC, CBA, SBI | Yes |
Wrapped multi-line descriptions | Phantom blank-amount rows | Revolut, Wise, AIB | Needs a row-count check too |
Date shown once per day | Wrong transaction dates | Barclays, ANZ, Westpac | No — needs date handling |
Running balance read as amount | Huge wrong totals | UK current accounts, Indian banks | Yes, immediately |
Locale/multi-currency formatting | Amount scaled ×100 or ×1000 | Irish, continental, lakh grouping | Yes |
OCR misreads on scans | Transposed digit | Any image-only statement | Yes, to the row |
The pattern worth noticing: a plain balance check catches the big, loud failures but misses two quiet ones — wrapped rows and carried-forward dates. That's why the check that actually protects you pairs the running balance with a transaction-count and date sanity check.
How the reconciliation check catches these
Extraction is only half the job. What protects you is the check that runs after it: opening balance, plus every extracted transaction, should equal the closing balance the bank printed. When it doesn't, something got dropped, duplicated, mis-signed or mis-scaled.
That single equation flags five of the six patterns above on its own. The two it can miss — wrapped phantom rows and carried-forward dates — are why the check also compares the extracted transaction count and date sequence against what the statement implies. A statement that doesn't reconcile is held up and flagged, rather than handed to you as a clean-looking file that's quietly wrong. This is the difference between a converter that extracts and one that verifies. For the general (non-format) version of these failures, see common PDF extraction errors.
Once a statement reconciles, the export drops into Xero, QuickBooks or Zoho Books in that software's native bank-import CSV format — you import the file yourself; there's no automated bank-feed sync, and there doesn't need to be for historical statements.
Frequently asked questions
Why do extraction errors differ from one bank to another?keyboard_arrow_down
Because each bank designs its statement differently. Whether debits and credits sit in one column or two, whether the date repeats on every line, and whether a running balance is printed all change how a parser reads the page. The bank's layout, not the converter brand, is the biggest predictor of which error you'll hit.
Which bank statements are hardest to extract accurately?keyboard_arrow_down
Image-only statements (scans and phone photos) are hardest, because OCR has to infer characters from pixels. After that, statements that wrap long descriptions onto multiple lines and those that show a running balance on every row cause the most parsing trouble.
Can a converter handle a scanned or photographed statement?keyboard_arrow_down
Yes, if it has OCR. Optical character recognition reads the image when there's no text layer. Accuracy depends on scan quality, so a reconciliation check matters most here — a single misread digit shifts the balance and gets flagged.
How do I know my converted statement is complete?keyboard_arrow_down
Check that it reconciles. If the opening balance plus every extracted transaction equals the printed closing balance, nothing was dropped or duplicated. A converter that flags non-reconciling statements does this for you instead of leaving you to find the gap later. See the extraction accuracy benchmark for how this is measured.
Does the converted file import straight into Xero or QuickBooks?keyboard_arrow_down
It imports as a file, not a live feed. The converter produces a CSV in the accounting software's native bank-import format, and you upload that file. It's reliable for historical data, but it isn't an automated API sync.
Try it on your own statement
Clean Excel/CSV, with every transaction checked to balance.