Bank statement imports

If your bank does not support automatic syncing, or if you need to import historical transactions, you can upload bank statements manually. Financica reads the file, shows you what it found, and posts the transactions to your ledger once you confirm.

Accessing bank statement imports

Navigate to Data Sources > Bank statements in the sidebar.

Supported formats

You can drop several files at once. Each file is read on its own and gets its own account and its own preview. A single file may be up to 50 MB.

CSV — Only bank-specific CSV layouts are recognised: Wise, Revolut, Mercury (both the QuickBooks and the NetSuite export) and KBC (English and French exports, including the accented Latin-1 files KBC produces for non-English locales). A generic CSV from another bank is rejected with an "unsupported CSV format" message. Export a CAMT.053 file or a PDF from that bank instead.
CODA — The Belgian bank statement format (Febelfin), which every Belgian bank exports and accountants receive through Codabox. Recognised by its content, whatever the file is called (.cod, .txt, a bank-specific suffix). Booking date, amount, counterparty name and account, the structured communication (OGM) and the bank's transaction code are all read. A structured communication becomes the transaction's reference in +++xxx/xxxx/xxxxx+++ form, so a customer payment carrying the reference printed on your invoice is matched to it. A batch payment (one line on the account with several beneficiaries detailed under it) is imported as one transaction, with the details kept on it. A file holding several daily statements is imported in full.
CAMT.053 (XML) — The ISO 20022 bank statement format, exported by most European banks. Booking date, amount, counterparty, references, bank transaction codes and exchange details are all read from the file. Only the first statement in the file is imported, so export one statement per file. Entries still marked as pending are imported alongside booked ones.
PDF — Any bank's statement PDF, in any language. This is the most flexible route and the one that needs the most checking. See below.

In a CSV, CODA or CAMT.053 file, rows with no usable date, or with an amount of zero, are skipped, and the preview tells you how many before you commit to anything. On the PDF paths that figure means less: the AI parser counts only the rows whose date it could not read, and the KBC parser always reports none skipped. On a PDF, check the transaction count against the statement rather than trusting the skipped figure.

How PDF statements are read

A statement PDF goes down one of three paths, chosen automatically:

A bank-specific parser, when Financica recognises the bank. Today that means KBC and no other bank. Dates, amounts and statement numbers are read exactly from the printed lines, with no guesswork; the counterparty name, account and payment reference are then tidied up by the AI parser, which is the part worth a glance. This path is the most reliable one available. It does not read the balance column, so a KBC PDF never produces an opening balance; see below.
The AI parser, for every other bank. The statement's text is handed to a model that works out the columns, the language and the sign convention for itself. This is what makes an arbitrary bank's PDF importable at all, but it is a reading of the document rather than a guaranteed transcription.
OCR, when the PDF carries no text at all (a scan or a photo of a statement). The pages are read into text first, then handed to one of the two paths above. OCR takes longer: the upload comes back as "processing" and the preview appears once the pages have been read. Quality follows the scan, so a crooked or low-resolution page is where errors come from.

The AI parser has limits worth knowing about:

The statement is split into pieces and read piece by piece, so a long statement takes several passes. Five pages is the ceiling, but a piece is also capped by how much text it holds, and on a busy statement that is usually what decides the split, so pieces are often shorter. Each pass has its own time limit; if one fails, the whole file fails to parse and you are asked to try again. Splitting a very large statement into shorter periods usually gets it through.
Where a statement prints a running balance, Financica uses it as a checksum: each line's balance must be the previous one plus that line's amount. A mismatch means a line was missed, duplicated or given the wrong sign. It does not block the import, so if the closing balance in Financica does not match the closing balance printed on the statement, that is your signal to look at the imported rows.
A piece that comes back with far fewer transactions than the rest of the document is automatically read a second time, and the better answer is kept. This guards against a silently truncated read, but it is not a proof of completeness.

Whichever path was used, check these three things against the paper statement before moving on: the number of transactions, the closing balance, and the sign on a couple of refunds or incoming payments.

How to import

Drop the files onto the upload area, or click to browse. Parsing starts immediately and each file gets a row of its own.
Pick the target account for each file. Only bank accounts in the statement's currency are offered. If none exists, choose to create one — for a PDF, the IBAN and BIC found on the statement are filled in for you.
Review the preview: format, transaction count, skipped rows, currency and date range.
Import. Transactions are posted, and the file itself is kept so you can download it later.

The uploaded file is stored even when parsing fails, so a statement Financica could not read stays listed and downloadable.

Supported currencies

Financica supports 37 currencies, covering the euro, sterling, the US dollar and most European and major world currencies. If a statement contains a currency outside that list, the import is blocked before anything is posted and the message lists the currencies you can use. A statement mixing several currencies needs a bank account for each.

Opening balances

