Statement formats

Assetli reads statements from banks around the world. An automated test currently checks 203 bank export formats from 31 countries. This page describes which formats those are and what exactly is read from them.

How the format is recognised

What decides is the content of the file, not its extension or the bank you pick in the dialog. Banks often mix up extensions (an .xls statement is frequently HTML, a .txt file can be MT940 or CFONB). So if you select your bank and upload a different export than we expect, the file is read according to what it actually contains.

Recognition order:

1. Excel (XLSX, legacy XLS, HTML table) is converted to a table.
2. Standards and national formats have their own parsers (tables below).
3. Bank-specific parsers: Air Bank, Raiffeisenbank, UniCredit Bank (Czech Republic) and Wise.
4. Smart CSV detection for any other tabular file.
5. Manual or AI column mapping when detection is unsure.

International standards

Format	Where it is used	Extension	What is read
camt.053 (ISO 20022, SEPA XML)	euro area, Slovakia, Switzerland, Czech banks following the Czech Banking Association standard	.xml	your own IBAN, the counterparty and their account, reference, batch payments split into individual items
MT940 (SWIFT)	Germany, the Netherlands, Austria, Switzerland, Poland, Scandinavia	.sta, .940, .mt940, .txt	your own account, counterparty, reference; transaction details in all three common layouts (German ?20, Dutch /TRTP/, Polish ~20 and <20) as well as free text
OFX / QFX / QBO	United States, Canada, United Kingdom	.ofx, .qfx, .qbo	your own account, the bank’s transaction ID (reliable duplicate detection), merchant
QIF (Quicken)	United States, Canada, Australia, United Kingdom	.qif	date, amount, payee, memo; bank accounts, credit cards and cash

For QIF, the order of day and month is determined from the whole file (a single day greater than 12 is enough). If it cannot be determined, US MM/DD is used and the preview says so.

National formats

Format	Country	Specifics we handle
GPC / ABO	Czech Republic, Slovakia	fixed-width lines, amounts in hundredths, reversals flip the direction, full counterparty name and message for the payee from supplementary lines
Norma 43 (AEB, Cuaderno 43)	Spain	several accounts in one file, zero-amount movements are skipped, description from supplementary 23 records
CFONB 120	France	sign and last digit of the amount packed into one character, the file may have no line breaks, currencies without decimals (XPF)
CBI (RH / EC)	Italy	value date comes before the booking date, payer of an incoming transfer from supplementary lines
CODA	Belgium	a summary movement with detail items is counted once, structured communication +++…+++ used as the payment reference
Elixir	Poland (PKO BP and others)	looks like CSV, but amounts are in grosze and the direction is carried by code 111/222

Excel

Upload an Excel statement exactly as your bank gave it to you. These are read:

• XLSX (Excel 2007 and later),
• XLS in the legacy binary format,
• an HTML table with the .xls extension, which many Spanish and Italian banks send.

A date stored as a date in a cell is recognised from the cell format, so 2 March 2026 does not turn into the number 46083. If a workbook has several sheets, the one with the most rows is used. Header lines above the table (account name, period) are skipped just as with CSV.

Excel files are read by our own reader, which only reads cell contents. Formulas are not evaluated (the result Excel saved in the file is used), macros are never run, and a file that would grow beyond 50 MB when unpacked is refused. A password-protected workbook cannot be read; save it without a password, or download CSV from your bank. When you upload a file, Excel is read directly in your browser; with email import, it is read on the server.

CSV from any bank

Smart detection recognises columns by their content, not by the header names. That is why it works even for a bank we have never seen. It knows column names in dozens of languages, but uses them only as a hint.

• Separator: comma, semicolon, tab and pipe.
• Numbers: decimal comma and decimal point, thousands separated by a space, dot, comma or apostrophe (1'234.50 in Switzerland), negative amounts in parentheses or with a trailing sign.
• Dates: 15.07.2026, 15/07/2026, 07/15/2026, 2026-07-15, 20260715, 15 Jul 2026, 02-Mar-26, Mar 02, 2026, 15. července 2026, also with a time. The order of day and month is determined from all rows; if that is not possible, the preview says so and lets you choose.
• Payment direction:
  • a signed amount,
  • two columns (debit and credit, for example “Soll / Haben”, “Uscite / Entrate”, “Debe / Haber”),
  • a positive amount with a direction column next to it (S/H, D/C, DR/CR, Af/Bij, IN/OUT…).
• Credit cards: some banks (American Express, Discover, BMO, Nubank) record a purchase as positive and a payment as negative. This is recognised from the export header, or from the fact that all negative rows are payments and refunds. The sign is then flipped so that a purchase is not saved as income.
• Extra rows: header lines above the table, total rows (“Celkem”, “Total”, “Saldo”) and empty rows are skipped.

When detection is unsure, the dialog shows the columns and you assign them yourself, or let the AI propose the mapping. The AI receives only the header and a few sample rows, never the whole statement.

Character encoding

• UTF-8 and UTF-16 (also with a BOM) are recognised automatically.
• National formats have the encoding set by their standard: GPC and Elixir Central European (Windows-1250), CODA, Norma 43, CFONB and CBI Western European (Windows-1252). So a Belgian statement is read correctly even if you have the Czech market selected in Settings.
• Other files in a legacy encoding are read according to the market in Settings: Czech Republic, Slovakia and Poland as Windows-1250, all other markets as Windows-1252. For markets outside Central Europe, Cyrillic, Greek, Japanese, Korean and Chinese are also recognised from the content.

What we cannot read yet

• PDF. Open the statement, copy the text and use the “Paste text” tab. The Air Bank text layout is recognised.
• Investment statements in OFX (a list of holdings instead of account movements). Broker trades are imported in the Investments module.
• Password-protected files.
• The account number in some GPC statements from Komerční banka. In one variant of the format, KB scrambles the digits of the account number. Transactions are read correctly; only email import cannot tell from the number which account the statement belongs to, and suggests an account based on weaker clues.

Limits

	Limit
Statement size (text)	8 MB
Number of rows	60,000
Excel when unpacked	50 MB
Email attachment	10 MB, at most 20 statements per message

Split a large statement by period. Duplicates from the overlap are skipped.

How we verify coverage

We do not collect real customer statements; they are personal data. Instead, for each bank we keep a description of its export: columns, separator, date and number format, encoding, header lines. Each description cites its source (the bank’s documentation or a public importer) and a confidence level. From the description we generate a statement with eight typical transactions in the language and currency of that country. It goes through exactly the same import as your file, and the result is compared field by field. A row counts as read only if both the date and the signed amount match. A change that would read any format worse does not reach production.

A description can differ from reality, because banks change their formats from time to time. If your statement cannot be read, tell us through the contact form which bank and which export it is. Please do not send the file.

The import process, duplicate detection and undoing an import are described on the Importing data page. What to do when an import fails is covered in Import: what to do when it fails.