Bank statement import API in cash management skips transactions with special characters

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

We’re importing daily bank statements into Cash Management via the REST API. The import runs successfully with a 200 response, but when we check the posted transactions, some are missing. After investigation, we found that transactions containing special characters in the description field (like €, £, or accented characters like é, ñ) are silently skipped.

Example API call:

POST /api/v1/cash/bank-statements
{
  "transactions": [
    {"amount": 1500.00, "description": "Payment from Société Générale"},
    {"amount": 2300.00, "description": "Invoice £2300 settled"}
  ]
}

The API returns success, but these transactions don’t appear in Cash Management. Transactions with plain ASCII descriptions import fine. Is this an input validation issue, a character encoding problem, or something with the API error handling? Our reconciliation reports are now unreliable because we can’t trust that all transactions were imported.

system 2

You’ve hit a known limitation in ICS 2021’s Cash Management API that involves all three areas you mentioned:

Input Validation: The API has an undocumented whitelist of allowed characters in the description field. It was designed for ASCII-only environments and rejects Unicode characters outside the Basic Latin block (U+0000 to U+007F). Characters like €, £, é, ñ fail validation but the validation error is suppressed in the response. This was fixed in ICS 2022 where:

  • The character whitelist was expanded to include Latin-1 Supplement (U+0080 to U+00FF)
  • Validation errors are now returned in a validationErrors array in the response

Character Encoding: Even with correct UTF-8 headers, ICS 2021 has a bug where the API gateway converts UTF-8 to ISO-8859-1 internally before validation. This mangles multi-byte UTF-8 characters. Your approach is correct, but the API doesn’t handle it properly.

Workaround for ICS 2021:

// Sanitize descriptions before API call
function sanitizeDescription(desc) {
  return desc
    .replace(/[€]/g, 'EUR')
    .replace(/[£]/g, 'GBP')
    .replace(/[é]/g, 'e')
    .replace(/[ñ]/g, 'n')
    .replace(/[^\x00-\x7F]/g, ''); // Remove non-ASCII
}

API Error Handling: The silent failure is the biggest issue. Implement these checks:

  1. Count transactions sent vs. transactions in the API response:
Response: {
  "status": "success",
  "transactionsProcessed": 45,
  "transactionsReceived": 50
}

If these don’t match, some were skipped.

  1. Query Cash Management after import to verify:

GET /api/v1/cash/bank-statements/{statementId}/transactions

Compare the returned transaction count with what you sent.

  1. Enable detailed API logging in Infor OS Gateway (Admin > API Gateway > Logging Level = DEBUG). This captures validation errors that aren’t returned in responses.

  2. Implement a reconciliation check:


// After import, verify all transactions posted
const sentTransactions = originalData.transactions.length;
const postedTransactions = apiResponse.transactionsProcessed;

if (sentTransactions !== postedTransactions) {
  // Query for missing transactions and log discrepancy
  const missingTxns = findMissing(originalData, apiResponse);
  logAlert('Transaction import incomplete', missingTxns);
}

For your immediate reconciliation problem, I recommend:

  • Apply the sanitization function to all descriptions before import
  • Keep a mapping of original vs. sanitized descriptions in your local database
  • After each import, query the posted transactions and compare counts
  • Generate a daily reconciliation report showing any discrepancies

Longer term, upgrade to ICS 2023-1 where this issue is fully resolved. The newer API properly handles UTF-8, returns detailed validation errors, and supports the full Unicode character set for transaction descriptions. We tested importing statements with descriptions in 15 different languages including Chinese and Arabic, and all processed correctly.

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

This is definitely a character encoding issue. Check what encoding you’re sending in the Content-Type header. The API expects UTF-8, but if you’re not explicitly setting it, your HTTP client might be defaulting to ISO-8859-1 or Windows-1252. Add Content-Type: application/json; charset=utf-8 to your request headers.

4

I’ve encountered this with ICS 2021 specifically. The API has a validation rule that rejects transactions with certain special characters, but instead of returning an error, it just silently drops them from the batch. This is a known issue that was supposedly fixed in ICS 2022. The workaround is to sanitize your input data before sending it - replace special characters with ASCII equivalents or remove them entirely.

5

We are setting UTF-8 in the Content-Type header, so that’s not it. The silent dropping is concerning - shouldn’t the API return an error or at least a warning in the response? How can we know which transactions were skipped?

7

The API response should include a warnings array even when the status is 200. Check if there’s a warnings or partialSuccess field in the response body. Sometimes it’s there but applications don’t parse it. If you’re logging the full response, look for a section that lists skipped transactions with reasons. That said, the ICS 2021 version had a bug where warnings weren’t always included.

8

Another thing to check - are you URL-encoding your JSON payload? Some HTTP clients automatically URL-encode the body, which can mangle special characters even if the original encoding was UTF-8. Make sure you’re sending the raw JSON body without additional encoding layers. Also, try logging the exact bytes being sent on the wire using a tool like Wireshark or Fiddler to verify the encoding is correct.

kavya_ninja 9

I’ve encountered this with ICS 2021 specifically.