Import Bank Transactions & Set Categorization Rules

Last updated: 2026-07-09 Summary:

Import a bank statement (CSV or Excel) using a Philippine bank preset or your own column mapping.
Categorization rules suggest a category for matching transactions — they don’t post anything.
Importing and rules never touch the ledger. Only categorizing a transaction in the Bank Register posts a journal entry.

Everything here is under the Banking area and needs the banking permissions (viewing needs banking:read, importing needs banking:import, editing rules needs banking:write). Banking is available on every plan.

Import a statement

Go to Banking → Import.
Account — choose the bank account you’re importing into. If none exists yet, add one under Banking → Accounts first.
Upload — drag in a .csv or .xlsx file (up to 10,000 rows / 10 MB). Macro-enabled .xlsm files aren’t supported.
Map columns — either pick a preset or map manually:
- Built-in presets cover BDO, BPI, UnionBank, Security Bank, and RCBC. (The BPI preset is a best-guess from sample statements — check the parsed rows before you commit.)
- To map manually, point each source column at a field (date, description, amount, or separate debit/credit), set how many header rows to skip, and choose the date format that matches your file. You can save a valid mapping as your own reusable preset.
Preview — check the parsed rows. Likely duplicates and rows that couldn’t be parsed are flagged and skipped; the confirm button tells you how many rows will actually import.
Confirm — the transactions land in the Bank Register as uncategorized entries.

Set categorization rules

Rules save you from hand-categorizing recurring transactions (bank fees, recurring transfers, a regular supplier).

Go to Banking → Rules and create a rule.
Give it a pattern and a match type — Contains, Starts with, or Regex — and choose the account the match should be categorized to. Use the built-in “Test rule” box to check your pattern against a sample.
Rules match on the transaction description. When more than one rule could match, the first matching rule wins (rules are evaluated oldest-first).
To apply your rules to transactions you’ve already imported, use Apply to existing.

Nothing posts until you categorize

This trips up almost everyone, so it’s worth being explicit:

Importing a statement posts nothing to the ledger. It only adds uncategorized rows to the Bank Register.
A matching rule only suggests a category. It fills in a suggestion and still leaves the row uncategorized — it does not post an entry.
The ledger only moves when you Categorize a transaction in the Bank Register. That’s the step that creates the balanced journal entry (and it respects closed periods).

So import and rules get you 90% of the way; the deliberate Categorize click is what commits the accounting.

Import history and undoing an import

Each import is recorded as a batch. From a bank account you can open its import history to see when each file was imported, how many rows landed, and how many were skipped as duplicates or parse errors.

To undo an import, delete the batch. It removes the batch and any of its transactions you haven’t touched yet. If some rows in the batch are already categorized or matched, the delete is refused — un-categorize those rows first, then delete.

Transfers between your own accounts

Money moving between two of your own bank accounts isn’t income or expense. Record it under Banking → Transfers → Create Transfer: pick the from/to accounts, amount, and date. That creates the matching entries on both accounts and posts one balanced journal entry. Do this instead of categorizing the two imported lines separately — and note there’s no tool to pair two already-imported rows as a transfer, so avoid also importing both sides if you record the transfer here.

Where people get tripped up

Wrong date format. The importer parses dates with the format you set in the mapping. If your statement is dd/MM/yyyy and the mapping says MM/dd/yyyy, those rows fail to parse and get skipped. Set it deliberately.
Duplicate detection is by content, not by a bank reference. Two rows with the same date, amount, and description are treated as the same transaction and skipped. That’s usually right, but genuinely distinct same-day/same-amount transactions can be caught — check the preview’s skipped count.
Only CSV and Excel are supported. OFX/QBO and PDF statements aren’t imported — convert to CSV or use a bank preset.
“I imported but nothing’s in my reports.” Right — import doesn’t post. Categorize the transactions (or let rules suggest, then confirm) to move them into the ledger.