Xero CSV Import Format Explained

The columns are the easy part. The detail that quietly breaks imports is the date order and whether your amounts are signed correctly — so this guide pins down each field exactly, then shows what an accepted file looks like.

The required and optional columns

Xero is stricter than most importers about what it *needs*, but generous about what it'll *accept*. You can hand it a two-column file and it works; you can hand it six columns and it maps the extras. Here's every field the Import a Statement screen recognises.

A minimum viable file, then, is two columns: Date and Amount. In practice you want at least a Payee or Description as well, because that's the text Xero uses to suggest matches on the Reconcile tab. A bare date-and-amount file imports fine but gives you nothing to recognise each line by later.

One thing Xero does *not* want is a running balance column. The statement balance is useful to you — it's how you confirm nothing was dropped — but it isn't a transaction field, so leave it out of the file you upload.

Date: the field that breaks the most imports

The Date column causes more failed Xero imports than every other field combined, and it's never the digits — it's the order. A line written `06/05/2024` is the 6th of May to a UK or Australian reader and the 5th of June to a US one. Xero resolves this from your organisation's date format setting, not from the file, so the file has to match what your org expects.

Get it wrong and one of two things happens. Either Xero rejects the rows outright, or — worse — it accepts them on the wrong day, sliding part of your period into a neighbouring month without a single error message. The safe move is to know your org's setting (UK orgs are typically DD/MM/YYYY) and produce the CSV in that exact order. When you're editing dates by hand, `YYYY-MM-DD` is the least ambiguous, and Excel is far less likely to silently reformat it on save.

Keep one date order throughout. A file that switches halfway down — a common artefact of copy-pasting from two statement pages — will never import cleanly.

Amount: signed column or split Debit/Credit

Xero takes the value two ways, and both work as long as you don't mix them in one file.

The first is a single signed Amount column: money out written as a negative number (`-142.18`), money in as a positive number (`1250.00`). This is the cleaner option for most statements. The second is a two-column Debit and Credit split: money out as a positive number in the Debit column, money in as a positive number in the Credit column, with the other cell left blank on each row.

The mistake that trips people up is hedging — a signed Amount column *and* a separate Debit/Credit pair in the same file. Xero then sees a value it can't place and the import fails or double-counts. Pick one. And whichever you pick, the numbers must be bare: no currency symbol, no thousands separator. `1,250.00` should be `1250.00`. A pound sign or a comma inside the number is enough to bounce the row.

What an accepted Xero CSV looks like

Here's a signed-Amount file laid out the way Xero's importer reads it — Date, Amount, then Payee and Description for context. Note the negative for the card payment and the bare numbers.

```csv Date,Amount,Payee,Description 05/06/2024,4210.00,Opening balance,Brought forward 06/06/2024,1250.00,Acme Ltd,Invoice 1042 07/06/2024,-142.18,British Gas,Direct debit utilities 10/06/2024,-86.40,Viking,Card payment office supplies ```

And the same transactions with the value split into Debit and Credit columns instead of one signed Amount:

```csv Date,Debit,Credit,Payee,Description 05/06/2024,,4210.00,Opening balance,Brought forward 06/06/2024,,1250.00,Acme Ltd,Invoice 1042 07/06/2024,142.18,,British Gas,Direct debit utilities 10/06/2024,86.40,,Viking,Card payment office supplies ```

Both carry identical information. The only real decision is whether money out is a negative number in one column or a positive number in a Debit column.

The file rules around the columns

Beyond the columns themselves, the file has to meet a few plain conditions before Import a Statement will read it:

• Plain CSV, UTF-8 encoded. Xero's statement importer also takes OFX and QIF, but for a converted PDF, CSV is the format you'll use. It will not read a PDF, a .numbers file or a spreadsheet link as transactions.
• One header row, then one transaction per row. No title rows, no bank-logo rows, no blank spacer rows above or between the data.
• One bank account per file. Don't pool two accounts into one CSV — you import each account's statement into that specific account in Xero.
• No merged cells. These survive a CSV export as misaligned columns and break the field mapping.

When you run Import a Statement, Xero shows a mapping screen where you point your columns at its fields and confirm the date order. Map it once for an account and Xero remembers the layout, so the next statement from the same bank imports faster. If a file does get rejected, how to fix Xero import errors maps each message to its cause.

A correct format still isn't a complete file

Here's the part a format spec quietly skips. A CSV can satisfy every rule above — two clean columns, signed amounts, the right date order, valid UTF-8 — and still be wrong. Format only tells you the file is *readable*. It says nothing about whether the file is *complete*.

That gap matters because of where these files come from. A PDF statement is a page layout, not a table. Descriptions wrap onto a second line, a bank prints the date once and blanks the rows beneath, a transaction gets split across a page break. When a converter extracts the rows, a line can drop out and nothing flags red — you get a perfectly shaped CSV that imports without a complaint and is missing a Direct Debit. A clean file that's incomplete is the dangerous kind, because you'll trust it.

The running balance is the checksum that catches this. 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 — found before the import, not at month-end when Xero won't reconcile and you can't tell 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 reaches Xero. It writes the file in Xero's native bank-import format too, with Date and Amount laid out the way Import a Statement reads them, so you're not reshaping columns by hand. We once watched a tidy-looking file fail the check over a single card payment clipped at a page break — the flag turned an hour of hunting into a one-line fix.

Be plain about what it is, though: convert, then import the CSV. It does not push transactions into Xero through a live bank-feed API — that's a separate, certified integration — and it isn't a bookkeeping service. You decide what gets imported. For the full upload route, see how to import PDF bank statements into Xero, and the Xero pillar gathers the related import and reconciliation guides.