QuickBooks CSV Import Format

The format itself is simple. What trips people up is everything the bank statement adds on top of it — running balances, reference codes, currency symbols, wrapped description lines — none of which QuickBooks wants. Below is the exact shape of an accepted file, field by field, plus the two amount layouts side by side.

The two accepted CSV layouts

QuickBooks Online reads two column arrangements. The difference is only in how the money is expressed.

The mistake to avoid is mixing them. A signed Amount column *and* a separate Debit/Credit pair in the same file gives QuickBooks columns it can't place, which is one of the most common reasons for the vague "file isn't formatted correctly" message. Choose 3-column or 4-column. Don't hedge.

Field-by-field requirements

Each field has its own rules. Get these right and the mapping screen barely needs your help.

A few things QuickBooks does *not* want anywhere in the file: the running balance, transaction-type codes, reference numbers, a second description line, merged header cells, or blank rows between transactions. Strip all of it. A file that imports first time is almost always a file you've cut down hard.

What an accepted file actually looks like

Here's a 3-column file as QuickBooks reads it. Note the signed amounts and the bare numbers — no `$`, no ``, no commas.

```csv Date,Description,Amount 06/02/2026,Opening deposit,2400.00 06/04/2026,Card payment - office supplies,-86.40 06/09/2026,Client invoice 1042,1250.00 06/14/2026,Direct debit - utilities,-142.18 ```

And the same transactions in the 4-column layout, with money split into Credit and Debit:

```csv Date,Description,Credit,Debit 06/02/2026,Opening deposit,2400.00, 06/04/2026,Card payment - office supplies,,86.40 06/09/2026,Client invoice 1042,1250.00, 06/14/2026,Direct debit - utilities,,142.18 ```

Both files carry the same information. The only real decision is whether money out lives as a negative number in one column or as a positive number in a Debit column.

Getting the date format right

The date field causes more rejected rows than anything except the amount column. The problem is order, not the digits. A date written `06/04/2026` is the 4th of June in the US and the 6th of April across the UK, Australia and Ireland. QuickBooks doesn't guess — if the order you pick on the mapping screen doesn't match how the dates are actually written, every row either lands on the wrong day or gets bounced.

Two safe habits. First, keep one date order throughout the file; a statement that mixes formats halfway down will never import cleanly. Second, write dates as `YYYY-MM-DD` when you're editing by hand — it's unambiguous, and Excel is far less likely to silently reinterpret it on save. Whatever order you use, set the matching choice on the mapping screen and then check one transaction you remember. If a payment you know landed on the right day, the rest will too.

File requirements

Beyond the columns, the file itself has to meet a few plain conditions:

• Plain CSV (or .xlsx). QuickBooks Online's manual import won't read a PDF, a .numbers file, or a Google Sheets link as transactions.
• One header row, then one transaction per row. No title rows, no bank logo rows, no blank spacer rows above the data.
• UTF-8 text with standard commas as the delimiter. Semicolon-delimited exports from some regional Excel settings can confuse the parser.
• No merged cells. These survive a CSV export as misaligned columns and break the mapping.

If your statement starts life as a PDF, none of this applies until you've converted it — QuickBooks treats a PDF as a document, not as data. The import PDF statements into QuickBooks guide walks the full conversion-to-upload route, and if an upload throws an error, how to fix QuickBooks import errors maps each message to its cause.

The check the format can't do

Here's the part that matters most, and it's the part a format spec quietly ignores. A CSV can match every rule above — three tidy columns, clean signed amounts, the right date order — and still be wrong. Because format only tells you the file is *readable*. It says nothing about whether the file is *complete*. A converter can hand back a perfectly shaped CSV that imports without a single complaint and is missing a transaction, because one Direct Debit fell off the bottom of page four during extraction. A clean file that's incomplete is the dangerous kind, because you'll trust it.

This is why the running balance earns its keep. It's a built-in checksum: opening balance, plus money in, minus money out, has to equal the printed closing balance. Recompute it row by row and the first line where your total stops matching the bank's figure is the exact transaction that went missing or got misread. You do this *before* the import, not at month-end when QuickBooks won't reconcile and you've no idea which row to blame.

Export Bank Statement is the web app built around that check. It converts the PDF — including scanned and photographed statements, via OCR — into a clean CSV or Excel file, then runs the running-balance reconciliation: it recomputes the totals against the printed closing balance and flags any statement that doesn't reconcile, so a dropped or misread line surfaces before it ever reaches QuickBooks. It writes the file in QuickBooks' native bank-import CSV format too, so the columns arrive in one of the two layouts above without you reshaping anything by hand. We once watched a neat-looking file fail the check over a single payroll line clipped from a batch — the flag turned an afternoon of hunting into a one-minute fix.

Be plain on what it is, though: convert, then upload. It doesn't push transactions into QuickBooks through a live bank-feed API, and it isn't a bookkeeping service — you decide what gets imported. Still wondering whether QuickBooks can take a statement at all? Can QuickBooks import PDF bank statements? answers that, and the wider US accounting guides cover the rest.