CAMT to CSV

What is CAMT.053 anyway?

Your bank sent you a statement and the file ends in .xml. You open it expecting numbers and instead get a tangle of <Ntry>, <CdtDbtInd>, and <RmtInf> tags nested six levels deep. That’s CAMT.053, the ISO 20022 standard for bank-to-customer account statements. Banks across Europe and a growing chunk of the world hand it out instead of the old MT940 telex format.

It’s great for software. It’s terrible to read. And good luck importing it into a spreadsheet as-is.

Paste the XML here and you get a flat CSV back, one row per transaction. Seven columns: booking date, amount, currency, credit or debit, a signed amount, the counterparty name, and the remittance reference. Drop it into Excel, Google Sheets, or your accounting import and move on.

How the conversion works

The parser reads the document with the browser’s built-in DOMParser, then walks every <Ntry> element. Each entry is one booking on your statement. Here’s what gets pulled from each one:

• Booking date comes from BookgDt. If the bank used a full timestamp (DtTm) instead of a plain Dt, the time portion is trimmed off so the column stays a tidy date.
• Amount and currency read from <Amt> and its Ccy attribute. So <Amt Ccy="EUR">1250.00</Amt> splits into 1250.00 and EUR.
• Type maps CRDT to Credit and DBIT to Debit. The raw codes are ugly, so they’re spelled out.
• Signed amount flips debits negative. Money out shows as -89.90, money in stays positive. Handy for a quick SUM in a sheet.
• Counterparty is direction-aware. On a debit, the relevant party is the creditor you paid; on a credit, it’s the debtor who paid you. The parser grabs whichever Nm fits and falls back to the other if one’s missing.
• Reference joins the unstructured remittance lines (RmtInf/Ustrd). Some banks split a payment note across two or three of these, so they’re stitched together with a space.

One detail worth mentioning: CAMT has a dozen versions (camt.053.001.02 through .08 and beyond), each with its own XML namespace. Rather than hard-code one, the parser matches on tag names and ignores the namespace prefix entirely. A German bank’s file and a Swiss one parse the same way.

Things to watch out for

CAMT lets a single <Ntry> wrap several individual transactions in a batch (think a payroll run booked as one line). This converter reads the first transaction detail block per entry. For most personal and small-business statements that’s exactly one transaction per entry, so you’ll rarely notice. If your bank batches heavily, expect one row per booking rather than one per underlying payment.

Nothing leaves your browser. The XML is parsed locally, which matters a lot here, since a bank statement is about as sensitive as a file gets. No upload, no server, no log.

FAQ

Which CAMT versions does it support?

Any camt.053 statement that uses standard Ntry elements, regardless of the exact minor version. Because it ignores XML namespaces and matches tag names, it works across .02, .04, .08, and the rest without you picking anything.

Will it handle CAMT.052 or CAMT.054 too?

Often, yes. Those formats share the same <Ntry> structure, so intraday reports (052) and debit/credit notifications (054) usually parse fine. It’s tuned for 053, but the underlying tags overlap.

Why is my debit shown as a negative number?

That’s the Signed Amount column doing its job. The raw <Amt> value is always positive in CAMT, so debits are flagged separately with DBIT. The signed column folds that direction into the number so you can total a whole month with one formula.

The counterparty cell is empty. What gives?

Some banks omit the party name on certain bookings, like fees or interest. When there’s no Nm to read, the cell stays blank instead of guessing. The rest of the row still comes through fine.

Can I open the result straight in Excel?

Yep. The CSV follows RFC 4180, quoting any field with a comma or line break and ending rows with CRLF, which is what Excel expects. Hit Download for a statement.csv, or copy and paste into a sheet.