Bank statement import fails with file format error after SFTP transfer

Our bank statement imports started failing yesterday with a cryptic file format error. The really strange part is that the exact same file passes all validation checks when we upload it directly through the UI, but fails when it comes through our automated SFTP process.

The error message says “Invalid file format - line endings not recognized” but we haven’t changed anything in our import template or SFTP configuration. The bank sends us the same BAI2 format file they’ve been sending for months.

Here’s what the validation shows:


File: bank_stmt_20250417.bai
Validation: PASSED
Format: BAI2
Records: 847

But after SFTP transfer:


Import Error: Line ending format invalid
Expected: CRLF
Found: Mixed

This is blocking our daily bank reconciliation process. Anyone seen file corruption during SFTP transfer before?

You can configure the import utility to normalize line endings before processing. Go to Financial Management > Bank Reconciliation > Import Configuration. There’s a preprocessing option called ‘Normalize Line Endings’ that should be enabled for SFTP imports. This tells CloudSuite to convert all line endings to CRLF before parsing, regardless of what comes through SFTP.

Let me address all three aspects of your issue with a comprehensive solution:

First, regarding why the file passes validation before upload but fails after SFTP transfer: The validation you’re running is checking the file format structure (BAI2 compliance, record counts, field formats) but not the byte-level encoding details like line endings. When you upload manually through the UI, CloudSuite receives the file directly from your browser with its original line endings intact. The SFTP process, however, is modifying the file in transit.

Second, why it fails only after SFTP transfer: Your SFTP server is configured for ASCII transfer mode, which automatically converts line endings based on the operating system. Since your bank sends files from a Windows system (CRLF line endings) and your SFTP server is Linux-based, the transfer mode converts some but not all line endings to LF (Unix style). This creates mixed line endings in the file - some records have CRLF, others have just LF. CloudSuite’s BAI2 parser requires consistent line endings throughout the entire file for proper record delimiting.

Third, the solution without changing your import template: You have two options that don’t require modifying the template or your SFTP configuration:

Option A (Recommended): Enable preprocessing in CloudSuite. Navigate to Financial Management > Bank Reconciliation > Import Profiles. Edit your bank statement import profile and expand the Advanced Options section. Enable ‘Preprocess File’ and select ‘Normalize Line Endings to CRLF’. This tells the import utility to scan the entire file and standardize all line endings before parsing begins. Add this preprocessing rule:


preprocess.lineEndings=CRLF
preprocess.encoding=UTF-8

Option B: Create an intermediate processing step. On your SFTP server, set up a file watcher script that runs immediately after the bank file arrives but before CloudSuite’s scheduled import picks it up. The script should normalize line endings:

#!/bin/bash
dos2unix -n input.bai temp.bai
unix2dos -n temp.bai output.bai

This converts to Unix format then back to Windows format, ensuring consistent CRLF throughout. Point your CloudSuite import job to the output.bai file instead of the original.

I recommend Option A because it’s configuration-only and doesn’t require scripting or additional dependencies. After enabling preprocessing, test with tomorrow’s bank statement file. The import should succeed through SFTP just as it does with manual upload, and your daily bank reconciliation process will resume normally.

Another option is to add a preprocessing script on the SFTP server. Create a simple bash script that runs dos2unix or unix2dos on the file after it arrives but before CloudSuite picks it up. This way you control the line endings without changing the SFTP transfer mode.

I’ve dealt with this exact issue. The problem is usually that SFTP in ASCII mode converts line endings based on the server OS. If your SFTP server is Linux and the file originates from Windows, it tries to be helpful by converting CRLF to LF. But CloudSuite’s BAI2 parser expects consistent line endings throughout the file. When you upload manually through the UI, it bypasses SFTP entirely, which is why that works. Check your SFTP server configuration file for the transfer mode setting.

Check your SFTP transfer mode. If it’s set to ASCII mode, it can modify line endings during transfer. Switch to BINARY mode to preserve the exact file format.

I checked with our IT team and they confirmed the SFTP is in ASCII mode. They’re hesitant to change it to binary because other file transfers depend on the line ending conversion. Is there a way to make CloudSuite handle mixed line endings, or do we need to convince IT to create a separate SFTP endpoint?