Import a bank statement

Bring your bank activity in from a statement file:

1. Go to Ledger › Banking › Statements.
2. Click Upload Statement and pick a PDF, CSV, OFX, or QFX file: you can select several at once.
3. Under Which account is this statement for?, pick the account the files belong to, then click Upload. A statement is filed on the account you choose and takes that account's currency, and its lines are checked against what that account already holds, so a line your bank feed already delivered is not added twice.

HQ never creates an account on its own from a statement. If the account isn't in HQ yet, choose New account and pick Bank account, Credit card or Line of credit. Before anything is created, HQ shows the number the account will get in your chart of accounts: the next free number from 1050 for a bank account, or from 2600 for a credit card or line of credit. Click Use a different number to pick another free number, or one of your existing chart accounts that no other account posts to yet (an account your accountant set up, for example). A new account can be in your book's currency or in a foreign currency HQ supports, such as USD. A foreign bank account gets its own ledger account the first time one of its transactions is recorded, so there is no number to show or choose for it yet. Leave its name blank and HQ names it from the statement, using the bank's name and the last four digits of the account number it reads.

If the account number printed on a statement doesn't match the one on the account you chose, the statement shows Account number differs on the Statements tab, with both numbers. HQ leaves it where you put it: check the paper statement (some banks print a member number near the account number), and if it was filed under the wrong account, use Move. If it is the right account and the bank simply prints a different number on its statements, choose This is the right account: HQ remembers that number for the account, and its statements stop being flagged. Nothing in your books changes.

A PDF is read in the background: the row shows Processing, then flips to completed once HQ has pulled out the transactions and checked them against the statement's own balances. CSV and OFX files import right away. An OFX or QFX file also runs HQ's automatic matching as soon as it has imported, the same as a PDF statement does once it is read, so a deposit that matches a store payout or a payment on an invoice is matched without another step. A CSV's lines wait for the next automatic pass, or for Run Matching. On the Statements tab, everything filed under one account sits in one section named after that account, so a CSV and the PDF statements of the same card appear together. Sections start closed, like the accounts on the Transactions tab: click one to open it, and it stays open next time.

A CSV for a credit card or line of credit has to say which way its amounts go, and banks disagree: some write a purchase as a positive amount, others as a negative one. HQ reads it off the file itself, since purchases outnumber payments on a card. When the file leans clearly one way, it imports and the message says so (for example "positive amounts read as purchases"). When it is too short or too evenly split to tell, nothing is imported yet and HQ asks: pick Positive amounts are purchases or Positive amounts are payments, and the same file imports with your answer.

A CSV can also give the amounts as separate Debit and Credit columns instead of one Amount column. HQ goes by the column, not by the sign of the number: a figure under Debit is money out and a figure under Credit is money in, even if your bank writes debits as negative numbers. There is no purchases-or-payments question to answer, because the columns already say which way each amount goes. A row with nothing in either column, or with a figure in both, can't be read and is reported as skipped. If a file has an Amount column as well, HQ reads that and ignores Debit and Credit.

A file that puts the amount under a CAD$ or USD$ column, as RBC's exports do, is read the same as an Amount column: HQ uses whichever of the two holds the amounts, and the currency is your account's.

A CSV's dates need an order too. A date like 02/03/2026 is 2 March in one bank's file and 3 February in another's, and HQ never guesses which. If any date in the file has a number over 12 in it, that settles the order for the whole file: 25/03/2026 can only be day first, and 03/25/2026 can only be month first. If every date is 12 or under, nothing in the file says, so before anything is imported HQ shows you one row both ways (for example Day first: 2 Mar 2026 and Month first: 3 Feb 2026) and asks you to pick. HQ remembers your answer for that account's next file and says so when it uses it. A file that writes some dates day first and others month first is refused with a message, because there is no safe way to read it: export it again with the dates in one order (2026-03-02, year first, is safest and is never asked about). A file added through Add paperwork that needs this answer is held with a message to upload it on the Statements tab instead, where the question is asked.

If none of a CSV's rows can be read (a date or amount HQ doesn't recognise), the upload is refused and the message names the first problem, rather than leaving an empty statement behind. If only some rows can't be read, the rest import and the message says some were skipped.

