Skip to main content

Import transactions from CSV

Bring existing transactions into an account from a comma-separated values (CSV) file exported by your bank or spreadsheet.

Prerequisites​

Steps​

  1. In the left navigation, click Import, or open an account register and click Import to pre-select that account.
  2. In step File and account, choose the target account where imported rows should land.
  3. Drag a .csv file onto the drop zone, or click Choose file and select your export.
  4. Wait for the app to read the file. A format badge shows CSV and the source filename.
  5. In step Column mapping (CSV only), confirm the suggested column mapping:
    • Transaction date → purchase or activity date (for example Transaction Date)
    • Posted date (optional) → when your file has both dates and they differ, map Posted Date here; it is noted in memo, not as a second register date
    • Amount → a single amount column or map Debit and/or Credit when the export splits them (common on credit card files)
    • Description → payee or narrative column
    • Memo (optional) → card number, notes, or other reference (for example Card No.)
    • Override any dropdown if the preview looks wrong. The first few rows update as you change mapping.
  6. Leave Remember mapping for this account checked if you plan to import from the same bank layout again.
  7. Click Continue to open Review staging.
  8. In the staging table, confirm which new rows to import:
    • New rows are accepted by default (checkbox on).
    • Uncheck any new row you want to exclude.
    • Duplicate rows are always skipped — they cannot be imported.
  9. Click Continue to open the Commit summary.
  10. Review counts, the duplicate log (if any), and click Commit.

Aborting an import​

While the app is writing transactions (status Importing on Import → Import & sync activity), click Abort to stop. Transactions already written stay in the register; the import is marked Aborted.

If you close or quit the app while an import is writing, the next time you unlock the file that import is marked Aborted so it does not look like it is still running. Rows written before the app closed remain in the register.

Duplicate handling​

When a staged row matches an existing transaction in the same account, the app always skips it. Duplicates are never imported.

Matching uses:

  • A row fingerprint stored when a row was previously imported (account, date, amount, normalized description, and bank reference when present)
  • Heuristic comparison to existing register rows (same date, amount, and similar description)

Re-importing the same file should mark every row as a duplicate so nothing is double-counted.

The import summary lists skipped duplicates for your records (date, description, amount). This is informational only — no action is required.

If you believe a row was skipped incorrectly, add or correct the transaction manually in the register rather than forcing a duplicate import.

Expected result​

  • The commit summary shows how many transactions were added (for example 5 transactions added)
  • Accepted rows appear in that account’s transaction register with correct dates and signed amounts (expenses negative)
  • Skipped duplicate rows do not appear in the register; they are listed in the import summary
  • If you enabled Remember mapping, a second import with the same column headers autofills mapping with no manual dropdown work
  • Canceling before commit leaves the register unchanged
  • Aborting (or closing the app) during write keeps any transactions already imported and marks the run Aborted
  • When the file includes a bank running balance, the register may show an import anchor for the covered dates; gaps between non-contiguous imports show Missing history (see Import coverage)