Where the statement prints a running balance, Financica works out what the account held before the first transaction (first line's balance minus its amount) and posts that as an opening balance, dated the day before that transaction. The Wise, Revolut and KBC CSV exports carry one, a CODA file always does (it states the balance before its first movement), and so does a PDF read by the AI parser whenever the statement prints a balance column. CAMT.053 and Mercury exports do not — and neither does a KBC PDF, because the KBC parser reads only dates and amounts. Importing a KBC PDF therefore never posts an opening balance; use KBC's CSV export if you need one.

This matters for reconciliation: without it, an account whose history starts mid-life would show a balance made only of the transactions you happened to import, and would never agree with your bank.

Three rules keep it safe:

It is posted only on an account with no transactions yet. Importing into an established account never touches its balance.
It is decided once per account, ever. If you delete the opening entry deliberately, a later import will not put it back.
An opening balance of zero is not posted.

The other side of the entry goes to the Opening balance adjustments equity account, so the balance sheet stays balanced while you have only partial history.

What happens when transactions are posted

Every imported row becomes a real double-entry transaction, marked as cleared:

One side lands on the bank account you selected, for the amount and in the currency on the statement line.
The other side lands on Uncategorized Income or Uncategorized Expenses, depending on the direction.

That second side is a parking place, not an answer. The work after an import is categorising those transactions, either by hand or with the AI suggestions. See Categorizing transactions.

If you have Stripe connected, payout lines in the statement are matched against your Stripe payouts as part of the import, so a payout is not booked twice.

Wise statements

Wise CSV exports are handled in more depth than a plain statement, because a Wise line often describes more than one movement of money:

Fees — Where a line carries a fee, the fee is split onto its own Wise bank charges entry and the expense side keeps the gross amount. Your costs are not understated and the fee stays visible.
Currency conversions — A conversion posts both sides through the Currency exchange account, so the money leaving one balance and arriving in another is one transaction rather than two unrelated ones.
Payments that convert on the way out — When you pay in one currency out of a balance in another, the transaction records the amount leaving your balance, both sides of the exchange, the fee, and the expense in the currency the recipient was actually paid.
Cashback — Booked to a Wise Cashback income account rather than left uncategorised.
Card and bank-detail order fees — Booked to Wise bank charges.
Missing currency accounts — If a Wise statement contains a currency you have no account for, a Wise account for that currency is created automatically. This happens for Wise statements only.
The same charge in two statements — A movement that Wise labels as a currency conversion appears in both currency statements. Importing the second one merges into the existing transaction instead of creating a second copy. Only lines Wise labels this way are matched across statements; anything else printed in both is imported twice.
Reversals and holds — Rows sharing one Wise transaction id are grouped. If they net to something other than zero (a charge with a partial fee reversal) they are merged into one transaction. If they net to exactly zero (a charge and its full reversal, the pattern behind ride-hailing and fuel authorisation holds) they are kept as two transactions, because each side is meaningful on its own. How many groups were merged and how many were kept is recorded as a warning on the import, which you read in the tooltip on its status badge in the import history.

Duplicates

How well Financica can recognise a transaction it has seen before depends on the format:

Wise statements carry Wise's own transaction ids. A row that matches a transaction already in your books — from an earlier Wise import, or from a connected Wise account — updates that transaction rather than creating a second one. This is what makes re-importing an overlapping Wise export safe.
CODA files identify each movement by account, statement number and position, which survive between exports. Re-importing a file you already imported, or one that overlaps it, updates the existing transactions instead of creating a second copy.
Every other format (Revolut, Mercury, KBC, CAMT.053 and PDFs) has no identifier that survives between exports, so rows are identified only by their position in the file being imported. Re-importing the same file, or a period you have already imported, posts those transactions a second time.

So keep imports to periods you have not covered yet, and if you do import an overlapping file, undo it rather than deleting transactions one by one.

Transactions arriving through an automatic bank connection are deduplicated separately, on the bank's own references. See Connecting bank accounts.

Import history

The bank statements page lists every file you have uploaded, whether or not it became an import. Each row gives you the file name, with the source format as a small icon beside it and the period covered on a line underneath; the account; a status badge; and the date of the upload.

The status badge holds the numbers. Hover it to see how many transactions were imported, how many rows were skipped, how many were counted as duplicates, the total row count, and any warnings or per-row errors.
Download — in the row's actions menu: the original file, exactly as uploaded.
Undo & delete — also in the actions menu: removes the transactions that import created, and unlinks any invoice payments that were matched to them. Use this to back out a bad or duplicated import in one step. It is offered only for rows that became an import; a file that failed to parse can only be downloaded.

Best practices

Import chronologically — Start with the oldest statements and work forward, so opening balances and running balances line up.
One account per file — A file should cover a single bank account. Multi-currency Wise exports are the exception and are handled for you.
Prefer structured formats — CODA, CAMT.053 and a supported CSV are transcriptions; a PDF is a reading of a document. Use the PDF route when nothing better is on offer.
Check the closing balance — Compare the account balance in Financica against the balance printed on the statement. It is the fastest way to catch a missed or mis-signed line.
Do not import a period twice — Outside Wise and CODA, nothing stops it. Check the import history first.
Use automatic syncing when possible — Manual imports are a fallback. A connected account is more reliable for ongoing bookkeeping. See Connecting bank accounts.