You converted a bank statement PDF to CSV, tried to import it into QuickBooks Online or Xero, and got an error — or worse, the import "succeeded" but the numbers are wrong.
CSV import errors are frustrating because they're often silent. A misformatted date doesn't throw an error — it just posts transactions on the wrong day. A misplaced column doesn't crash the import — it just swaps your debits and credits.
This guide covers the most common bank statement CSV errors, explains why they happen, and shows you how to fix them.
1. Date Format Mismatch
The symptom: Transactions appear on wrong dates, or the import fails with "invalid date."
Why it happens: Your bank's PDF uses one date format (e.g., DD/MM/YYYY), but your accounting software expects another (e.g., MM/DD/YYYY). The date 03/04/2026 could mean March 4th or April 3rd depending on the convention.
How to fix it:
- Check what format your accounting software expects. QuickBooks Online uses MM/DD/YYYY by default. Xero uses your organization's regional setting.
- Open the CSV in a text editor (not Excel — Excel silently reformats dates) and verify the date column.
- If dates are wrong, use find-and-replace or a spreadsheet formula to swap day and month positions.
How Exact Statement avoids this: Dates are parsed from the PDF and output in the format your target software expects. You choose your output format (QBO 3-col, QBO 4-col, Xero) and dates are formatted accordingly.
2. Character Encoding Issues (Garbled Text)
The symptom: Payee names or descriptions show garbled characters like é instead of é, or â€" instead of —.
Why it happens: The CSV file was saved in one encoding (e.g., UTF-8) but opened or imported with another (e.g., Windows-1252/Latin-1). This is especially common with international bank statements that contain accented characters, currency symbols, or non-Latin scripts.
How to fix it:
- Open the CSV in a text editor that lets you choose encoding (VS Code, Notepad++, Sublime Text).
- Re-save the file as UTF-8 with BOM — the BOM (byte order mark) helps Excel and other tools detect the encoding correctly.
- If importing to QuickBooks, ensure your system locale matches the encoding.
How Exact Statement avoids this: All CSV output uses UTF-8 encoding by default, which handles international characters correctly across all major accounting platforms.
3. Column Mismatch (Wrong Number of Columns)
The symptom: Import fails with "unexpected number of columns" or "header mismatch." Or data imports but amounts appear in the description field.
Why it happens: The CSV has a different number of columns than the accounting software expects. Common causes:
- Descriptions containing commas that split into extra columns (if not properly quoted)
- Missing or extra header columns
- Mixed row formats within the same file (e.g., some rows have 4 fields, others have 5)
How to fix it:
- Open the CSV in a text editor and check that every row has the same number of commas (delimiters).
- Look for unquoted fields that contain commas — the description "Transfer to Savings, Checking" will split into two columns unless wrapped in double quotes.
- Verify the header row matches what your software expects exactly.
How Exact Statement avoids this: Output files are generated with strict column counts matching the target format. Descriptions containing commas or special characters are properly quoted per RFC 4180.
4. Amount Sign Confusion (Credits vs. Debits)
The symptom: All transactions import as positive (or all as negative). Deposits and withdrawals aren't distinguished.
Why it happens: Banks represent credits and debits in different ways:
- Some use a single column with positive/negative signs
- Some use parentheses for negatives:
(500.00)instead of-500.00 - Some use separate Credit and Debit columns
- Some add a "CR"/"DR" suffix
When the CSV converter doesn't normalize these correctly, your accounting software can't tell deposits from withdrawals.
How to fix it:
- For QuickBooks Online 3-column format: amounts should be negative for money out, positive for money in — all in a single
Amountcolumn. - For QuickBooks Online 4-column format: use separate
CreditandDebitcolumns with positive values only. - Search for parenthesized values and replace them:
(500.00)→-500.00.
How Exact Statement avoids this: Amount signs are normalized during extraction. You choose your output format, and amounts are formatted to match — single signed column for QBO 3-col, split columns for QBO 4-col.
5. Thousands Separator and Decimal Confusion
The symptom: An amount of 1,234.56 imports as 1234560 or 1.234 imports as one-point-two-three-four instead of one thousand two hundred thirty-four.
Why it happens: Different countries use different conventions:
- US/UK:
1,234.56(comma = thousands, period = decimal) - Europe:
1.234,56(period = thousands, comma = decimal)
If the CSV uses one convention and the importing software assumes the other, amounts will be wildly wrong.
How to fix it:
- Check which convention your accounting software expects.
- Use find-and-replace to swap separators if needed.
- Be especially careful with amounts that have no decimal places: is
1.500one and a half, or one thousand five hundred?
How Exact Statement avoids this: Amounts are parsed from the original PDF format and output with the standard US convention (comma for thousands, period for decimal) which is the default for QuickBooks Online and Xero.
6. Repeated Headers from Multi-Page PDFs
The symptom: Extra rows appear in your import that look like headers — "Date", "Description", "Amount" show up as transaction descriptions.
Why it happens: When a bank statement spans multiple pages, the column headers often repeat at the top of each page. If the PDF-to-CSV converter doesn't strip these, they become data rows in the CSV.
How to fix it:
- Open the CSV and search for rows containing header text like "Date" or "Description" in the date column.
- Delete those rows manually.
- Check for page footer rows too (e.g., "Page 2 of 5", "Continued on next page").
How Exact Statement avoids this: Repeated headers and page footers are automatically detected and removed during extraction. The output CSV contains only transaction data rows.
7. Opening / Closing Balance Rows
The symptom: Your reconciliation total doesn't match because non-transaction rows (opening balance, closing balance, totals) were included as transactions.
Why it happens: Bank statements typically include summary rows — opening balance, closing balance, total debits, total credits. These aren't real transactions, but they sit inside the same table structure as the transaction rows.
How to fix it:
- Look for rows where the description says "Opening Balance," "Closing Balance," "Total," or similar.
- Delete these rows before importing — they're informational, not transactional.
How Exact Statement avoids this: Our extraction engine distinguishes between transaction rows and summary rows. Balance information is preserved as metadata but not included as transaction lines in the CSV output.
8. Empty Rows and Whitespace
The symptom: Import fails with vague errors, or blank transactions appear in your ledger.
Why it happens: The CSV contains empty rows (blank lines between transactions) or cells with invisible whitespace characters (spaces, tabs, non-breaking spaces). Some accounting software chokes on these; others silently create empty transaction entries.
How to fix it:
- Open the CSV in a text editor and remove blank lines.
- Use find-and-replace to remove leading/trailing whitespace in each field.
- Check for non-breaking spaces (Unicode
\u00A0) which look identical to regular spaces but can cause import errors.
How Exact Statement avoids this: All output is trimmed and cleaned. No blank rows, no trailing whitespace, no invisible Unicode characters in the exported CSV.
Quick Troubleshooting Checklist
Before you import a bank statement CSV into any accounting software, run through this checklist:
- Open the CSV in a text editor (not Excel) to see the raw data
- Check the header row — does it match what your software expects?
- Verify the date format — MM/DD/YYYY vs. DD/MM/YYYY
- Count the columns — every row should have the same number of delimiters
- Check amount signs — are debits negative? Are there parenthesized values?
- Look for junk rows — header repetitions, page footers, balance summaries
- Verify encoding — do special characters display correctly?
- Check for blank rows at the end of the file
Skip the Troubleshooting Entirely
Most CSV errors come from the conversion step — turning a PDF's visual layout into structured data. If the converter doesn't handle bank statements specifically, you'll spend more time fixing the CSV than you saved by not typing it manually.
Exact Statement is built specifically for bank statement PDFs. It handles date normalization, amount formatting, column mapping, encoding, header deduplication, and all the edge cases above — so the CSV you download is ready to import on the first try.
Ready to skip the CSV debugging? Convert your first bank statement for free — no sign-up required for your first page.
