How to Use the Mt940 Validator: Step-by-Step Tutorial

This tutorial walks you through using the Mt940 Validator to check MT940 SWIFT bank statement files for structural and format errors. You will learn how to load a file, read each category of validation result, understand what the errors mean, and take action to fix them. No software installation is required — the entire process runs in your browser.

If you are new to MT940 and want to understand the format before validating, read the Complete Guide to Mt940 Validating first. This tutorial assumes you have an MT940 file ready and want to validate it now.

Connect on LinkedIn →

Step 1: Open the Mt940 Validator

Navigate to dataconversioncenter.com/developer-tools/mt940-validator/. The tool loads entirely in your browser — no login, no account, and no file upload to any server. Your MT940 data, which may contain sensitive account numbers and financial transaction details, never leaves your machine.

The page displays a drag-and-drop file zone at the top and a validate button. The results area is initially empty and will populate after you run a validation.

Step 2: Load Your MT940 File

You have two options for loading your file:

Option A — Drag and drop: Drag your MT940 file from your file manager directly onto the drop zone on the page. The zone will highlight when a file is dragged over it. Release to load the file.

Option B — Browse: Click the "Browse" link or button inside the drop zone to open a standard file picker. Navigate to your MT940 file and select it.

After loading, the tool displays the filename and file size. MT940 files are typically plain-text files with the extension .mt940, .sta, .txt, or sometimes no extension at all. The validator accepts any file — it reads the content directly rather than relying on the file extension.

Tip: If your bank provides MT940 files as a zip archive, extract the file first and then load the extracted .sta or .mt940 file.

Step 3: Click Validate

With a file loaded, click the Validate button. The validator reads the file content, parses all statement blocks, and runs the complete set of checks. For typical MT940 files — even those with many transactions — this completes in under a second.

The results area populates immediately with the validation output. If the file is valid, you will see a green status banner. If there are errors, the banner is red. Warnings appear in amber.

Step 4: Read the Summary Panel

The summary panel at the top of the results shows the high-level outcome:

• Status: VALID, INVALID, or VALID WITH WARNINGS. A file is INVALID if any mandatory tag is missing or if balance reconciliation fails. It is VALID WITH WARNINGS if the structure is correct but optional checks or advisory items were flagged.
• Statement blocks found: The number of individual account statements parsed from the file. A single MT940 file may contain one or multiple blocks.
• Total transactions: The count of :61: statement line tags across all blocks.
• Errors / Warnings: The count of each category. Click a count to jump to that section of the results.

If the summary shows zero errors and zero warnings, your file is structurally valid and ready for import. You can stop here. If errors or warnings are present, continue through the following steps to understand and fix them.

Step 5: Review Mandatory Tag Checks

The mandatory tag section lists the result for each required tag in each statement block:

• :20: Transaction Reference — Present or missing. A missing :20: means the file cannot be identified as an MT940 statement.
• :25: Account Identification — Present or missing. This is the account number, typically an IBAN.
• :28C: Statement/Sequence Number — Present or missing, and whether the format nnnnn/nnnnn is correct.
• :60F/:60M: Opening Balance — Present or missing, and whether the format (debit/credit indicator, YYMMDD date, ISO currency code, comma-decimal amount) is valid.
• :62F/:62M: Closing Balance — Same format checks as opening balance.

Each result shows PASS or FAIL with the specific issue on failures. For example: :28C: FAIL — format does not match nnnnn/nnnnn pattern. This tells you exactly which tag and which format rule was violated.

Action: For any FAIL item, open your MT940 file in a text editor and locate the flagged tag. Compare it against the expected format shown in the error message. Most tag failures are either missing tags or minor formatting issues like a wrong separator character.

Step 6: Review Balance Reconciliation

The balance reconciliation section shows whether the closing balance matches the opening balance plus the net of all transactions. This is the most important business-level check.

The validator displays:

• Opening balance: The value parsed from the :60F: or :60M: tag, with its debit/credit indicator.
• Net transaction movement: The sum of all :61: amounts, with credits positive and debits negative.
• Expected closing balance: Opening balance adjusted by net movement.
• Actual closing balance: The value parsed from the :62F: or :62M: tag.
• Difference: The gap between expected and actual. Zero means the file reconciles correctly.

If the difference is non-zero, the most common causes are:

1. A transaction line with the wrong debit/credit indicator — a credit recorded as D instead of C shifts the running total by double the transaction amount.
2. A missing :61: transaction — a transaction that should appear in the statement is absent from the file.
3. A decimal point used instead of a comma in one or more transaction amounts — for example, 500.00 parsed as 50000 rather than 500.00 depending on the parser.

Action: Note the difference amount. Look for a transaction in your source data whose value is exactly half the difference (if caused by a wrong indicator) or exactly equal to the difference (if caused by a missing transaction or decimal error). Correct the specific line and re-validate.