Click a CSV or OFX file's name on the Statements tab to open it. HQ keeps the file you uploaded and shows it as a table: a CSV with every column as your bank wrote it, an OFX or QFX file with each transaction's date, type, amount, payee, memo and FITID. The columns read as the date, amount and description are marked (for a Debit and Credit file, both of those columns). Each row says whether it was imported, was not imported (it was already in your books from an earlier import, or its line has been removed since), or couldn't be read, and why. The Recorded as column shows each amount the way it went into your books, so on a card you can see a positive purchase recorded as money out; click it to open that line on Transactions. Download gives you back the original file. A CSV or OFX file is read exactly as written, so there is no Re-extract for one. Files imported before 26 October 2026 weren't kept, so opening one of those says so.

Extracted transactions land on the Transactions tab ready to categorize and match. Everything belonging to one account sits in one list in date order, whether it came from a statement, a connected bank feed, a file import or your own typing: under each date is a small note saying which. Each statement row lets you rename its account, Move it to another account, open it to fix any rows that don't tie, or delete it.

Overlapping imports are safe, in any mix of formats. Each file you import is checked against what the same account already holds, whether it came from a PDF statement, a CSV, an OFX file or your bank feed: a charge already there is linked to the new file instead of added again. Across formats that means the same amount within five days, however each one words it, so you can download a CSV or OFX file mid-month and import the PDF statement when it arrives. When two lines already there fit equally well, the line is imported and shows up in Banking › Review for you to choose. So does a charge whose amount changed between the two files (a tip added, a foreign charge settling at another rate), including between two overlapping CSV or OFX downloads of the same account: HQ asks Same charge, amount changed? rather than merge it. A Keep both answer is remembered for those two readings, so reading the file again does not ask the same question twice.

If a connected bank feed already delivered some of a statement's transactions, HQ links those existing lines to the statement instead of importing them a second time. The statement still accounts for every line it lists, and any work already done on the feed's copy (a category, a match, a reconciliation) is left exactly as it was. On a line nobody has worked yet, the statement's own transaction date wins over the feed's posted date, which usually runs a day or three later.

Move really does move the transactions, not just the name on them, so use it when a statement was filed under the wrong account. HQ refuses the move once any of those transactions has been categorized or matched: their entries are already recorded against the account they are on now, and shifting them would leave your books saying one thing and the transaction another. Clear the categories or unmatch first, then move. A line that actually came from your connected bank feed stays on its own account either way: the move releases its link to the statement instead of carrying it along. If the account you move it onto already has some of its lines, from its bank feed or from another file, the statement links to most of them instead of adding them a second time, and the lines themselves are left exactly as they were. A statement line that carries a note, a suggested match or a receipt, or one HQ cannot tell apart from another line, is not linked: it stays, and waits for you in the duplicate review. Move the statement back and the lines this move linked become its own again. A bank-feed line the statement had linked when it was uploaded or re-read is let go by any move and not brought back, so the statement can arrive (or come back) one line short; Re-extract the statement to restore it.

If the statement is in a supported foreign currency (for example USD), choose that currency's account when you upload, or make it there with New account in that currency: its lines convert to your book's currency at the rate for their date. If the statement is in a currency HQ can't convert, or its lines end up on an account in a different currency, they still import but can't be categorized or matched, because posting them would book the foreign amount as your own currency. A health card on your dashboard lists each of those lines. If they were filed under the wrong account, Move the statement onto the account that really holds the money: the Move menu lists your accounts from Banking › Accounts. A statement moved onto a different account takes that account's currency, and so do its lines. A new name typed under + New account… that matches no account only renames the statement, and HQ says so: add the account under Banking › Accounts first, then move the statement onto it.

If the statement is already under the right account but its currency was read wrongly (a CAD statement read as USD, say), a Move can't fix it, because there is nowhere to move it. Instead, find it on the Statements tab in Banking: a note on the statement says which currency it was read in and which currency its account is held in, with a button to use the account's currency. Press it and confirm, and the statement and every line it imported take the account's currency; nothing new is recorded in your books. A line that came from your connected bank feed is left alone, since it belongs to the feed's own account. It only ever offers the account's own currency. HQ refuses it while any of those lines has an entry in your books (from categorizing it, for example), is matched, or is part of a completed reconciliation, and the note says which. Clear the category or unmatch first. Once you have chosen a statement's currency this way (or by moving it, or by changing the currency in its preview), re-extracting it keeps your choice. Uploading the same file again as a new statement reads the currency off it afresh.