Import transactions from CSV

Import bank statements by CSV when a live connection is unavailable — LHV, Swedbank, SEB and Wise formats recognised, with duplicates skipped automatically.

A live bank connection is the comfortable route, but CSV import covers everything it can't: a bank or payment service that isn't in the connection list, history from before the date you connected, or a simple preference for not linking your bank at all. The destination is identical either way — imported transactions land in the same queue and go through the same reconciliation as connected ones.

CSV import also pairs well with a live connection. A connection reaches back up to a year, but some banks only release 90 days of history through open banking — a statement export is how the older history gets in, uploaded straight onto the same account. See Import your financial history for the full backfilling picture.

Exporting a statement from your bank

Every internet bank can produce an account statement as a file: log in, open the statement or transactions view for the account, pick the period and choose CSV as the format. Arvello accepts .csv, .tsv and .txt files, and recognises the export formats of LHV, Swedbank, SEB and Wise out of the box — Estonian or English column names, semicolon delimiters, comma decimals and DD.MM.YYYY dates included. Files from other banks work too; they just need their columns mapped by hand on the first import.

Importing a statement

Create a CSV bank account (first time only)

Go to Banking → Bank Accounts → Add Bank Account and choose CSV Import. Give the account a label such as "LHV Business" or "Wise EUR", plus its IBAN — bank accounts in Arvello are euro accounts, so for a multi-currency account (Wise again) this is its EUR balance. This is the account your statements will import into from now on. Already sync this account through open banking? You don't need a separate CSV account — open that account's menu and choose Upload Statement to add a CSV straight onto it, which is the usual way to backfill history older than the bank's API returns.

Upload the file

Open the account card, select Upload Statement and drop your file into the wizard.

Map the columns

Arvello detects which bank the file came from and pre-fills the mapping; for anything else it makes a reasonable guess from the column names, which you can correct. A date column is required, along with an amount — a single signed Amount column, separate Debit and Credit columns, or an unsigned amount paired with the bank's debit/credit indicator column (the D/K letter in Estonian bank statements, which marks whether money went out or came in — LHV, Swedbank and SEB files have this mapped automatically). Description, counterparty name and IBAN, payment reference and currency are optional, but the more of them you map, the better auto-matching and rules work later. For currency-conversion lines — Wise's Exchange To Amount and Exchange To columns are recognised automatically — the original foreign-currency amount is stored alongside the booked amount, matching what a live open banking connection records. The mapping is saved per account, so the next statement sails straight through this step.

Preview and import

The preview shows the first 50 rows as Arvello will record them — a moment to confirm the dates parsed correctly and outgoing payments show as negative. Statement summary lines — opening and closing balances and turnover totals — are recognised and left out automatically, so they never import as transactions. Rows that look like transactions already pulled in through open banking are flagged and left unticked for you (every flagged row stays visible to review, even beyond the first 50); tick or untick any row to control exactly what imports. Then Import. The result screen reports how many transactions were imported, how many were skipped as duplicates and any rows that failed.

Categorisation rules and auto-matching run over the new arrivals straight away, so by the time you open the transaction list, the routine items may already be handled. Whatever remains sits in "Needs review", ready for reconciliation.

Filling a missing-history gap

When a connected account's first import couldn't reach as far back as your books need, the account card shows a missing-history warning and the import wizard opens with the missing period named at the top — see Connect your bank for how the shortfall is detected. Export a statement from your internet bank covering at least that range and upload it as usual.

After the import, the result screen gives a verdict: either the missing period is now covered, or part of it is still uncovered, listed by date range. Statement rows can only prove coverage where transactions exist, so a quiet account may leave the edges of the range looking uncovered — if the account simply had no transactions then, confirming it with the button on the result screen clears the warning.

Duplicates and re-importing

Each imported row gets a fingerprint built from its date, amount, description and counterparty — plus the bank's own transaction ID when the statement carries one, which is mapped automatically for the recognised bank formats and keeps otherwise-identical rows apart. If a row with the same fingerprint already exists in that account, it is skipped — so re-importing a statement that overlaps a previous one is safe, and the result screen simply reports the overlap as duplicates skipped. There is no need to trim exports to exact date ranges before uploading.

When the same account also syncs through open banking, Arvello additionally checks each CSV row against the transactions the bank already delivered — matching on amount and date — and pre-ticks those to skip in the preview. The two feeds word the same payment differently, so this cross-source check deliberately ignores the description and leans on the amount and date instead. You can override its preview choice, and Arvello honours it: a row you tick to import is kept, even if it looks like a duplicate. The only row it still sets aside on its own is one the bank delivered after the preview was built — you never saw it to decide, so a clear match (same amount and date with a matching reference, counterparty account or same-day name) is left out to stop the two feeds booking the same payment twice, and shows in the skipped-duplicates count.

ℹ️Genuinely identical transactions

Two real transactions that match on all four fields — same day, same amount, same description, same counterparty — look like one transaction to the duplicate check when the file carries no bank transaction ID, so the second is skipped. Statements from the recognised banks include their ID and are unaffected; for a hand-mapped file without an ID column, editing the description of one row in the CSV before importing makes them distinct.

Two other quiet filters apply. Transactions dated on or before your opening balance cutover date are skipped automatically, since that period is already represented in your opening balances and importing it again would double-count. And rows booked in a currency other than the euro are skipped with their own count on the result screen — Arvello's books are kept in euros, so a USD or GBP statement can't be reconciled; export the EUR balance's statement instead. If an import comes up shorter than the file, those two counts are worth checking before suspecting anything more exotic.