Importing a bank statement
Importing CSV statements, saving a column mapping as a reusable template, and how duplicate detection keeps overlapping imports from double-counting.
How-toFor Bookkeepers, Business owners, Firm staff
When you import
- The account has no connected feed.
- The feed has a gap — an outage, a re-authentication, a period before you connected.
- You are bringing in history from before your cutover date.
- You want the statement's own record rather than the feed's interpretation of it, ahead of a reconciliation.
Running an import
- 1
Download the statement from your bank as CSV.
Take the widest date range that still overlaps what you already have. Overlap is safe — duplicate detection handles it — and gaps are not.
- 2
In Banking, choose the account and start an import.
- 3
Map the columns.
At minimum: date, description, and amount. Some banks provide separate debit and credit columns instead of one signed amount; map both and the importer will combine them.
- 4
Check the sign convention on the preview.
This is the step that goes wrong. Money leaving the account should be negative. If the preview shows your rent payment as positive, invert the amount mapping before continuing.
- 5
Save the mapping as a template.
Templates are stored per account, so next month's import from the same bank is a single click.
- 6
Import, and confirm the transaction count.
The result reports how many rows were imported and how many were skipped as duplicates.
Duplicate detection
Imports are matched against transactions already in the account on date, amount, and description. Rows that match existing transactions are skipped and reported, rather than added again.
This is what makes overlapping ranges safe, and it is why you should always overlap rather than trying to import exactly the missing days.
Formats and awkward files
| Problem | What to do |
|---|---|
| The file has header rows above the column names. | Delete the preamble rows so the header row is first, and re-upload. |
| Amounts contain currency symbols or thousands separators. | These are handled, but check the preview — a locale using commas as decimal separators needs the file re-exported. |
| Dates are ambiguous (03/04/2026). | Set the date format explicitly during mapping rather than letting it be inferred. |
| Only a PDF statement is available. | Upload it through Document Intake, which extracts the transactions, then review the extraction before it reaches the feed. |
| Separate debit and credit columns. | Map both. Do not map only one and negate it — you will lose half the activity. |
Common questions
No. An import puts transactions in the account's feed, where they wait to be categorized. Nothing reaches the journal until a transaction is coded to an account.
Imported transactions that have not been categorized can be removed. Once a transaction has been categorized it has posted to the ledger, so removing it means reversing the entry — recategorize or reverse rather than trying to delete.
See alsoCorrecting a posted entry
Imports are per account, because the mapping and the sign convention are properties of that bank's export. Saved templates make repeat imports fast enough that batching is rarely worth it.
Was this useful?

