What Is an MT940 File? SWIFT Statement Format Explained

TL;DR: An MT940 file is the SWIFT message type banks use to deliver an end of day account statement. It is plain text built from tagged fields: :20: for the statement reference, :25: for the account, :60F: for the opening balance, one :61: line per transaction, :86: for the narrative under each transaction, and :62F: for the closing balance. It usually arrives with a .sta, .940 or .mt940 extension, and it has to be parsed before a spreadsheet or accounting system can use it.

What is an MT940 file?

MT940 is the SWIFT standard for a customer statement message. A bank generates one per account per statement period, almost always end of day, and sends it to a corporate customer or that customer's treasury system. It is the machine readable equivalent of the paper statement: an opening balance, every posting that hit the account, and a closing balance that the postings have to add up to.

The MT prefix means Message Type, and 940 is the number SWIFT assigned to customer statements. You will run into its relatives too. MT942 is an intraday report of activity so far today, and MT950 is a shorter statement message with less narrative detail. All three share the same tagged structure, which is why a parser that reads one usually reads the others.

The practical thing to understand is who MT940 was designed for. It was never meant for a person to read. It was built so a bank's system could hand a statement to a corporate treasury system without either side agreeing on a bespoke format first. That design choice is exactly why the file looks impenetrable when you open it, and why it is useful once it is parsed.

What does an MT940 file look like inside?

Open one in Notepad and you get something like this, minus the line wrapping:

:20:STMT260715
:25:12345678901
:28C:00142/00001
:60F:C260714USD48250,00
:61:2607150715D1250,00NTRFINV-88104//REF9931
:86:ACME SUPPLY CO INVOICE 88104
:61:2607150715C7400,00NTRFPAYMENT//REF9932
:86:NORTHWIND LLC PAYMENT REF 2210
:62F:C260715USD54400,00

Every line starts with a colon, a tag number, and another colon. The tags always appear in the same order, and the whole statement is just that pattern repeating. Once you know what the seven tags mean, the file stops being cryptic.

What do the MT940 tags mean?

There are only a handful of tags you need to read a statement. Everything else in an MT940 is optional detail that most banks leave out.

How do you read tag 61 in an MT940 file?

Tag 61 is the transaction line and it is the densest part of the format, because six separate pieces of information are packed into one run of characters with no separators. Read it left to right: the six digit value date, an optional four digit entry date, a C or D mark for credit or debit, the amount with a comma as the decimal separator, a four character transaction type code, and then the bank's reference.

Take :61:2607150715D1250,00NTRFINV-88104//REF9931. The value date is 260715, meaning 15 July 2026. The entry date is 0715, the same day. D says this is money leaving the account. The amount is 1250,00, which in SWIFT notation means 1250.00. NTRF is the transaction type code for a transfer. INV-88104 is the customer reference and REF9931 after the double slash is the bank's own reference.

Two details here cause most of the trouble people hit. The decimal separator is a comma, not a period, so a naive import into US formatted software can read 1250,00 as the number 125000. And direction is that single C or D character rather than a plus or minus sign, which is why hand copied MT940 data so often shows every transaction as positive.

What is tag 86 used for?

Tag 86 carries the narrative for the transaction on the tag 61 line immediately above it. It is optional, but banks almost always populate it, and it is where the useful text lives: the counterparty name, a payment reference, sometimes an invoice number the payer typed into their remittance field.

SWIFT allows tag 86 up to six lines of 65 characters, which means a single description can be split across half a dozen rows in the file. Anything reading the statement has to join those lines back together, otherwise a reference like INVOICE 88104 gets cut in half at a line break. That narrative field is what makes automated matching possible at all, since it is the only place a bank credit tells you which customer it came from. Teams that do this matching at volume usually stop doing it in a spreadsheet and let software match incoming payments against open invoices automatically, but the reference has to survive the conversion first either way.

How do I open an MT940 file?

Any text editor opens an MT940, because it is plain text. Notepad, TextEdit, or VS Code will all display it. What you get is the raw tagged content shown above, which is fine for spot checking one transaction and useless for anything else.

To actually work with a statement you need it as columns. Convert it to Excel or CSV so the value date, description, and signed amount each sit in their own field, and then you can sort, filter, and total it like normal data. The MT940 converter does that in the browser, and exports it straight to Excel, CSV, or OFX with the column layout spelled out.

Do not try to shortcut it by renaming the file to .csv. There are no commas separating fields, so Excel drops the entire statement into column A. Fixed width import is not much better, because tag 61 subfields vary in length between banks, so column breaks that work on one statement break on the next.

Why can't Excel read MT940 directly?

Excel imports text that is either delimited by a character or arranged in fixed width columns. MT940 is neither. It is a tagged format where one logical transaction spans at least two physical lines, the :61: and the :86: that follows it, and where several values are concatenated inside a single field with no delimiter at all.

There is a second problem even if you get the lines split. MT940 dates are six digits in YYMMDD form, so 260715 arrives in Excel as the number 260,715 rather than a date. Sorting by that column puts rows in an order that looks plausible and is wrong. A real conversion writes proper date values into the cells.

MT940 compared to BAI2, OFX and CAMT.053

MT940 is one of several statement formats a finance team runs into, and the differences matter mostly for knowing which parser to reach for.

The direction of travel is toward CAMT.053, and many banks now offer both. MT940 is not going away quickly though, because a lot of corporate treasury infrastructure was built against it and rewriting that integration is rarely anyone's priority. If your bank offers both, take CAMT.053 for new work and keep an MT940 path for the accounts that still send it.

How do you check an MT940 conversion is complete?

There is one test, it takes ten seconds, and it catches nearly every conversion error. Take the opening balance from tag 60F, add the signed total of every converted transaction, and confirm the result equals the closing balance in tag 62F.

If it matches, nothing was dropped and no sign is reversed. If it is off, look at the size of the difference. A gap that is exactly twice one transaction amount means that transaction came through with the wrong sign, which points you straight at the row to fix. A gap equal to one transaction means a line was skipped entirely, usually because its tag 86 narrative confused a line based parser.

Run that check every time before the data goes anywhere that matters. Reconciliation built on an incomplete statement is worse than no reconciliation, because it looks finished.

Common MT940 problems and what causes them

A few failures come up over and over when people start working with these files.

Every amount is positive. The C or D mark in tag 61 was ignored. Direction is not a sign in this format.

Amounts are inflated by a hundred. The comma decimal separator was read as a thousands separator, turning 1250,00 into 125000.

Descriptions are truncated or shifted. Multi line tag 86 content was not joined, so continuation lines were either dropped or treated as separate transactions.

Dates sort wrong. The six digit YYMMDD dates came through as numbers instead of dates.

A statement is missing. Check the sequence in tag 28C. It increments per statement, so a gap tells you a day never arrived, which is easy to miss when files land automatically.

The short version

An MT940 is a SWIFT end of day statement in tagged plain text, with the account in tag 25, the opening and closing balances in 60F and 62F, one transaction per :61: line, and the readable narrative in the :86: beneath it. It is unusable as delivered and straightforward once parsed. Convert it to a spreadsheet, run the balance check, and it behaves like any other transaction data. If you need the statement inside personal finance software rather than a spreadsheet, exporting it as OFX is the path, since Quicken and MS Money have never read SWIFT files.