Decoding the MT940 Bank Statement for D365 Advanced Bank Reconciliation

While ISO 20022 CAMT.053 is rapidly becoming the gold standard for global banking communication, the classic SWIFT MT940 format remains a powerful and ubiquitous staple for automated bank reconciliation.

Understanding how to read an MT940 file—and how Dynamics 365 Finance interprets its structured tags—is an essential skill for any financial implementation team.

Unlike the highly nested XML structure of CAMT.053, MT940 is a "flat-file" standard established by SWIFT. It relies on sequential alphanumeric tags to denote fields. If a bank omits a mandatory tag or misformats a string, the D365 import process will likely fail.

Let's break down the core architecture of an MT940 statement and highlight the critical fields required for a seamless D365 Finance integration.

---

The Anatomy of an MT940 Statement

An MT940 file systematically structures its data into specific blocks marked by tags. A tag starts with a colon, followed by the tag number, and ends with another colon (e.g., :25:).

Here are the most critical tags you need to understand when configuring your D365 Bank Account Master and Advanced Bank Reconciliation Matching Rules:

1. Tag :20: - Transaction Reference Number (TRN)

• What it is: The unique reference number assigned to the statement message by the sender.
• D365 Impact: D365 uses this for internal tracking and duplicate prevention. If an MT940 file is imported twice, D365 checks this reference, alongside the statement date and number, to block duplicate imports.

2. Tag :25: - Account Identification [CRITICAL FOR MATCHING]

• What it is: This identifies your bank account. It is usually represented as the IBAN or the standard domestic bank account number.
• D365 Impact: This is arguably the most crucial tag for the import process. The standard D365 MT940 parser looks at Tag :25: to match the statement block to the internal D365 Bank Account.
• The Rule: The IBAN field or the Bank account number field on your D365 Bank Account Master must be an exact alphanumeric match to the contents of Tag :25:.

3. Tag :28C: - Statement Number / Sequence Number

• What it is: A progressive number that indicates the chronological sequence of the statements (e.g., 15/1 indicating Statement 15, page 1).
• D365 Impact: Helps D365 chronologically sequence the statement headers in the Advanced Bank Reconciliation worksheet.

4. Tags :60F: / :60M: - Opening Balance

• What it is: The opening balance of the account at the start of the statement period. F stands for First/Opening, M indicates an intermediate balance.
• Structure: It packs multiple data points into a single string. It starts with C (Credit) or D (Debit), followed by the Date (YYMMDD), Currency (EUR), and Amount (15000,00).
• D365 Impact: D365 uses the currency defined here to validate against the D365 Bank Account Master base currency. If the currencies clash, the import will be blocked. The opening balance is also verified mathematically against the sum of the transactions to authenticate the file.

5. Tag :61: - Statement Line (The Transaction details) [CRITICAL FOR MATCHING]

• What it is: The meat of the file. Every single financial transaction has its own Tag :61:.
• Structure Example: 61:2603310331CR1500,00NMSCNONREF
• Breakdown: Let's tear this string apart because it drives your D365 transaction lines:
  • 260331: Value date (YYMMDD) - March 31, 2026
  • 0331: Entry date (MMDD)
  • C / D / CR / RC: Credit or Debit indicators (R usually denotes a Reversal). This dictates whether D365 writes a positive or negative amount.
  • 1500,00: Transaction Amount.
  • NMSC: SWIFT Transaction Type Identifier Code (e.g., NMSC for Misc, NTRF for Transfer, NCHG for Charges).
  • NONREF: Bank Reference.
• D365 Impact: D365 Matching Rules heavily leverage the SWIFT Transaction Code (the 4 letters like NMSC). You can instruct D365: "If the line is a Debit and the Bank transaction code is NCHG, bypass the subledger and automatically post this to the Bank Fees General Ledger account."

6. Tag :86: - Information to Account Owner [CRITICAL FOR CLEARING]

• What it is: Directly follows a Tag :61: line. This is the Remittance Information block. It contains unformatted metadata regarding who paid you and why, like Invoice Numbers, Vendor Names, or payment descriptions.
• D365 Impact: This is the playground for D365 Advanced Bank Reconciliation's more complex features. Because the tag often contains a massive, unstructured string of text, you utilize Matching Rules to scan the :86: tag. If a customer paid Invoice INV-90921, the text INV-90921 will live inside this tag. D365 searches this block, pulls the invoice ID, and uses it to auto-settle the open Accounts Receivable balance.

7. Tags :62F: / :62M: - Closing Balance

• What it is: The ending check-figure. Functions identically to Tag :60F:.
• D365 Impact: D365 validates the imported data by taking the Opening Balance (:60F:), netting all the Tag :61: lines, and verifying that the final number perfectly matches Tag :62F:. If it's off by even a penny, the statement is typically flagged as structurally invalid and won't reconcile.

---

Summary

For D365 implementations, the MT940 format thrives in its standardized rigidity. Ensure that the Account Identification (Tag :25:) perfectly aligns with the IBAN in D365, and heavily utilize the SWIFT Action codes in Tag :61: and the dense text inside Tag :86: to automate your daily transaction matching.