Bank Statement Converter - camt.053 / MT940 to JSON, CSV, Ex

Bank Statement Converter - camt.053 / MT940 to JSON, CSV, Excel

Problem: your bank switched account statements from MT940 to camt.053 (ISO 20022 XML) - Commerzbank EBICS from 2026-11-16, many German, Dutch and Polish banks during 2025-2026 - and your accounting import, ERP integration or spreadsheet still expects MT940 or a simple table. Or you get camt/MT940 files from clients and need them as JSON or Excel. Desktop converters cost EUR 39-180 per year and run only on Windows.

This API: send the file (link or content), get it back as JSON rows, CSV, Excel (xlsx) or MT940 - in about a second, no AI, no account at a converter site.

• Inputs: camt.053 versions .001.02 / .04 / .08 (any .001.NN), camt.052, MT940 (with or without SWIFT envelope), and a .zip with up to 50 files. Raw text or base64.
• Outputs: json = one row per statement + one row per transaction; csv (UTF-8 with BOM, opens in Excel); xlsx (sheets Transactions + Statements); mt940 = camt converted to MT940 for older software.
• Balance check in every statement: opening balance + all entries = closing balance, with the difference when it does not match.
• Parsed fields: booking and value date, signed amount, currency, credit/debit, counterparty name + IBAN + BIC, remittance text (unstructured + structured reference), end-to-end ID, mandate ID, creditor ID, bank transaction code, references, purpose code, reversal flag. Batch entries are split into one row per transaction. German :86: subfields ?20-?33 and Dutch /TRTP/.../IBAN/.../REMI/ are read.
• Privacy: files are processed in memory only and never stored or logged. Error messages quote at most the first 40 bytes.

Example (API)

curl -X POST "https://api.apify.com/v2/acts/martin10291~bank-statement-converter/run-sync-get-dataset-items?token=YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"fileUrl": "https://example.com/statements/camt053-2026-11-12.xml", "format": "json"}'

Send the file itself instead of a link: {"fileContent": "<base64 of the file>", "format": "xlsx"}. Run with no input to convert a built-in sample statement.

Transaction row (from the built-in sample):

{"type": "transaction", "statementId": "EXAMPLE-2026-211", "account": "DE02120300000000202051", "bookingDate": "2026-11-02", "valueDate": "2026-11-02",
 "amount": 250.0, "currency": "EUR", "creditDebit": "CRDT", "counterpartyName": "Nordwind Logistik AG", "counterpartyIban": "DE89370400440532013000",
 "counterpartyBic": "COBADEFFXXX", "remittance": "Rechnung 2026-1042", "endToEndId": "INV-2026-1042", "bankTxCode": "PMNT/RCDT/ESCT", "status": "BOOK"}

Statement row:

{"type": "statement", "account": "DE02120300000000202051", "currency": "EUR", "openingBalance": 1000.0, "closingBalance": 2560.9,
 "sumCredits": 1730.0, "sumDebits": -169.1, "balanceCheck": {"ok": true, "expectedClosing": 2560.9, "closingBalance": 2560.9, "difference": 0.0},
 "sourceFormat": "camt.053.001.08"}

For csv, xlsx and mt940 you get one row with fileName, contentBase64 (decode and save) and the statement summaries.

Use from agents (MCP)

Add the Apify MCP server (https://mcp.apify.com?tools=martin10291/bank-statement-converter) to Claude, Cursor or any MCP client and ask: "Convert this camt.053 file to Excel and tell me if the balances add up."

Daily feeds (monitor)

onlyNew: true + monitorId (format json): returns only transactions not returned before under that ID, so a daily download that repeats yesterday's entries gives you each booking once. Only one-way hashes of the transaction keys are kept, never the statement.

Input

Field	Meaning
fileUrl	public http(s) link to the file or zip (max 10 MB); private/local addresses refused
fileContent	the file as text or base64
fileName	optional, used for sourceFile and the output file name
format	json (default), csv, xlsx, mt940
inputFormat	auto (default), camt053, mt940
onlyNew, monitorId	only new transactions per feed

Honest limits

• No PDF statements (they need OCR); only the bank's electronic camt/MT940 files.
• MT940 output follows the format's limits: SWIFT character set (umlauts become ae/oe/ue/ss), names cut at 54 and purpose at 378 characters, long end-to-end IDs kept in :86: as EREF+. The German GVC code is derived when the camt has none.
• Polish bank-specific :86: layouts are kept as raw text in remittance.
• :64: / :65: (available balances) are not parsed.

FAQ

Do you keep my statements? No. The file is parsed in memory during the call and dropped; nothing is written to disk or to logs. Which banks? Any bank that issues standard camt.053/052 or MT940 (Commerzbank, Deutsche Bank, Sparkassen, Volksbanken, ING, ABN AMRO, Rabobank, PKO BP, mBank and others).