CSV to CAMT

The short version

You have transactions in a spreadsheet. Something downstream, a treasury system, a reconciliation tool, a test harness, wants them as CAMT.053, the ISO 20022 XML that banks ship account statements in. Hand-writing that XML is miserable. So describe the transactions as CSV instead and let this build the document.

Six columns in, one <Ntry> per row out, wrapped in a proper camt.053.001.02 envelope. It’s the exact inverse of our CAMT to CSV tool, so a file you flattened there round-trips back here.

The columns it reads

Put a header row on top. Order doesn’t matter, the tool reads the names, not the positions, and it’s loose about spelling:

• date in YYYY-MM-DD. Becomes the booking date (BookgDt/Dt).
• amount as a positive number like 1250.00. This is the value that goes in <Amt>.
• currency as a three-letter code (EUR, USD, GBP). It fills the Ccy attribute. Leave it blank and you get EUR.
• creditDebit tells direction. Write CRDT or DBIT, or just credit / debit, any case. That maps to <CdtDbtInd>.
• counterparty is the other party’s name. On a credit it’s written as the debtor who paid you; on a debit it’s the creditor you paid. Same logic the reverse tool uses.
• reference is your payment note. It lands in RmtInf/Ustrd.

Small convenience: if you only have signed amounts, a leading minus (-89.90) is read as a debit and the sign is stripped, since CAMT amounts are always stored positive with the direction in a separate tag.

What comes out

A single statement with a group header (GrpHdr carrying a generated MsgId and the current timestamp) and one Stmt block. Each CSV row turns into an <Ntry> containing the amount with its currency, the credit/debit indicator, a BOOK status, the booking date, and an NtryDtls/TxDtls section holding the related party and the remittance text. Empty optional cells are simply left out rather than written as blank tags.

Everything you type gets XML-escaped on the way in. Ampersands, angle brackets, and quotes in a counterparty name or reference won’t break the document, so Smith & Co <Ltd> is encoded correctly instead of producing malformed XML.

Honest caveat: this is a minimal CAMT.053. It’s well-formed and namespaced correctly, and it carries the fields most reconciliation tooling reads, but it leaves out the heavier optional structures, account owner, opening and closing balances (Bal), bank transaction codes, end-to-end IDs. Some strict bank importers expect those. For testing, prototyping, and tools that only need entry-level data, it’s plenty. For submitting to a particular bank, check what their schema profile requires.

It all happens in your browser. The CSV is parsed and the XML is assembled in JavaScript on the page, nothing is uploaded. Given these are transaction records, that’s the right place for it to run.

FAQ

Is the XML actually valid CAMT.053?

It’s well-formed XML in the urn:iso:std:iso:20022:tech:xsd:camt.053.001.02 namespace with the correct element nesting for entries. It validates structurally and parses cleanly, including back through our CAMT to CSV tool. Whether it passes a specific bank’s stricter schema profile depends on which optional fields that bank mandates.

Does the column order matter?

Nope. The first row is treated as a header and each column is matched by name, so you can rearrange them however your export happens to spit them out. Amount and a credit/debit column are the only two that must be present.

What if I leave the currency blank?

It defaults to EUR. If your statement is in another currency, fill the column in, since the code goes straight into the Ccy attribute on every amount.

Can it produce one file with many transactions?

Yes. Every data row becomes its own <Ntry>, all inside a single <Stmt>. Twenty rows give you twenty entries in one statement document.

How do I handle a refund or money coming in?

Mark it CRDT (or credit) in the creditDebit column. The counterparty is then written as the debtor, matching how a real statement records an incoming payment.