How to Validate a NACHA File Before Sending It to the Bank

Short answer: Validating a NACHA file means checking four things before the bank sees it: that every line is exactly 94 characters, that each header record has a matching control record, that the batch and file control totals equal the sum of the entries beneath them, and that the entry hash matches. Most rejected files fail on one of those four, not on anything exotic.

Last updated July 2026

A rejected ACH file is an expensive kind of mistake. Payroll misses a cycle, vendors call, and somebody spends an afternoon reading fixed-width text with a ruler. The frustrating part is that the vast majority of rejects come from a short list of structural problems you can check yourself in a few minutes, before the file ever leaves your building.

What does it mean to validate a NACHA file?

Validation is checking that a file is structurally correct and internally consistent against the NACHA format rules, before submitting it to your bank. It is not the same as checking that the payments are correct. A file can be perfectly valid and still pay the wrong vendor. Structural validation asks a narrower question: will the bank's system be able to read this file and will its own totals agree with themselves?

The four checks that catch most rejects

1. Every line is exactly 94 characters

NACHA's developer guide is unambiguous that an ACH file is fixed-width ASCII with each line exactly 94 characters. A line at 93 or 95 characters breaks the whole file, and the usual causes are mundane: a text editor that trimmed trailing spaces, a spreadsheet export that added a delimiter, or a file that picked up Windows line endings on its way through a system expecting Unix ones. Open the file, turn on a column indicator, and confirm the last character of a few lines lands on column 94.

2. Every header has its matching control record

The structure works like brackets. A type 1 file header opens the file and a type 9 file control closes it. Inside, each type 5 batch header is closed by a type 8 batch control. If a process appended batches or a file got concatenated, it is easy to end up with five batch headers and four batch controls. Count them. They must match exactly.

3. The control totals equal the entries

This is the check that catches real data problems rather than formatting ones. Each type 8 batch control record carries the entry and addenda count, the total debit amount, and the total credit amount for its batch. The type 9 file control carries the same figures for the whole file. Add up the amounts in your type 6 entry detail records and confirm they match. Remember that entry amounts are ten zero-filled digits with two implied decimals, so 0000012345 is $123.45, and a comparison done without dividing by 100 will look wrong when it is fine.

4. The entry hash matches

The entry hash is the least intuitive field and a common silent failure. It is the sum of positions 4 through 11 of every type 6 entry detail record, which is the eight digit receiving bank identifier, with only the rightmost 10 digits kept if the sum overflows. Batch control carries the hash for its batch and file control carries it for the file. If someone edited a routing number by hand and did not recompute the hash, the file will fail at the bank even though it looks fine to the eye.

Other things worth checking before you submit

• Blocking factor. ACH files are padded with lines of 9s so the total line count is a multiple of ten. If your line count is not divisible by ten, the padding is wrong or missing.
• Service class codes. 200 means the batch has mixed debits and credits, 220 means credits only, and 225 means debits only. A batch marked 220 that contains a debit is inconsistent.
• Trace numbers ascend. Within a batch, trace numbers should be unique and ascending. Duplicates usually mean two runs got merged.
• Effective entry date is a banking day. A date on a weekend or holiday will not settle when you expect it to.
• Company entry description. Since March 20, 2026, PPD credits paying wages or salaries must carry PAYROLL, and WEB debits for e-commerce purchases must carry PURCHASE. This field sits at positions 54 to 63 of the batch header and is now a real compliance check rather than free text.
• Prenotes are zero dollar. A prenotification entry, transaction code 23 or 28, should carry ten zeros in the amount field. A prenote with a real amount is a bug.

How do I check a NACHA file without special software?

The practical approach is to get the file into a spreadsheet so you can total columns instead of counting characters. That is harder than it sounds, because a NACHA file has six different record layouts sharing the same 94 columns, so a single fixed-width import scheme is wrong for most of the lines. Excel will also strip the leading zeros from routing, account, and trace numbers and can flip long account numbers into scientific notation, which corrupts exactly the fields you are trying to verify.

The faster route is to run the file through a NACHA file to Excel converter, which reads each record type correctly, restores the implied decimals, keeps the identifiers as text, and carries the batch details down onto each entry. Then your validation is ordinary spreadsheet work: sum the amount column, compare it to the control totals, and pivot by batch. If you would rather do it by hand, our walkthrough on how to open a NACHA ACH file in Excel covers the fixed-width and Power Query methods step by step.

What is a NACHA file validator?

A NACHA file validator is a tool that parses an ACH file and reports structural errors: wrong line lengths, unbalanced headers and controls, mismatched totals, bad hashes, and invalid codes. Banks usually run one on receipt, which is why you find out about problems after submission. Many ODFIs also publish their own file specification and a test facility, and using the bank's own test channel before a production run is the single best habit here, because the bank's parser is the one whose opinion counts.

Why did my bank reject my ACH file?

In practice the common causes cluster tightly. Line length is wrong somewhere in the file. Control totals do not tie because entries were added or removed after the totals were computed. The entry hash was not recalculated after an edit. Header and control records are unbalanced because files were concatenated. The immediate destination or origin routing values in the file header do not match what the bank expects for your setup. Or the effective entry date has already passed or falls on a non-banking day. Work through those six before assuming something deeper is wrong.

Should you edit a NACHA file by hand?

Try not to. Hand-editing is the most reliable way to create an invalid file, because almost every meaningful change has a knock-on effect: changing an amount breaks the batch and file totals, changing a routing number breaks the entry hash, and adding an entry breaks the counts and the blocking. If the source data is wrong, fix it in the system that generated the file and produce a new one. Use the converted spreadsheet to find and prove the problem, then regenerate rather than patch.

Building the check into a routine

For teams running payroll or vendor payments on a schedule, the useful version of this is a short standing checklist rather than a one-off investigation. Convert the file, sum the amounts by batch, compare against the control records, confirm the line count is a multiple of ten, and eyeball the entry descriptions and effective dates. It takes a few minutes and it catches the errors that otherwise surface as a phone call from your bank the next morning. Teams that also need to automate the approval trail behind those vendor payments usually end up wanting the same structured export anyway, so the conversion step pays for itself twice.

Once the file is validated and submitted, the reconciliation side picks up: the payments will land on your bank statement, and matching them back is much easier when both sides are already structured data. Our guide on bank statement reconciliation covers that half, and the bank file format converter explains how the ACH file relates to the BAI2 and MT940 statement files your bank sends back.