What Is the Entry Hash in a NACHA File? (And How to Calculate It)

Last updated July 2026.

The entry hash in a NACHA file is a checksum, not a dollar amount. It is the sum of the eight digit Receiving DFI Identification field from every entry detail record in the batch, with only the rightmost ten digits kept. Banks compare the hash they calculate against the one you wrote in the batch control and file control records, and a mismatch rejects the file.

It exists for one reason: to prove that no entry was added, removed or altered between the moment you built the file and the moment the bank received it. The dollar totals catch a changed amount. The entry count catches a missing line. The hash catches a changed routing number, which is the one corruption the other two controls would sail straight past.

How is the entry hash calculated?

Take positions 04 to 11 of every type 6 entry detail record in the batch. That is the Receiving DFI Identification, the first eight digits of the receiving bank's routing number. Add them together as plain integers. If the total runs longer than ten digits, drop the leading digits and keep only the rightmost ten. Write the result right justified and zero filled into positions 11 to 20 of the batch control record.

A worked example with three entries:

The sum is eight digits, shorter than ten, so nothing gets truncated. Zero fill it to ten characters and the batch control entry hash field reads 0021300008.

Truncation only bites on larger batches. Once you are past roughly a hundred entries the sum climbs past ten digits, and at that point you keep the last ten and throw the rest away. That feels wrong the first time you do it, but it is correct: the hash is deliberately a lossy fingerprint rather than a real total.

What about the file control entry hash?

The file control record at the bottom carries its own entry hash at positions 22 to 31. It is the sum of every batch level entry hash in the file, truncated the same way to ten digits. So you do not recalculate from the individual entries. You add up the batch hashes you already computed and truncate again.

This is the step that most homegrown ACH generators get wrong. They compute each batch hash correctly, then either sum the raw routing numbers a second time across the whole file, or they forget to truncate at the file level, and the file bounces with a control total error that gives no hint about which of the two hashes is bad.

How do I calculate the entry hash in Excel?

Once the entry detail records are in a sheet with the routing number in its own column, the calculation is one formula. If your Receiving DFI values sit in D2 through D200, this gives you the hash:

=RIGHT(REPT("0",10) & SUM(D2:D200), 10)

Padding with ten zeros before taking the rightmost ten characters handles both cases at once: short sums get zero filled and long sums get truncated, which is exactly what the spec asks for.

The trap is upstream of the formula. The Receiving DFI field is text in the file, and a large share of US routing numbers start with a zero. If that column came into Excel as a number, the leading zeros are already gone. The digits still sum the same way, so the hash comes out right, but the routing numbers themselves are now corrupt and the file you rebuild from that sheet will fail for a different reason. Import the column as text and use VALUE inside the SUM instead. Getting the fixed positions right in the first place is what the NACHA file format record layout reference is for.

Why did my bank reject the file for a bad entry hash?

Almost always one of five things:

• You summed the wrong field. The hash uses the eight digit Receiving DFI Identification only. The check digit at position 12 is not part of it. Including it inflates every entry by roughly a factor of ten.
• You forgot to truncate. An eleven or twelve digit sum will not fit the ten character field, and writing it in overflows into the neighboring dollar total.
• You truncated from the wrong end. Keep the rightmost ten digits, not the leftmost.
• The file hash was recomputed from entries rather than from batch hashes. These give the same answer on a single batch file, which is why the bug hides until the day you send two batches.
• An entry was edited after the totals were written. Someone opened the file to fix a name or an account number and saved it without regenerating the control records. Every control field is now stale, not just the hash.

That last one is the most common by a wide margin, and it is the reason banks treat the control records as a real security check rather than a formality. Editing a NACHA file by hand and sending it without rebuilding the totals is how a file that looks fine gets rejected. If you are opening the file to inspect it, work on a copy and leave the original alone, which is the whole argument for converting the ACH file to Excel for review rather than editing the text file in place.

Is the entry hash a security feature?

Partly. It is a data integrity check rather than a cryptographic one. A hash mismatch reliably tells you something changed, which is useful, but the calculation is public and simple enough that anyone altering a file on purpose can recompute it. That is why it sits alongside the message authentication code field in the batch control record and alongside whatever secure transmission channel your bank requires, rather than standing on its own.

Treat it as the accounting control it is: proof that the file the bank processed is arithmetically the same file you approved. Combined with the entry count and the separate debit and credit dollar totals, the three together make it very hard for a corrupted or truncated transmission to slip through unnoticed. The other checks worth running before release are covered in validating a NACHA file before sending it to the bank.

What does the entry hash tell me when I am reading someone else's file?

Recalculate it. If your total matches the hash written in the batch control record, the file you are holding is complete and unaltered, and you can trust the entry count and dollar totals sitting next to it. If it does not match, stop and go back to the sender before you reconcile anything against it, because you now have no idea which entries are missing or changed.

This matters most for anyone receiving ACH files rather than originating them: a service bureau taking payroll files from clients, an accountant reviewing what a bookkeeper submitted, or an auditor testing a population of vendor payments. The hash is the cheapest completeness test available, and it takes one formula. Teams processing a steady stream of vendor batches usually reach the point where the file review belongs in the payment workflow itself rather than in a spreadsheet, which is where accounts payable automation takes over the approval and release steps.

Where the hash sits in the record layout

Two places, and only two:

Neither the file header nor the batch header carries a hash, which makes sense: you cannot know the checksum until you have written every entry. The full position by position layout for all six record types, including the fields either side of the hash, is on the NACHA file format reference, and the practical route from a 94 character file to a spreadsheet is covered in how to open a NACHA ACH file in Excel.