To validate a NACHA file, confirm that every record is 94 characters, the record types run 1-5-6-8-9 with every batch opened and closed, each routing number passes its check digit, and the batch and file control totals (entry count, entry hash, debit and credit amounts, block count) equal what the detail records add up to. Then check the business rules: SEC codes, transaction codes, effective dates and company IDs. A validator does all of this in seconds; by hand it takes an hour per file and still misses things.
What "validating" a NACHA file means
Your bank's ACH system reads a NACHA file by column position, not by field name. If a line is one character short, every field after the gap shifts and the whole file is rejected. Validation is the step where you prove the file is readable and internally consistent before the bank tries to read it. It is not the same as approving the payments: validation says "this file is well formed," not "this money should move."
There are two layers. Format checks confirm the file obeys the NACHA record layouts. Business-rule checks confirm the contents make sense: a payroll batch is not coded as a debit, the effective date is a banking day, the company ID matches the one your bank assigned. Banks reject on both.
The 12-point checklist
Work through these in order. The first six are format checks you can do by eye on a small file; the rest need arithmetic or reference data.
- Every line is exactly 94 characters. Trailing spaces count. An editor that trims them, or saves with a different line ending, breaks the file silently.
- Record types are in order. The file opens with a 1 record and closes with a 9 record. Every 5 (batch header) has a matching 8 (batch control). Entry records (6) and addenda (7) sit between them.
- The file is padded to a multiple of ten lines. After the 9 record, rows of nines fill out the last block, and the block count in the 9 record matches.
- Required fields are filled. Immediate destination and origin, company name, company ID, SEC code, effective date, and the receiving account number and name on every entry.
- Reserved and blank fields are actually blank. Stray characters in a reserved position are a common hand-editing error.
- Dates parse. Creation date and effective entry date are YYMMDD, and the effective date is a banking day, not a weekend or Federal Reserve holiday.
- Every routing number passes the check digit. The ninth digit is calculated from the first eight. A typo almost always fails this test. The ODFI routing prefix in the batch header and the trace numbers must also agree.
- Entry counts match. The batch control's entry and addenda count equals the number of 6 and 7 records in that batch, and the file control's count equals the sum of the batches.
- Entry hashes match. Add up the first eight digits of every receiving routing number in the batch, keep the last ten digits, and compare with the batch control. The file control carries the sum of the batch hashes.
- Debit and credit totals match. The batch control's debit and credit totals equal the sum of the entry amounts by transaction code, and the file control carries the sum of the batches. Amounts are in cents, so a floating-point rounding error shows up here.
- SEC code, service class and transaction codes agree. A batch with service class 220 (credits only) cannot contain a 27 debit. PPD and CCD entries carry at most one addenda record; CTX requires addenda; a prenote carries a zero amount and a live entry does not.
- Company ID and trace numbers are consistent. The company ID in the batch header matches the batch control and is the one your bank issued. Trace numbers start with your ODFI's routing prefix and increase through the batch. No two entries share a trace number.
Validating by hand versus with a tool
By hand, checks 1 through 6 take a few minutes on a file with a handful of entries if you open it in an editor with word wrap off and a column ruler. Checks 7 through 12 mean recomputing check digits, hashes and totals for every entry, which is an hour of careful work on a 50-entry file and error-prone enough that people skip it. The bank does not skip it.
A validator runs all twelve in seconds and names the record and field that failed. The free ACH Validator does exactly that with no account required: drop the file on the page and read the results. It reports errors (the bank will reject), warnings (the bank may question) and informational notes, in plain English rather than codes. It does not move money, submit the file to your bank, or confirm that an account exists or has funds; those stay with you and your bank.
If the file fails
Fix the source, not the file. Hand-editing a NACHA file to patch one field usually breaks a total or a count somewhere else (checks 8 through 10 are where those surface). Regenerate the file from your payment data with the correction made, then validate again. If the error message is unfamiliar, Common ACH File Errors and How to Fix Them walks through the seven most frequent ones.
After validation
A clean validation means the bank can read the file. Upload it through your bank's portal or send it over SFTP before the bank's cutoff for your effective date, and keep the validated copy with your payment records. If you create files regularly, ACH Drafter builds them already validated from a recipient list, so the checklist becomes a confirmation rather than a hunt.