An MT940 file is a stack of colon tags, not a table. Amounts use a comma for the decimal, dates are six digits, and the whole description sits inside tag 86. Upload the file and BankXLSX reads the tag 61 statement lines into dated rows with amount, debit or credit, reference, and the balances either side. Start free, no credit card.
Upload your bank statement
Drop file here or click to upload
PDF, JPG, PNG, BMP, HEIC, TIFF, MT940
Uploading...
MT940 was designed for bank to bank messaging in an era when every byte on the wire cost money. That compactness is exactly what makes it unreadable in a spreadsheet.
Every line starts with a colon tag such as :20:, :61:, or :86: instead of sitting in a field, so Excel drops the whole file into one column with no structure at all.
A single transaction is a tag 61 line followed by one or more tag 86 lines, so the record you want is split across rows before you even start.
MT940 amounts use a comma as the decimal separator, so 1250,00 lands in a US Excel install as text or as the wrong number entirely.
Value dates are YYMMDD with no separators, and the entry date is an optional four digit MMDD, so Excel reads 260315 as an ordinary number.
The counterparty, the payment reference, and the bank's own description are all compressed into the free text of tag 86, which wraps across lines.
Direction is a C or a D mark inside the tag 61 line rather than a sign or a separate column, so nothing totals correctly until it is decoded.
Upload the MT940 or MT942 file and the converter reads the tag structure for you, pairing each statement line with its description and writing the result as ordinary spreadsheet rows.
Each statement line lands as its own row with value date, entry date, amount, debit or credit, transaction type code, and references in separate columns.
The wrapped description lines are stitched back together and attached to the transaction they belong to, so nothing is orphaned.
European style amounts like 1250,00 are converted to real numbers so your columns total correctly in a US Excel install.
Opening and closing balances from tags 60F, 60M, 62F, and 62M are lifted into clear fields you can reconcile against.
Download a real .xlsx workbook for analysis or a clean CSV mapped for QuickBooks, NetSuite, SAP, or your treasury system.
256-bit encryption in transit and you can delete your uploaded files whenever you want.
No software to install and no credit card to start.
Banks deliver MT940 as plain text, often named .sta, .mt940, or .txt. If yours is not .txt, rename the copy so the uploader accepts it.
Tip: Renaming does not change the data.
Drag the file into the box above. The converter reads the tag 61 statement lines, their tag 86 descriptions, and the balance tags around them.
Tip: MT942 interim reports work too.
Save as XLSX or CSV, then check the row total against the closing balance in tag 62F.
Tip: A matching balance proves nothing was dropped.
MT940 is the SWIFT end of day statement. In the US it turns up wherever a company banks internationally or runs a treasury workstation, so the people converting it are usually managing cash across borders or feeding an ERP.
Build a multi bank cash position when one bank sends MT940, another BAI2, and a third camt.053.
Handle statements from European and Asian bank accounts, where MT940 is still the common delivery format.
Inspect and map real MT940 files during an SAP, NetSuite, or treasury system implementation.
Reconcile foreign bank activity to the ledger using the opening and closing balances in the file.
Get a complete transaction population from a statement file rather than a stack of PDFs.
Look at real tag 61 and tag 86 content while building a parser or an integration.
MT940 is the SWIFT Customer Statement Message, the end of day statement a bank sends for an account. It is plain text built from numbered tags in a fixed order rather than columns, which is why it does not open as a table. Each file gives you a statement reference, the account it covers, an opening balance, a list of transactions, and a closing balance. If you open a file and see lines beginning :20:, :60F:, :61:, and :62F:, you are looking at an MT940.
The tags always appear in the same order, and once you know six of them you can read most of any file. Here is what each one carries.
| Tag | Name | What it carries |
|---|---|---|
| :20: | Transaction reference | The bank's reference for this statement message. |
| :25: | Account identification | The account the statement covers, often IBAN or account plus currency. |
| :28C: | Statement number | Statement number and sequence number, used to spot a missing day. |
| :60F: | Opening balance | Final opening balance. :60M: is used instead when the statement continues. |
| :61: | Statement line | One transaction: dates, debit or credit mark, amount, type code, references. |
| :86: | Information to account owner | Free text description for the transaction above, often wrapped over lines. |
| :62F: | Closing balance | Final closing balance. :62M: marks an intermediate closing balance. |
| :64: | Closing available balance | Funds actually available, which can differ from the ledger balance. |
| :65: | Forward available balance | Optional. Available balance on a future value date. |
Tag 61 is where the actual transaction lives, and it packs six or seven pieces of data into a single line with no separators. Reading it left to right, this is the order.
| Subfield | Format | Notes |
|---|---|---|
| Value date | YYMMDD | Six digits, no separators. The date the money counts from. |
| Entry date | MMDD, optional | Booking date. Some banks leave it blank or send spaces. |
| Debit or credit mark | C, D, RC, or RD | RC and RD mark reversals of a credit or a debit. |
| Funds code | 1 character, optional | Usually the third character of the currency code. |
| Amount | Up to 15 characters | Comma as the decimal separator and no thousands separator. |
| Transaction type code | 4 characters | A letter then three characters, such as NTRF or NCHK. |
| Customer reference | Up to 16 characters | Your reference, where the bank passes one back. |
| Bank reference | Prefixed // | Optional. The bank's own reference for the entry. |
The four character transaction type code is the closest thing MT940 has to a category, and the first letter tells you where the entry came from. N marks a non-SWIFT transfer, S marks a SWIFT transfer where the following three characters are the message number, so S103 is an MT103, and F marks a first advice raised by the bank itself. Codes confirmed in published bank tables include NTRF for a transfer, NMSC for miscellaneous, NCHK for a cheque, NINT for interest, NCOM for commission, and NFEX for foreign exchange. Other codes such as NDDT and NSTO are defined in the standard but appear less consistently in practice. Banks genuinely do use proprietary codes here, so confirm anything unusual against your own bank's MT940 implementation guide rather than assuming a universal list.
MT940 is the end of day customer statement: a final, complete record of a closed banking day with an opening balance in tag 60F and a closing balance in tag 62F. MT942 is the Interim Transaction Report, sent one or more times during the day so a treasury team can see activity as it happens. The important structural difference is that an MT942 carries no opening or closing balance tags at all. Instead it uses tag 34F for the floor limit, meaning the minimum transaction amount being reported, and tags 90D and 90C for the count and sum of debit and credit entries. It covers only the period since the last report, which is why you reconcile against the MT940 and use the MT942 for intraday cash positioning. Both use the same colon tag style, so the same converter handles them: for the interim report on its own, the MT942 to Excel converter spells out the 34F floor limit and the 90D and 90C totals.
It is being replaced, but slower than most summaries suggest, and the distinction matters if you are planning a migration. SWIFT ended the MT and ISO 20022 coexistence period for cross border payment messages on November 22, 2025, when MT103 and MT202 were retired. That deadline did not apply to the MT9xx reporting messages. MT940 is deprecated and no longer actively maintained, but it has not been withdrawn from the network, and banks are still sending it in 2026. There is no announced hard sunset date for the statement messages, and banks are migrating clients to camt.053 on their own timelines running into 2027 and beyond. Some regions are moving faster: MT940 and MT942 stopped being a German Banking Association standard in November 2025.
In SWIFT's mapping, MT940 and MT950 correspond to camt.053, MT942 corresponds to camt.052, and MT900 and MT910 correspond to camt.054. The real reason to move is reconciliation quality rather than the deadline: MT940 compresses the counterparty, payment reference, and description into the free text of tag 86, so your ERP has to parse it with pattern matching, while camt.053 gives remittance information, the transaction code, and the credit or debit direction their own named elements. Until your banks switch, expect to handle both. Our guides on camt.053 versus MT940 and choosing between MT940, BAI2, and camt.053 go deeper.
This is the question that usually decides whether you need to convert at all, and the answer splits cleanly. SAP handles MT940 as a standard electronic bank statement format and distinguishes structured from unstructured tag 86 variants. Oracle Fusion Cloud ERP ships parsers for BAI2, SWIFT MT940, EDIFACT FINSTA, camt.052, and camt.053. Microsoft Dynamics 365 Finance states plainly that it supports three bank statement formats out of the box: ISO 20022, MT940, and BAI2.
NetSuite is the notable exception. Its default bank statement parsers cover BAI2, camt.053, CSV, OFX, and QFX, and MT940 is not among them. NetSuite's own documentation points users toward third-party conversion for other formats. If you are on NetSuite and a bank sends you MT940, converting the file to CSV is the supported path rather than a workaround, and the NetSuite bank statement converter covers what that importer expects.
| System | Reads MT940 natively? |
|---|---|
| SAP | Yes, as a standard electronic bank statement format. |
| Oracle Fusion Cloud ERP | Yes, alongside BAI2, camt.052, and camt.053. |
| Dynamics 365 Finance | Yes, one of three formats supported out of the box. |
| NetSuite | No. Default parsers are BAI2, camt.053, CSV, OFX, and QFX. |
Once the statement lines are rows, the rest is ordinary spreadsheet work. If your bank also sends an interim report, see our walkthrough on how to convert an MT942 file to CSV or Excel. For other bank file types, the BAI to Excel converter handles North American balance reporting, the camt.053 to Excel converter handles ISO 20022 XML, and the NACHA file to Excel converter handles ACH payment files. Not sure which one you have? The bank file format converter compares them side by side. Loading the data onward, map it through the OFX converter or the QuickBooks QBO format, or go straight to the SAP and NetSuite converter pages. If all you were given is the PDF statement, the main bank statement converter produces the same rows.
Converting is rarely the last step. If the destination is QuickBooks Online, a CSV to QBO converter turns the export into a file QuickBooks accepts. Teams that need reporting on top of the converted data can build it with an AI financial statement generator, and finance teams handling other document types at volume can extract them with enterprise document OCR.
An MT940 is the SWIFT Customer Statement Message, the end of day bank statement for an account. It is plain text made of colon tags in a fixed order carrying a statement reference, the account, an opening balance, the transactions, and a closing balance. It is built for software, so it needs converting before Excel can use it.
Rename the file to .txt if it has an extension like .sta or .mt940, upload it to BankXLSX, and download the result as XLSX or CSV. The converter reads each tag 61 statement line into a row, attaches its tag 86 description, and converts the comma decimals into real numbers.
You can open it as text, but it will not be usable. Every line lands in one column, a single transaction is split across a tag 61 line and its tag 86 description, amounts use a comma decimal that US Excel misreads, and dates are six digit numbers. Convert it first to get real rows.
MT940 is the end of day statement with a final closing balance, and MT942 is an interim transaction report sent during the day covering activity since the last report. Use MT940 to reconcile a closed day and MT942 for intraday cash positioning. Both share the same tag structure.
Tag 61 is the statement line, one per transaction. It packs the value date as YYMMDD, an optional MMDD entry date, a debit or credit mark, an optional funds code, the amount with a comma decimal, a four character transaction type code, and customer and bank references into one line.
Tag 86 is the information to account owner field, the free text description for the transaction on the tag 61 line above it. It usually holds the counterparty name, the payment reference, and the bank's own wording, all compressed together and often wrapped across several lines.
Yes. SWIFT ended MT and ISO 20022 coexistence for cross border payment messages in November 2025, but that did not cover the MT9xx reporting messages. MT940 is deprecated and no longer actively maintained, yet banks are still sending it and no hard sunset date has been announced for the statement messages. Banks are migrating clients to camt.053 on their own timelines into 2027 and beyond.
MT940 follows the European convention of a comma as the decimal separator with no thousands separator, so 1250,00 means one thousand two hundred fifty. A US Excel install reads that as text or as the wrong number, which is why amounts have to be converted rather than imported raw.
Convert the MT942 intraday interim report.
Compare every bank file format side by side.
Convert ISO 20022 camt.053 XML statements.
Convert BAI and BAI2 balance reporting files.
From the same family of tools
Get started converting bank statements to spreadsheets.
USD
per month
billed as
$288 yearly
Choose speed vs accuracy when extracting
| Base AI Faster | 2,500 pages |
| Pro AI Best accuracy | 500 pages |
Scale statement conversion across your team with automation.
USD
per month
billed as
$888 yearly
Choose speed vs accuracy when extracting
| Base AI Faster | 10,000 pages |
| Pro AI Best accuracy | 2,000 pages |
Enterprise-grade bank statement conversion and controls.
USD
per month
billed as
$ yearly
Choose speed vs accuracy when extracting
| Base AI Faster | pages |
| Pro AI Best accuracy | pages |