Step 7: Review Transaction Line Results

The transaction line section reports the result for each :61: statement line individually. Each row shows the line content and the result of format checks:

• Value date: Must be a valid YYMMDD date.
• Debit/credit indicator: Must be C, D, RC, or RD. Case-sensitive — lowercase is invalid.
• Amount: Must contain only digits and a single comma as the decimal separator. No currency symbol, no spaces, no period.
• SWIFT transaction code: The four-character code following the amount (e.g., NTRF, NCHK, NRTI). Must be present and recognized.
• Reference: The reference field following the transaction code. Checked for length and character set compliance.

Lines that pass all checks show a green indicator. Lines with errors show the specific failing element and what was found vs. what was expected.

Common transaction line errors and fixes:

• Invalid debit/credit indicator 'c' — Change lowercase c to uppercase C.
• Amount contains period character — Replace the period with a comma: 1500.00 → 1500,00.
• Missing SWIFT transaction code — The four-character code after the amount is absent. Add the appropriate code for the transaction type.
• Value date is not a valid date — Check that the six digits form a valid YYMMDD date. Month values above 12 or day values above 31 indicate a transposition error.

Step 8: Review Field Format Checks

Beyond the mandatory tags and transaction lines, the validator checks field-level formatting rules across the entire file:

• :20: reference character set — The reference must use only characters from the SWIFT character set. Curly braces, backslashes, and some special characters are not allowed.
• :25: account identifier length — Must not exceed 35 characters including any currency code suffix.
• :86: narrative lines — Information to account owner lines following :61: are checked for character set compliance and line length (maximum 65 characters per line).
• File encoding — The validator detects non-ASCII characters that may indicate encoding problems. MT940 should be ASCII or ISO-8859-1; multi-byte UTF-8 characters in field values are flagged.
• Line endings — Mixed CRLF and LF line endings are reported as a warning. This does not cause parsing failures in most systems but can affect line-by-line processing tools.

Field format issues are typically warnings rather than errors unless they affect a mandatory field. Warnings do not prevent import but may cause issues with strict receiving systems.

Action: For encoding warnings, open the file in a text editor that shows encoding information (such as Notepad++ or VS Code) and re-save as UTF-8 without BOM or as ISO-8859-1, replacing any non-ASCII characters with their ASCII equivalents where possible.

Step 9: Fix Errors and Re-validate

After reviewing the validation results, open your MT940 file in a plain text editor. Do not use a word processor such as Microsoft Word — it will add formatting characters that corrupt the file. Use Notepad, Notepad++, VS Code, TextEdit (in plain text mode), or any other plain-text editor.

Work through the errors systematically, starting with mandatory tag failures (Step 5) before addressing balance reconciliation (Step 6) and then individual transaction line errors (Step 7). Fixing a mandatory tag failure first ensures that subsequent checks run on a complete file structure.

After making corrections, save the file and return to the Mt940 Validator. Load the corrected file using either the drag-and-drop zone or the browse button, and click Validate again. Repeat until the summary shows VALID or VALID WITH WARNINGS with no remaining errors.

Tip: If you are correcting a file generated by a bank system, document each change made so that you can report the issue to the bank or the generating system. Production MT940 files should not require manual correction — a recurring format error indicates a bug in the generating system.

Step 10: Practical Examples

Here are three real-world scenarios and how to handle them with the validator:

Scenario A: File from a new bank integration

You have connected a new bank account to your treasury system and received the first MT940 file via SFTP. Before importing it into your TMS, you validate it. The validator reports: :28C: FAIL — value is "00001" (no slash separator)".

The bank's SFTP export is omitting the sequence number separator. Open the file, find :28C:00001, and correct it to :28C:00001/001. Re-validate. If the file now shows VALID, import it and report the format issue to the bank for correction in subsequent exports.

Scenario B: Balance reconciliation mismatch of exactly double a transaction amount

The validator reports the closing balance differs from the expected value by €2,400.00. You have a transaction for €1,200.00 in the file. This is the double-amount pattern indicating a wrong debit/credit indicator. Find the :61: line for €1,200.00 and check whether C should be D or vice versa. Correct the indicator, re-validate, and confirm the reconciliation now passes.

Scenario C: File validates correctly but your ERP rejects it

The validator shows VALID but your SAP or Oracle system rejects the import. This typically means the receiving system has stricter requirements than the base MT940 standard — for example, it may require specific SWIFT transaction codes, enforce line length limits on :86: fields, or require a specific account number format in :25:. Check the ERP documentation for its MT940 import requirements and run the validator again with those specific constraints in mind. Field format warnings in the validator output (Step 8) are often the source of ERP-level rejections.