If your bank just rejected an ACH file, you are not alone. NACHA's fixed-format specification is unforgiving: a single error anywhere in the file causes the entire batch to be rejected. No partial processing, no automatic correction — just a rejection notice and a delay in your payments.
This guide covers the most common errors we see, what they look like, why they happen, and how to fix them so your file clears the next time.
Why Banks Reject Entire Files
The ACH network was designed for reliability at scale. Banks process hundreds of millions of transactions daily, and that volume demands strict, machine-readable formatting. When your file has an error, the bank's processing system cannot safely guess your intent — so it refuses the whole thing.
That is why validating your file before you send it matters so much. Once a file is rejected, you have to correct it, recreate it, and resubmit — which can push your payment date back by a full business day or more.
Error 1: Invalid Routing Number (Failed Checksum)
What it looks like
Your bank's error response says something like "Invalid ABA routing number" or "Routing number checksum failure" for one or more Entry Detail records.
Why it happens
Every U.S. bank routing number has a built-in checksum digit. The checksum is calculated from the first eight digits using a specific formula, and the ninth digit has to match the result. It is a validity check baked into the routing number itself.
Typos are the most common cause — transposing two digits, or accidentally entering a nine-digit account number in the routing field. Routing numbers also occasionally change when banks merge or rebrand.
How to fix it
Double-check every routing number in your file against a verified source, such as a voided check from the payee or the bank's official website. If you are managing a large vendor list, a routing number lookup API can catch stale numbers before they cause a rejection.
FiSTWorks validates routing number checksums automatically when you import or enter payment data, flagging any failures before you generate the file.
Error 2: Wrong Record Length (Not 94 Characters)
What it looks like
Errors like "Record length invalid," "Line too long," or "Expected 94-character record" on one or more lines.
Why it happens
Every record in a NACHA file — File Header, Batch Header, Entry Detail, Batch Control, File Control — must be exactly 94 characters wide. Fields are fixed-position, not delimited. If a record is 93 or 95 characters, the parser cannot read subsequent fields correctly.
This usually happens when someone manually edits a NACHA file in a text editor that auto-strips trailing spaces, or when an export script has a bug in its padding logic. Even a single missing space breaks the record.
How to fix it
Do not manually edit NACHA files in a text editor unless you are absolutely certain your editor preserves trailing spaces and does not insert line endings that add extra characters (Windows CRLF vs. Unix LF is a common culprit).
The safest approach is to regenerate the file from your source data using software that handles the padding rules correctly. If you are building a custom export, test your output with a NACHA validator before submitting to the bank.
Error 3: Batch Total Mismatch
What it looks like
"Batch debit total does not match," "Entry/addenda count incorrect," or similar errors pointing to the Batch Control record.
Why it happens
Each batch ends with a Batch Control record that summarizes the batch: total debit amount, total credit amount, and a count of entries. If those numbers do not exactly match the sum of the Entry Detail records in the batch, the file fails validation.
This can happen if you add or remove entries after the Batch Control was calculated, or if a rounding issue causes a penny-level discrepancy in the totals (amounts in NACHA files are expressed in cents as integers — there are no decimal points).
How to fix it
Regenerate the Batch Control record from scratch after finalizing your entry list. Never hand-edit totals or counts. If you are building a custom NACHA generator, make sure your amount fields are stored and summed as integers (cents), not floating-point numbers.
Error 4: Missing or Invalid SEC Code
What it looks like
"Invalid Standard Entry Class code," "Unsupported SEC code," or "SEC code not permitted for this account type."
Why it happens
Every ACH batch has a Standard Entry Class (SEC) code that identifies the type of transaction. Common codes include:
- PPD — Prearranged Payment and Deposit (consumer accounts)
- CCD — Corporate Credit or Debit (business accounts)
- CTX — Corporate Trade Exchange (business-to-business with addenda)
- WEB — Internet-initiated consumer debits
Using the wrong SEC code for your payment type — for example, using PPD for a business-to-business payment — can cause the receiving bank to reject the transaction. Some banks also restrict which SEC codes their origination agreement covers.
How to fix it
Confirm with your bank which SEC codes your origination agreement permits. For most small business vendor payments, CCD is correct. For payroll to employee personal accounts, PPD is standard. Check your bank's ACH origination agreement if you are unsure.
Error 5: Bad Effective Entry Date
What it looks like
"Effective entry date invalid," "Settlement date in the past," or "Date format error in Batch Header."
Why it happens
The Effective Entry Date in the Batch Header tells the ACH network when you want the payment to settle. It must be a valid calendar date in YYMMDD format and must be a future banking day — typically at least one business day out (two days for IAT transactions).
Common causes: submitting a file after your bank's same-day ACH cutoff, using the wrong date format, or not accounting for federal holidays when the ACH network does not process.
How to fix it
Always check your bank's ACH file submission cutoff time before sending. If you miss the window for a given effective date, update the date to the next valid banking day and regenerate the file. Federal Reserve holidays are published annually and should be on your radar if you are scheduling payments near holidays.
Error 6: Company ID Format Errors
What it looks like
"Invalid Company Identification," "Company ID must be 10 characters," or "Company ID does not match origination agreement."
Why it happens
The Company ID in the Batch Header is a 10-character field that identifies your business as the originator. It is typically your IRS Employer Identification Number (EIN) prefixed with a "1" (e.g., 1123456789), but your bank may assign a different value when they set up your ACH origination account.
If the Company ID in your file does not match what your bank has on file for your origination agreement, the file will be rejected.
How to fix it
Use exactly the Company ID your bank provided when they set up your ACH origination agreement — not your EIN. This value should be consistent across every file you send to that bank. If you are unsure what value to use, contact your bank's ACH department directly.
Error 7: File Padding Issues
What it looks like
"File block count incorrect," "File does not end on a 10-record boundary," or the file appears truncated or has extra blank lines.
Why it happens
NACHA files must be padded to a multiple of 10 records (a "block" of 940 characters). After the File Control record, the file is padded with rows of nines (999999...) until the total record count is divisible by 10. If the padding is missing, has the wrong character, or the block count in the File Control is off, the file fails.
This is another case where manual editing frequently causes problems. Deleting lines without recalculating the block count, or saving the file without ensuring the final padding rows are present, will produce this error.
How to fix it
Regenerate the file programmatically. If your NACHA-generating software correctly calculates the File Control record and appends padding automatically, you should never see this error. If you are getting it, the file generation logic has a bug in its padding or block-count calculation.
Validate Before You Send
The fastest way to avoid all of the above is to validate your NACHA file against the full specification before it ever leaves your computer. A good validator checks routing number checksums, record lengths, field formats, totals, SEC code validity, date logic, and padding in seconds.
FiSTWorks includes a free ACH Validator tool that runs all of these checks and returns plain-English error messages — not cryptic rejection codes. You can paste a file or upload it directly, and you will see exactly which record, which field, and what the problem is before you submit anything to your bank.
Catching errors locally is always faster than waiting for a bank rejection, investigating the error code, fixing the file, and resubmitting. For businesses running weekly or semi-monthly payment cycles, a single rejection can push a batch past a payment deadline.
Ready to Stop Fighting Your ACH Files?
If you are spending real time on NACHA file formatting, validation, and bank submissions every payment cycle, FiSTWorks is built for exactly that workflow. Import your payment data, let the validator catch any issues, and transmit directly to your bank via SFTP — all from one place.