Short answer
Bank statement CSV import software reads the transaction file you export from online banking and checks it before anything is matched. DIGITAL EUR's demo imports comma-separated CSV files of up to 2 MB and 20,000 rows, validates every line, and stops with the exact line and column when something is wrong. camt.053 import and column mapping are planned.
What does the import step actually do?
Import is the least visible part of reconciliation and the one that causes most wrong results. A matcher can only be as good as the rows it receives: a decimal comma read as a thousands separator, or a debit read as a credit, produces confident nonsense further down. DIGITAL EUR therefore treats import as a gate. A file either passes every check or is rejected with a message you can act on; nothing is half-imported.
The pipeline in the Reconciliation Lab runs entirely in your browser, in this order:
- Size check. Files larger than 2 MB are refused before they are read.
- Read as UTF-8. A leading byte-order mark (BOM), which Excel often adds, is removed.
- Parse. The parser follows RFC 4180: comma separator, optional double quotes around a field, two double quotes for a literal quote, and CRLF, LF or CR line endings. Blank lines are skipped. Cell contents are kept as text and never evaluated.
- Header check. The first row must contain unique, non-empty column names, including every required column.
- Row check. Each row must have exactly as many cells as the header. IDs must be present and unique; currency must be a three-letter code; amounts must be well-formed; direction must be CRDT or DBIT.
- Row limit. More than 20,000 data rows in one file stops the import.
- Preview. Accepted rows are shown as tables (invoices; transactions with direction, remittance, counterparty and amount) so you can see what was read before you match.
- Hand-over to matching. Amounts are already converted to integer euro cents, so matching never touches floating-point numbers.
The checks stop at the first problem. Fix that line, run the import again, and the next problem, if any, is reported.
Which bank statement formats are supported?
| Format | Status | Notes |
|---|---|---|
| CSV, comma-separated, dot decimals | DEMO (available now) | The fixed layout described below |
| ISO 20022 camt.053 (end-of-day statement, XML) | PLANNED | Brings end-to-end ID, structured reference and counterparty into their own fields |
| CSV with semicolons, decimal commas, dates and bank-specific columns | PLANNED (column mapping with preview) | Today such files must be converted first |
| SWIFT MT940 | Not on the current plan | We would consider it only if customers' banks cannot provide camt.053 |
| camt.052 / camt.054 | Not planned | Intraday reports and notifications, not closing statements |
| OFX, QIF, Excel (XLSX), PDF | Not planned | Export CSV from your bank or spreadsheet instead |
| Live bank feeds, bank logins | Not planned | DIGITAL EUR works from files you export; it never connects to your bank |
Why camt.053 first? It is the ISO 20022 bank-to-customer statement, and it carries the data that matters for matching in separate, named elements rather than one text column. MT940 puts remittance and counterparty details into a free-text field whose layout varies by bank, and banks are moving their statement services to camt on their own schedules; Commerzbank, for example, says it will switch the statement format of the relevant EBICS connections to camt automatically on 16 November 2026. Our SEPA reconciliation guide compares the formats in detail and shows where each matching field sits in a camt.053 file.
What must the CSV look like?
You import two files: open invoices and bank transactions. Column names must match exactly (they are case-sensitive and surrounding spaces are ignored). Columns can be in any order, and extra columns are ignored, so you can leave a booking date or balance column in place.
Transactions file
| Column | Required | Rule | Example |
|---|---|---|---|
| transaction_id | Yes | Unique within the file | 2026-11-02-0457 |
| currency | Yes | Three letters; lower case is accepted and converted | EUR |
| amount | Yes | Non-negative, dot as decimal separator, at most two decimals, up to ten digits before the dot, no thousands separator | 1250.00 |
| remittance | Yes (may be empty) | Any text, including commas if the field is quoted | "Invoice INV-2026-0042, thanks" |
| direction | Yes | CRDT for money in, DBIT for money out; lower case accepted | CRDT |
| counterparty_name | No | Payer or payee name | Example GmbH |
| counterparty_iban | No | Spaces allowed | DE89 3704 0044 0532 0130 00 |
Invoices file
| Column | Required | Rule |
|---|---|---|
| invoice_id | Yes | Unique within the file |
| customer_name | Yes | Used for exact name evidence |
| currency | Yes | Three letters |
| amount_due | Yes | Same amount rule as above |
| reference | Yes | The reference you expect payers to quote, for example the invoice number or an RF creditor reference |
| customer_iban | No | The customer's paying IBAN, if known |
Two rules surprise people who are used to bank exports. First, amounts are never negative: the direction column carries the sign, so an outgoing payment of €30.00 is written as amount 30.00 with direction DBIT. Second, there is no date column: matching in the demo depends on references, IBANs, names and amounts, not dates. A date column in your file is accepted and ignored.
What error messages will you see?
We ran typical problem files through the current parser. These are the messages it returns, word for word, so you can recognise them.
| Problem in the file | Message |
|---|---|
| Semicolon-separated export | Line 2: expected 1 columns but found 2. |
| Decimal comma ("1250,00") | Line 2, column amount: Expected a non-negative amount with a dot and at most two decimals (e.g. 1250.00), got "1250,00" |
| Thousands separator, unquoted (1,250.00) | Line 2: expected 5 columns but found 6. |
| Negative amount (-30.00) | Line 2, column amount: Expected a non-negative amount … got "-30.00" |
| Three decimals (10.005) | Line 2, column amount: Expected a non-negative amount … got "10.005" |
| Missing column | Transactions CSV is missing required column(s): direction. Required: transaction_id, currency, amount, remittance, direction. |
| Same ID twice | Line 3: missing or duplicate transaction_id "T1". |
| Direction written as "C" | Line 2: direction must be CRDT or DBIT. |
| Currency written as "€" | Line 2: currency must be a 3-letter code such as EUR. |
| Quote never closed | Line 2: a quoted field is never closed. |
| Text after a closing quote | Line 2: unexpected text after a closing quote. |
| Empty header cell | The header row contains an empty column name. |
| Duplicate header | The header row contains a duplicate column name. |
| File over the size limit | The file is larger than the 2 MB limit for this demo. |
Line numbers refer to lines in the file, counting the header as line 1, and a quoted field that spans several lines is reported at the line where it starts.
A worked example: converting a typical European bank export
Many European online banks export something like this (invented data):
Buchungstag;Valuta;Auftraggeber;IBAN;Verwendungszweck;Betrag;Währung
02.11.2026;02.11.2026;Example GmbH;DE89370400440532013000;RE INV-2026-0042;1.250,00;EUR
03.11.2026;03.11.2026;Sample Bank;;Kontoführung Oktober;-30,00;EUR
The file uses semicolons, a decimal comma with a dot as thousands separator, and a signed amount. The demo will reject it at line 2. To convert it:
- Open the file in a spreadsheet with the correct import settings (semicolon separator, comma decimal) so that 1.250,00 is read as the number 1250.
- Add a transaction_id column. If the bank gives no unique ID, combine the booking date with a running number, for example 2026-11-02-001.
- Add a direction column: CRDT where the amount is positive, DBIT where it is negative. Then make every amount positive.
- Format amounts with two decimals and no thousands separator.
- Rename the columns: Auftraggeber to counterparty_name, IBAN to counterparty_iban, Verwendungszweck to remittance, Währung to currency, Betrag to amount.
- Save as CSV with comma separators and UTF-8 encoding.
The result imports cleanly:
transaction_id,currency,amount,remittance,direction,counterparty_name,counterparty_iban,booking_date
2026-11-02-001,EUR,1250.00,RE INV-2026-0042,CRDT,Example GmbH,DE89370400440532013000,2026-11-02
2026-11-03-001,EUR,30.00,Kontoführung Oktober,DBIT,Sample Bank,,2026-11-03
The booking_date column is kept for your own reference and ignored by the importer. If you merge exports from several accounts into one file, prefix each ID with an account label (for example DE01-2026-11-02-001) so IDs stay unique and you can still tell the accounts apart.
Column mapping with a preview, so that the importer reads your bank's own layout without this conversion, is PLANNED, together with handling of semicolons, decimal commas and date formats.
How does this compare with other import approaches?
The vendors below document their import features publicly; we read their pages on 5 November 2026.
| Approach | What it offers | What to watch |
|---|---|---|
| ERP or accounting import with mapping (Sequence, NetSuite's Bank Statement Parsers) | CSV with configurable mapping, plus camt.053 and MT940 parsers; NetSuite parses camt.053 versions 001.02 and 001.08 | Mapping is set up per bank; NetSuite notes UTF-8 requirements for its parsers |
| Add-on importers (for example a Cerevantix module for Odoo) | Column auto-detection, encoding and decimal detection, duplicate detection against earlier lines, saved bank profiles | Tied to one ERP and its hosting options |
| Dedicated reconciliation apps (Fast Four Bank Reconciliation) | Many formats; recommends camt first, MT940 second and CSV as configurable fallback; multi-account CSV needs an account column | Feature depth comes with configuration work |
| PDF-to-CSV converters | Turn PDF statements into spreadsheets | Converted figures must be checked against the original statement |
| DIGITAL EUR demo | One fixed CSV layout, strict validation with exact messages, local processing, no account | No mapping, no camt.053 and no duplicate detection across imports yet |
Our import is narrower than the mature options. What it offers is predictability: one documented layout, no silent guessing about separators or decimals, and a clear message for every rejection.
What does the importer not check?
Knowing the gaps matters as much as knowing the checks.
- Encoding. Files are read as UTF-8. A file saved in another encoding, such as Windows-1252, is not rejected, but accented characters may appear garbled in the preview. Save as UTF-8.
- Duplicates across files. IDs must be unique within a file; importing two overlapping statement exports is not detected. Deduplication across imports is planned.
- Balances. The demo does not check that transactions add up to an opening and closing balance. camt.053 import is the planned route to balance checks.
- IBAN validity. Counterparty IBANs are compared, not validated. The IBAN format checker page covers format checks.
- Account. There is no account column; the importer does not know which bank account a line belongs to.
If you want to check a file's layout before matching, the bank statement CSV validator page is the place for that question.
What should you check before exporting from online banking?
Most import problems start in the banking portal, not in the importer. Before you download a statement, check these points; they apply to any reconciliation tool, not only ours.
- Choose the right period. Export from the day after your last reconciled booking to today, so no booking is missed and none is imported twice.
- Pick the most detailed export. Many banks offer a short and a detailed CSV. The detailed one usually includes the full remittance text and the counterparty IBAN, which are your best matching evidence.
- Check that remittance text is complete. SEPA remittance information can be up to 140 characters. If the export cuts it short or merges it with the payer's name, references can disappear.
- Look for a unique booking ID. If the bank provides one, use it as transaction_id. It makes duplicates easy to spot when exports overlap.
- Note how the bank shows debits. A minus sign, a separate debit column, or a "S/H" (Soll/Haben) indicator all need converting into the CRDT/DBIT direction column.
- Check batch bookings. If several customer payments were booked as one line, the export will show one amount; split it only if the bank gives you the individual transactions.
- Keep the original file. The converted CSV is a working copy. Keep the bank's own export, unchanged, for your records and your accountant.
What happens after the import?
Once both files pass validation, the matching engine compares every incoming credit with every open invoice in the same currency and suggests pairs only where there is reference, IBAN or name evidence. How references, RF creditor references and the end-to-end ID are read from SEPA payments is explained on the SEPA invoice matching page. Scoring, approval, allocation caps and exports are covered on the bank transfer reconciliation software page. Import never decides anything on its own: it only guarantees that what reaches the matcher is what your bank file said.
Who is CSV statement import for?
It suits small businesses, freelancers and bookkeepers who already download statements from online banking and want to match receipts to invoices without migrating to a new ERP and without giving any tool their bank login. It also suits accountants who receive statement exports from clients by email. It does not suit teams that need automatic daily bank feeds, many-account cash management or card-acquirer settlement files.
How is your file handled?
In the demo, the file is read by your browser and never uploaded. There is no account, no server-side storage and no copy kept after you close the page. We still recommend synthetic or anonymised data, because the demo is built for evaluation. Before DIGITAL EUR accepts real customer files, the security page lists the controls that must exist, including upload limits, XML parsing that rejects external entities for camt.053, idempotent imports and a retention policy.
What will import cost?
Nothing yet: there is no checkout. The illustrative pre-launch prices on the pricing page are Solo €19 per month with CSV import, Growth €49 per month adding camt.053 import, and Agency €129 per month with bulk import and export for accountants. Prices exclude tax and may change.
What are the honest limitations?
- One fixed CSV layout; no column mapping today.
- Comma separator and dot decimals only.
- Stops at the first error rather than listing every error in the file.
- No date handling, balance checks or cross-file duplicate detection.
- 2 MB and 20,000 data rows per file.
- Demo only: nothing is saved between sessions.
Frequently asked questions
Can I import my bank's CSV file directly?
Only if it already uses the documented column names, commas and dot decimals. Most bank exports need the short conversion shown above; column mapping is planned.
Does DIGITAL EUR support camt.053?
Not yet. camt.053 import is planned and listed for the Growth plan. CSV is the only format available in the demo.
Will MT940 be supported?
It is not on the current plan. If your bank offers camt.053, that is the better source for matching.
Why must amounts be positive?
The direction column (CRDT or DBIT) carries the sign. This avoids the common mix-up between banks that sign amounts and banks that use separate debit and credit columns.
Is my file uploaded anywhere?
No. In the demo the file is read by your browser and discarded when you close the page.
What happens to outgoing payments in the file?
They are imported, shown in the preview and listed as unresolved, but never matched to invoices.
Can I import several bank accounts at once?
Yes, in one file, as long as every transaction ID is unique. Prefix IDs with an account label to keep them apart.
Sources
- IETF, RFC 4180: Common Format and MIME Type for Comma-Separated Values (CSV) Files (accessed 5 November 2026)
- ISO 20022, Message definitions catalogue (accessed 5 November 2026)
- Commerzbank, Umstellung von MT-Formaten auf camt-Formate (accessed 5 November 2026)
- Oracle NetSuite, Bank Statement Parsers SuiteApp (accessed 5 November 2026)
- Sequence, How do I import a statement in CSV, CAMT 053 or MT940 format? (accessed 5 November 2026)
- Fast Four, Supported file formats (accessed 5 November 2026)
- Cerevantix, Import Bank Statement for Odoo 18 (accessed 5 November 2026)