Bank statement import fails in treasury-mgmt-SWIFT MT940 format parsing errors block reconciliation

Our bank statement imports are failing in SAP S/4HANA 1809 cash management module. The bank provides statements in MT940 format, but the import process consistently rejects files with format validation errors.

Error from transaction FF_5:


Error in line 47: Field separator expected
Statement date: 20250420
Transaction code: NMSC not recognized
Import terminated at record 47 of 203

We’ve been using the same MT940 format for years with our legacy system, and the bank confirmed their format hasn’t changed. The blocked reconciliation is causing delays in our daily cash position reporting. I’ve checked the format specification in transaction FEBP, and it appears to match the bank’s format. What could be causing the delimiter and transaction code recognition issues?

Before switching formats entirely, check if your bank’s MT940 includes field :61: with transaction codes that need delimiter corrections. Some banks concatenate codes without proper spacing, which causes parsing errors in S/4HANA’s stricter validation engine.

I’ve dealt with similar MT940 import issues after S/4HANA upgrades. The 1809 version introduced enhanced validation for SWIFT message formats. Your bank might be including supplementary information in field :86: (transaction details) that doesn’t follow the standard structure. SAP expects specific subfield delimiters within :86:. If the bank uses non-standard delimiters or exceeds the character limits, you’ll get field separator errors. Try importing just the first 20 transactions to isolate which specific field is causing the rejection.

Transaction code mapping is in OBBC for external transaction codes. You need to map NMSC to an internal SAP posting key. However, the field separator error is more critical - that’s stopping the import before it even gets to transaction code validation. MT940 format requires specific field tags like :20:, :25:, :60F:, etc. If your bank added custom fields or changed the tag sequence, SAP won’t recognize the structure. Compare your current MT940 file against the SAP MT940 specification document. Line 47 is likely where a non-standard field appears.

Have you considered using CAMT.053 format instead of MT940? Many banks now support the newer ISO 20022 standard, which has better structure and validation. S/4HANA handles CAMT.053 more reliably than MT940 in my experience.

I’ve successfully resolved this exact issue with MT940 imports in S/4HANA 1809. The problem stems from three areas that need systematic correction:

Bank Statement Format Validation: S/4HANA 1809 enforces strict MT940 SWIFT standards that legacy systems often ignored. Your error at line 47 indicates a structural issue. First, validate your MT940 file structure:


Check field :61: format:
:61:YYMMDD[MM]DD[CR/DR]amount[N]code//reference
Example: :61:2504200420C50000,00NMSC//REF123456

The field separator error occurs when the delimiter between amount and transaction code is missing or non-standard. Banks sometimes use custom delimiters that worked in legacy systems but fail S/4HANA validation.

Delimiter Correction: MT940 requires specific delimiters:

  • Fields start with : and end with CRLF (carriage return + line feed)
  • Subfields within :86: use // or ? as separators
  • Transaction codes in :61: must have exactly one N character before the code

Your bank’s NMSC code appears without proper delimiter. The correct format should be:

:61:2504200420C50000,00NMSС//reference If the bank file shows :61:2504200420C50000,00NMSC//reference` (missing the N prefix), that triggers the field separator error. Contact your bank to add the N qualifier, or create a pre-processing script to insert it.

Transaction Code Mapping: Once format issues are fixed, map NMSC in transaction OBBC:

  1. Go to OBBC (External Transaction Codes)
  2. Create entry: Bank Country + Bank Key + NMSC
  3. Map to internal posting key (likely 40 for debit, 50 for credit)
  4. Assign G/L account for automatic posting

For blocked reconciliation, also verify:

  • Bank account configuration in transaction FI12 includes correct MT940 algorithm
  • Account symbol in FEBP matches your bank’s statement structure
  • Field :25: in MT940 contains your SAP bank account ID exactly as configured

Format Specification Check: In FEBP, ensure your format variant includes:

  • Field structure matching your bank’s MT940 implementation
  • Character set encoding (UTF-8 vs. ISO-8859-1)
  • Line ending style (set to CRLF for Windows-generated files)

Testing Approach:

  1. Extract one day’s statement (20-30 transactions)
  2. Manually verify each :61: field has proper N prefix before transaction codes
  3. Import via FF_5 with detailed log enabled
  4. Check system log (SM21) for detailed parsing errors
  5. Once successful, process full statement files

The reason your legacy system worked is that older SAP versions had looser MT940 parsing that auto-corrected minor format deviations. S/4HANA 1809 requires exact SWIFT compliance. After implementing these corrections, your 203-transaction statements should import cleanly and enable automated reconciliation.