MT940 bank statement format explained

MT940 is a plain-text message format, defined by SWIFT, that banks use to send an end-of-day account statement to a business customer's software. It is a business-banking feed. If you run a small business and bank through a normal online-banking login, you almost certainly do not have MT940 files and do not need them; your PDF statement and CSV download contain the same transactions. If someone has handed you an .sta or .txt file full of lines starting with colons and numbers, this guide explains what you are looking at and what to do with it.

What MT940 actually is

SWIFT is the network banks use to send each other standardised messages. Each message type has a number. MT940 is "Message Type 940", the Customer Statement Message: a bank telling an account holder what happened on an account during a period, usually one banking day. Its sibling MT942 is the intraday version, sent during the day with the transactions booked so far.

Originally these travelled over the SWIFT network itself, to corporates with their own SWIFT connection. Today most MT940 files never touch SWIFT. Banks generate them in the same format and deliver them through corporate banking portals, host-to-host connections or SFTP drops, and the customer's treasury system or ERP picks them up each morning.

Who uses it

Corporate treasury departments running dozens of accounts at several banks. ERP systems such as SAP and Microsoft Dynamics, which import MT940 in their bank reconciliation modules. Accounting packages built for the European corporate market, such as Exact Online and Twinfield, which have imported Dutch-bank MT940 files for years.

The common thread is a customer large enough to have an electronic reporting agreement with the bank. Retail and small-business online banking does not offer it, which is why a bookkeeper working with sole traders and small companies can go a whole career without seeing one.

What a file looks like

An MT940 message has a short header, a body of tagged fields, and a closing marker. The body is where the statement lives:

:20:STMT260630001
:25:GB29NWBK60161331926819
:28C:00126/001
:60F:C260629GBP14250,00
:61:2606300630D1200,00NTRFNONREF//BANKREF001
ACME SUPPLIES INVOICE 4471
:86:PAYMENT TO ACME SUPPLIES LTD
INV 4471
:61:2606300630C3500,00NTRFNONREF//BANKREF002
:86:RECEIPT FROM CLIENT B
:62F:C260630GBP16550,00
:64:C260630GBP16550,00

Each line begins with a tag in colons. A tag tells the reading software what the rest of the line means. Some tags appear once per statement, :61: and :86: repeat for each transaction.

The tags

Balances: :60F:, :62F:, :64: and :65:

All four balance tags share one layout: a one-letter mark, a date, a currency, an amount.

:60F:C260629GBP14250,00
     ││     │  │
     ││     │  └── amount, comma as decimal separator, no thousands separator
     ││     └── ISO 4217 currency code
     │└── date as YYMMDD
     └── C for a credit balance, D for a debit (overdrawn) balance

The :60F: of one day's statement should equal the :62F: of the previous day's. Treasury software checks that automatically, which is how a missing day's file gets noticed.

The statement line: :61:

This is the dense one. The subfields run together without separators, and their positions are fixed by the standard:

:61:2606300630D1200,00NTRFNONREF//BANKREF001
    │     │   ││      │   │       │
    │     │   ││      │   │       └── bank reference, after //
    │     │   ││      │   └── customer reference, 16 characters, NONREF when there is none
    │     │   ││      └── transaction type code, 4 characters
    │     │   │└── amount, comma as decimal separator
    │     │   └── debit/credit mark: D, C, or RD / RC for reversals
    │     └── entry (booking) date MMDD, optional
    └── value date YYMMDD

The four-character type code starts with S, N or F. S means the transaction came from a SWIFT message and the next three digits are that message type (S103 is a customer credit transfer). N means a non-SWIFT transaction with a three-letter code: NTRF for a transfer, NCHK for a cheque, NMSC for miscellaneous, NINT for interest, NCOM for commission. F is "first advice". Banks differ in how carefully they use these, so most software treats the code as a hint rather than a fact.

An optional supplementary line of up to 34 characters can follow directly under the :61: line, before the :86:. In the example above, ACME SUPPLIES INVOICE 4471 is that line.

The narrative: :86:

The counterparty's name, their account, the payment reference, the invoice number: everything a human would want to know goes here. The standard only says it is up to six lines of free text, and every bank fills it differently. German banks use a ?20, ?21, ?32 subfield scheme; Dutch banks use slash-delimited codes such as /NAME/ and /REMI/; others just dump the text as printed on the paper statement. A parser that handles ING's :86: will not necessarily handle Barclays', and this is where most MT940 integration effort goes.

Things that trip people up

• Decimal commas. 1200,00 is one thousand two hundred. There is never a thousands separator.
• Two-digit years. 260630 is 30 June 2026.
• Debit and credit describe your account. C on :60F: means you have money; C on a :61: means money came in.
• Multi-page statements. A long day's activity arrives as several messages with the same statement number and sequence numbers 001, 002, 003, joined by :62M: at the end of one and :60M: at the start of the next. Read them together or the balances will not chain.
• Bank dialects. A file that a bank calls MT940 may deviate in the :86: layout, the type codes or even the date handling. Bank-specific format guides exist for exactly this reason.

MT940 and camt.053

MT940's designated successor is camt.053, the Bank-to-Customer Statement in the ISO 20022 family. It is XML rather than tagged text, with separate structured elements for the counterparty name, address, account, the end-to-end reference and the remittance information, all of which MT940 crams into :86:. camt.052 replaces MT942 for intraday reporting.

The timeline is often misreported. SWIFT ended the coexistence period for cross-border interbank payment messages on 22 November 2025; after that date, bank-to-bank payment instructions on SWIFT are ISO 20022 only. That deadline did not switch off MT940 delivered from a bank to its own corporate customers. Those feeds run on each bank's own timetable. As of September 2026, a number of banks still offer MT940 and camt.053 side by side, some have announced retirement dates for MT940 reporting in 2027 or later, and others have not published a date. If you depend on an MT940 feed, the only reliable answer on when it stops is the one your bank gives you in writing.

If you have an MT940 file and just need the transactions

Three routes, in the order I would try them.

Ask whoever sent it for a different format. The bank that produced the MT940 also produces a PDF statement and, almost always, a CSV download of the same account. For a small business that needs the numbers in a spreadsheet, QuickBooks or Xero, the PDF or CSV is the better starting point anyway, because you can read it. The CSV guide covers what a good CSV looks like.

Import it into software that reads MT940 natively. If the file exists because a larger company's treasury or ERP system requested it, that system is the right place to open it. SAP, Dynamics 365 Business Central in several localisations, Exact Online and Twinfield all import MT940, subject to the bank dialect being one they recognise.

Convert the PDF instead. stmtai does not read MT940 or camt.053. It reads PDF statements, scanned images, and CSV, QIF and OFX exports, checks each file against the printed opening and closing balances, and exports Excel, CSV, QuickBooks .qbo or Xero CSV. The PDF statement for the same account reconciles to the same closing balance as the :62F: in the MT940, so nothing is lost by taking that route. For where those balances sit on the printed page, see how to read a bank statement.