Home › Blog › Xero & Accounting Software › Xero bank statement CSV format explained
The exact Xero bank statement CSV format, including required and optional columns, the money out negative rule, one header row, and UTF-8 encoding.
By StatementVerified Editorial · November 2, 2026 · 7 min read · Filed under Xero & Accounting Software
Xero imports bank statements by CSV with a mapping step that feels forgiving, and that forgiving surface hides strict expectations underneath. The file needs a single header row, a date column Xero can interpret unambiguously, and an amount column in which direction is expressed by sign under one firm convention: money leaving the account is negative and money arriving is positive for a bank account. Files that violate the convention do not always fail. They sometimes import with lines reversed, balances drifting, and a statement balance that will not agree, leaving the bookkeeper to untangle direction line by line inside the reconciliation screen.
This guide sets out the Xero statement format precisely: the core columns and what each is for, the optional columns and when they help, the encoding and header rules, and the pre import checks that confirm your file expresses the statement faithfully. If you convert PDF statements for Xero clients, shaping the file to this specification at conversion time is far cheaper than repairing lines inside Xero after import, where every fix competes with matching and coding work already in progress.
A Xero statement import centers on four ideas: when the transaction happened, how much moved and in which direction, who the other party was, and what the bank said about it. In file terms those are the Date, Amount, Payee, and Description columns. Date and Amount are the essential pair; an import cannot proceed sensibly without both on every row. Payee and Description carry the statement text that makes later coding, matching, and searching possible, and skimping on them to make the file simpler is a false economy, because a statement line inside Xero with a thin description is a line a bookkeeper must research manually every time it is questioned.
Keep one transaction per row, in full, with no subtotal, balance, or header rows repeated inside the data. Xero reads the file as statement lines that will each demand an accounting decision, so anything in the file that is not a genuine bank line becomes false work or a false balance movement. If your conversion carries a running balance for verification, keep that column in the workpaper copy only and export the import copy without it, unless you are deliberately mapping it as a reference, which most workflows should not. The import file should be the statement activity and nothing else, exactly as the bank activity list presents it.
Direction in a Xero bank statement file is expressed by the sign of the Amount value: deposits and other money in are positive, and payments, fees, checks, and other money out are negative, for a standard bank account. This is the rule whose violation causes the most damage, because a file built with the opposite intuition, or with all amounts unsigned and direction implied by a separate debit or credit column that never gets mapped, imports as statement lines pointing the wrong way. The account statement balance inside Xero then moves opposite to reality, and the mismatch against the true bank balance grows with every line instead of canceling out.
Build the signed amount deliberately from the statement. Where the statement separates debit and credit columns, translate them during shaping: credit values become positive amounts, debit values become negative amounts, and the separate columns disappear from the import copy. Where the statement shows a single amount with indicators such as a trailing minus or a credit marker, apply the same translation row by row and then prove the result: the sum of your signed amounts must equal the statement closing balance minus its opening balance. That one equation, checked before upload, certifies direction for the entire file more reliably than reading any sample of individual rows.
Beyond the core, Xero statement imports can carry additional mapped information, commonly a Reference column and a check number where the workflow uses it, which travel with the statement line and help matching against invoices, bills, and payments already in Xero. Use optional columns when the statement genuinely provides the data and your coding process benefits, such as check numbers for accounts with heavy paper check volume. Do not invent optional data to fill the grid. An optional column populated with repeated placeholders adds noise to every line and can interfere with matching suggestions that rely on meaningful reference text to propose the correct counterpart.
The file itself needs exactly one header row at the top naming the columns, with the data beginning immediately beneath it. Title blocks, account summaries, blank separator rows, and totals at the foot all belong in your workpaper, not in the import file, because extra rows at the top shift the header detection and extra rows at the bottom become phantom statement lines. Save as a standard CSV with UTF-8 encoding so characters in payee names, accented letters, and punctuation survive the journey intact. Encoding damage shows up as mangled characters in descriptions, which then defeats the text based matching and searching the descriptions were carried for in the first place.
Dates in the file must be consistent in format on every row and interpretable without guessing the order of day and month. Xero import mapping asks you to identify the date column and its format, and the same ambiguity hazard from other systems applies in full: a file built day first but declared month first will swap every date where both numbers are small, importing successfully and dating the accounting history wrongly. Choose one format, apply it uniformly during shaping, and declare it truthfully at mapping. Where your source statement prints dates in a local format, normalize them by true date value in your spreadsheet rather than by text replacement, so the normalized column carries real dates instead of lookalike strings.
After shaping, run the period sanity check: every date should fall within the statement period, the earliest and latest dates in the file should equal the statement first and last activity dates, and sorting a copy by date should produce a sensible progression with no rows stranded in adjacent months or years. That check catches the year errors and format stragglers that individual row reading misses. It also prepares you for the import mapping preview, where you should verify one known transaction date against the statement before completing the import, exactly the same paranoid habit that protects QuickBooks uploads, because the cost structure of a silent date swap is identical in both systems.
The reliable workflow mirrors every other destination in this series: start from a conversion proven against the statement balances, shape a copy to the Xero specification, and keep the proof with the source. Shaping means selecting and ordering the columns, translating amounts to the signed convention and proving their sum, normalizing dates, moving any balance or analysis columns to the workpaper, and saving as UTF-8 CSV with one header row. Then import into the correct Xero bank account, compare the imported statement line count and the resulting statement balance movement in Xero to the statement itself, and only then begin coding and matching the lines against invoices, bills, and spend or receive money transactions.
That final comparison inside Xero deserves emphasis, because it is the moment a shaping error is still cheap. If the imported lines move the Xero statement balance by anything other than the statement own movement, stop and repair the file rather than coding around the difference. Coding first and repairing later means unwinding accounting decisions to fix a data problem, the exact inversion of efficient order. With a proven file, a truthful mapping, and a post import balance comparison, Xero statement importing becomes the dependable workhorse it is meant to be for statement based clients, month after month, with the reconciliation screen reserved for judgment rather than archaeology.
At minimum a Date column and a signed Amount column on every row, with Payee and Description strongly recommended so lines can be coded, matched, and searched. Optional Reference and check number columns help where the statement provides them. Use one header row and one transaction per row.
For a bank account, money in is positive and money out is negative in a single Amount column. Translate any debit and credit columns from the statement into that signed amount during preparation, and prove it by confirming the amounts sum to closing minus opening balance.
Saving as UTF-8 preserves accented characters and punctuation in payee names and descriptions. Other encodings can mangle those characters, which damages readability and weakens the text based matching and search that good descriptions exist to support.
Xero & Accounting Software · November 3, 2026
Use the Xero duplicate statement lines review to find imported duplicates, verify each line against the bank statement, and delete only proven extras.
Xero & Accounting Software · November 4, 2026
Diagnose a Xero statement balance that does not match the bank, using the Statement Exceptions report, balance continuity, and line level proof.
Xero & Accounting Software · November 3, 2026
Use converted bank statements in FreshBooks expense and bank workflows, with general guidance on imports, matching payments, and balance verification.
Convert a statement now and watch the reconciliation check verify it against the statement itself.
Your first conversion is free — no card, no sign-up — and every result is reconciled against the statement itself before you download it.