Bank statement import in cash management fails with unexpected file format error after SWIFT MT940 integration setup

ERP Infor CloudSuite
, , , , , , , ,
1

We’re unable to import bank statements into cash management from our primary banking partner. The import process fails immediately with an “unexpected file format” error, even though we’re receiving standard SWIFT MT940 files that should be compatible with CloudSuite.

We’ve been using the same bank statement import configuration for six months without issues. Last week the bank notified us they upgraded their output system, and now our imports fail every time. When I compare the new MT940 files to our older successful imports, the structure looks identical to me, but clearly something changed that CloudSuite doesn’t recognize.

This is causing major reconciliation delays as we have five days of unprocessed bank statements piling up. The bank insists their MT940 output is standards-compliant, so I’m trying to figure out what specific format element CloudSuite is rejecting. Has anyone dealt with MT940 import failures after a bank system upgrade?

2

To fix this, go to Cash Management > Bank Statement Import > MT940 Configuration. Edit your bank’s import template and change the Field 86 parser from ‘Standard’ to ‘SEPA Extended’. This tells CloudSuite to expect and handle the additional SEPA reference subfields. You may also need to map the /EREF/ field to a custom field in your bank transaction table if you want to store that reference data.

3

Yes, absolutely. The /EREF/ subfield is the end-to-end reference per SEPA standards. If your MT940 import configuration in CloudSuite isn’t set to handle optional SEPA subfields, it will reject files containing them. You need to update your import template to recognize and parse SEPA-extended MT940 format, which includes /EREF/, /KREF/, /MREF/, and other reference fields.

4

Checked the line endings and encoding - file is ASCII with CRLF endings, same as before. But when I look closely at field 86, I notice the bank added a new subfield ‘/EREF/’ that wasn’t in the old format. Could that be causing the import to fail?

5

MT940 has variations even within the standard. Check the line ending characters first - some banks use CRLF while others use just LF. CloudSuite ICS 2022 is particular about line terminators in MT940 files. Also verify the character encoding - it should be ASCII, but some banks output in UTF-8 which can cause parsing issues.

6

Changed the parser to SEPA Extended and the import is working now! Processing the backlog of statements. Thanks for identifying the SEPA subfield issue!

7

Excellent outcome. Let me provide comprehensive guidance on all three aspects of your MT940 import challenge:

MT940 File Import Process: CloudSuite Cash Management processes SWIFT MT940 bank statements through a structured parsing pipeline. The system reads the file, validates the overall structure against MT940 specifications, parses each statement block (beginning balance, transactions, ending balance), extracts transaction details from field 86, and then matches transactions to open items for reconciliation.

Your import was failing at the field 86 parsing stage because the parser encountered subfield delimiters it wasn’t configured to handle. The import process is intentionally strict - if it can’t parse transaction details correctly, it rejects the entire file rather than risk importing incomplete or incorrect data that would compromise cash reconciliation accuracy.

Unexpected File Format Error: The “unexpected file format” error in this case was somewhat misleading. The file format was still valid MT940, but it used SEPA extensions that your import configuration wasn’t expecting. Specifically, your bank added these SEPA subfields to field 86:

/EREF/ = End-to-end reference (unique transaction identifier)

/KREF/ = Customer reference

/MREF/ = Mandate reference (for direct debits)

/SVWZ/ = SEPA purpose code

The standard MT940 parser in CloudSuite expects field 86 to contain unstructured text or simple key-value pairs. When it encountered the SEPA subfield delimiters (forward slashes), it couldn’t parse the structure correctly and rejected the file. The error message was generic because the parser detected structural elements it didn’t recognize, which it classified as “unexpected format.”

Bank Output Format Mismatch Resolution: Here’s the complete solution for handling SEPA-extended MT940 files:

Step 1: Update Import Configuration

Navigate to Cash Management > Bank Statement Import > Import Templates

Select your bank’s MT940 template

In the Field 86 Configuration section:

  • Change Parser Type from ‘Standard MT940’ to ‘SEPA Extended MT940’
  • Enable ‘Parse SEPA Subfields’
  • Add subfield mappings:
    • /EREF/ → Transaction Reference ID
    • /KREF/ → Customer Reference
    • /MREF/ → Mandate Reference
    • /SVWZ/ → Payment Purpose
    • /ABWA/ → Deviant Originator (if used by your bank)

Save the template configuration.

Step 2: Field Mapping

The SEPA subfields contain valuable reconciliation data. Map them to CloudSuite fields:

  • /EREF/ should map to the Transaction Reference field in cash management - this provides unique identifiers for matching payments to invoices
  • /KREF/ can map to Customer Reference or a custom field for tracking customer-provided payment references
  • /MREF/ is critical for direct debit reconciliation - map it to the Mandate ID field if you process SEPA direct debits
  • /SVWZ/ provides payment purpose text - map to the Transaction Description field

These mappings ensure all information from the bank statement is captured in CloudSuite for comprehensive reconciliation.

Step 3: Backward Compatibility

Your bank may continue sending SEPA-extended format going forward. To handle both old and new format files during any transition:

In the import template, enable ‘Allow Optional SEPA Subfields’

This setting makes the parser flexible - it will correctly process files with SEPA extensions but won’t fail if it encounters older files without them

This prevents future import failures if the bank sends mixed format files.

Step 4: Process Backlog

For your five days of failed imports:

  1. Go to Cash Management > Bank Statement Import > Failed Imports
  2. Select all failed imports from your bank (filter by Bank Code)
  3. Click ‘Reprocess with Updated Template’
  4. CloudSuite will re-import the files using your SEPA-extended parser configuration
  5. Verify the imports succeeded by checking Cash Management > Bank Transactions - you should see five days of transactions now loaded
  6. Run cash reconciliation for those dates to match the imported transactions

Step 5: Validation and Testing

Request sample files from your bank showing the full range of SEPA subfields they may include. Test your import configuration with these samples to ensure it handles all variations:

  • Payments with /EREF/ only
  • Direct debits with /EREF/, /MREF/, and /KREF/
  • International transfers with additional SEPA fields like /ABWA/ (deviant originator)

This proactive testing prevents future import failures when the bank uses different SEPA subfield combinations.

Best Practice for Bank Format Changes:

Establish a notification protocol with your banking partners. Request that they provide:

  • 30-day advance notice of any MT940 format changes
  • Sample output files in the new format before go-live
  • Documentation of any new fields or subfields being added

This allows you to update CloudSuite import configurations proactively rather than discovering format changes when live imports fail. Add this requirement to your bank service agreements if possible.

Also consider implementing import monitoring alerts in CloudSuite: set up a notification rule that triggers if bank statement imports fail for any bank account two days in a row. This provides early warning of format issues before they create significant reconciliation backlogs.