MT940 vs CSV: what’s the difference?
MT940 is the SWIFT format banks hand you when you download a statement. It’s a stack of tagged lines like :61: and :86:, designed for accounting software to ingest, not for a person to skim. CSV is the opposite: plain rows and columns that Excel, Google Sheets, and every bookkeeping app on earth understand.
So you’ve got a .sta file and your accountant wants a spreadsheet. That’s the gap this fills. Paste the statement on the left, get a table on the right. One transaction per row, ready to import, with the SEPA reference fields (end-to-end ref, mandate, purpose, counterparty name and IBAN) split into their own columns whenever your bank fills them in.
How the conversion works
Each MT940 file is a sequence of tags. The parser walks them in order and pulls out what matters:
:20:is the transaction reference, the statement’s header ID.:25:holds the account number (IBAN or account ID). It shows up as context above the table.:28C:is the statement and sequence number.:60F:is the opening balance, and:62F:is the closing balance. These bracket the transactions.:61:is where each line item lives, and:86:is the human-readable description that follows it.
The real work is decoding :61:. That single line packs the value date, an optional booking date, a debit or credit mark, the amount, a transaction type code like NTRF or NMSC, and a reference, all jammed together with no delimiters. The parser reads it field by field per the SWIFT spec. A D mark turns the amount negative; a C keeps it positive. Booking dates borrow their year from the value date, since :61: only stores MMDD for that part.
Then :86: gets cleaned up. Many banks use the structured form with subfield codes like ?00, ?20, ?32, and SEPA tags like SVWZ+, EREF+, MREF+. The Description column drops that scaffolding so you’re left with the readable remittance text, while the structured pieces (end-to-end reference, mandate, creditor id, purpose, counterparty name, IBAN and BIC) each get their own column. The untouched :86: is kept in a Raw column too, so nothing is lost. If your bank writes plain free-text descriptions instead, those pass straight through.
Things to watch out for
Balance lines aren’t transactions. The :60F: and :62F: tags carry the opening and closing balance, and the parser uses them as boundaries rather than turning them into rows. Your CSV holds only the actual :61:/:86: movements.
Amounts use a comma as the decimal separator in MT940, the European convention. The output converts that comma to a period (1250,00 becomes 1250.00) so spreadsheets read it as a real number. Debits come through signed with a minus, which makes summing a column trivial.
Multi-line :86: blocks get stitched together first. SWIFT wraps long descriptions across several physical lines, and any line that doesn’t start with a : is treated as a continuation of the tag above it. So a four-line remittance note ends up in one cell, not scattered across four broken rows.
Heads up on dialects. MT940 has variants, and German, Dutch, and SWIFT-reference layouts differ in how they pad fields and structure :86:. This parser targets the common SWIFT layout and the usual ?NN subfield codes. If your bank does something exotic, check the description column and adjust the input where a field looks off.
Everything runs locally in your browser. Your statement, with its account numbers and payee names, never gets uploaded.
FAQ
What’s the difference between the Date and Value Date columns?
Date is the booking date, when the bank actually posted the entry. Value Date is when the money became available for interest purposes. They’re often the same day, but not always.
Why are some amounts negative?
Debits get a minus sign so you can sum the Amount column directly. Credits stay positive. The Debit/Credit column spells it out too, in case you’d rather filter on text.
Can it open a .sta file directly?
Not yet. Open the file in any text editor (it’s plain text), copy everything, and paste it in. Takes about five seconds.
Does it handle reversals?
Yep. RC (reversal of a credit) posts as a debit, and RD (reversal of a debit) posts as a credit, matching the balance effect the SWIFT spec gives them. Both keep the correct sign in the Amount column and get a Y in the Reversal column so you can spot them.
My description has weird codes in it. What happened?
Some banks pack extra subfields into :86: that don’t follow the standard ?NN pattern. The parser keeps the readable parts. If something looks cluttered, your bank may use a custom dialect that needs the raw text trimmed by hand.
Is the comma decimal handled correctly?
Yes. MT940 uses 1234,56 style amounts, and the output rewrites them as 1234.56 so your spreadsheet treats them as numbers, not text.