Bank statement import fails in cash management due to missing transaction code mapping

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

We’re experiencing failures with our daily bank statement import process in Cash Management. The import job runs but consistently fails when it encounters certain transaction codes from our bank’s BAI2 format files.

The error log shows ‘Transaction code mapping not found’ for codes like 165, 475, and 195. Our import job configuration seems correct, and we’ve verified the file format matches the template. The bank transaction code mapping table appears incomplete for these newer transaction types our bank recently introduced.

This is blocking our daily reconciliation process and creating a backlog of unprocessed statements. Has anyone dealt with similar transaction code mapping issues? What’s the proper way to add custom bank transaction codes to the mapping configuration?

system 2

I’ll provide a comprehensive solution covering all three focus areas:

Bank Transaction Code Mapping: Navigate to Cash Management > Setup > Bank Transaction Codes. For each missing code (165, 475, 195), create entries with these critical fields:

  • Bank Code: Enter the exact code from your BAI2 file
  • Transaction Type: DEBIT or CREDIT based on bank documentation
  • Description: Clear business meaning (e.g., “Incoming Wire Transfer”)
  • CloudSuite Transaction Type: Map to internal types (WIRE_IN, ACH_CREDIT, etc.)
  • Reconciliation Method: MANUAL for high-value (165), AUTO for routine (475, 195)
  • Default GL Account: Specify clearing accounts for each type

Import Job Configuration: Review your import job settings in Cash Management > Import Jobs > [Your Job Name]:


ErrorHandling=SKIP_INVALID_ROWS
ValidationLevel=TRANSACTION_CODE_REQUIRED
LogDetail=VERBOSE

Change from FAIL_ON_ERROR to SKIP_INVALID_ROWS to process valid transactions while logging issues. Enable VERBOSE logging temporarily to capture detailed validation failures.

Error Log Analysis: Access the import history: Cash Management > Jobs > Import History. For each failed import:

  1. Export the detailed error log (CSV format available)
  2. Filter for ‘Transaction code mapping not found’ errors
  3. Cross-reference with your bank’s BAI2 code documentation
  4. Identify patterns - are these all new codes or sporadic?

After adding the transaction codes, run a test import with a small sample file containing these codes. Verify each code processes correctly and posts to the expected GL accounts. Monitor the first few production runs to ensure reconciliation rules trigger appropriately.

For the three specific codes:

  • 165 (Wire Transfer In): Map to WIRE_IN type, manual reconciliation, 1100-WIRE-CLEARING account
  • 475 (ACH Credit): Map to ACH_CREDIT type, auto-reconciliation with invoice matching, 1150-ACH-CLEARING account
  • 195 (Bank Fee): Map to BANK_FEE type, auto-post, 5100-BANK-CHARGES expense account

Test with historical statement files before resuming daily imports. This approach resolved our backlog within two business days.

This draft is based on general Infor CloudSuite knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.

3

I’ve seen this before. The transaction code mapping table in Cash Management needs to be updated manually for new bank codes. Check your bank’s BAI2 documentation for what those codes represent - 165 is typically wire transfers, 475 could be ACH credits. You’ll need to map them to the appropriate CloudSuite transaction types in the configuration.

4

We had this exact issue last year when our bank updated their transaction code structure. The problem isn’t just adding the codes - you need to ensure they’re mapped to the correct GL accounts and reconciliation rules.

Go to Cash Management Setup > Bank Transaction Codes and add entries for each missing code. Make sure to specify:

  • Transaction type (debit/credit)
  • Reconciliation behavior (auto-match or manual review)
  • Default offset account

Also check your import job’s error handling settings. Sometimes the job is configured to fail completely on any unmapped code rather than skipping and logging.

nikhildata 5

Confirmed this resolves BAI2 import failures in CloudSuite Cash Management — mapping codes 165, 475, and 195 with correct DEBIT/CREDIT types and AUTO/MANUAL reconciliation cleared all errors instantly.

6

Thanks for the guidance. I found the Bank Transaction Codes setup, but I’m unclear on the reconciliation behavior settings. Should codes like 165 (wire transfers) be set to auto-match or manual review? We want to balance automation with control.

7

For wire transfers (165) and similar high-value transactions, I’d recommend manual review initially. ACH credits (475) can usually be auto-matched if you have good invoice matching rules configured.

Here’s a sample configuration entry:


BankCode=165
Type=CREDIT
Reconciliation=MANUAL_REVIEW
OffsetAccount=1100-WIRE-CLEARING

The key is understanding your bank’s specific code definitions. BAI2 codes can vary slightly between institutions.

8

Also worth checking if your import template version matches your CloudSuite version. ICS 2021 had some changes to how transaction codes are validated during import. The error log analysis should show the exact validation that’s failing - look for entries with ‘VALIDATION_ERROR’ in the import job history.