We have a client that we just set up EFT for Payables. We have chosen the NACHA format and have all the account numbers entered. Their bank is not accepting the file because the claim the Hash Total on the Batch Control Record is incorrect. Now I have checked the layout of other EFT files I have set up and they match. What is different is that in their example you can see the hash total is the sum of the routing numbers of the vendors being paid. In our other examples the hash total looks like a checksum value where you cannot simply add up routing numbers and type in a number. Has anyone else ever encountered this?
*This post is locked for comments
Hey Richard, I am dealing with the same thing. My company needs the settlement (box unchecked so just 1 total line for the settlement) and it is not calculating.
When you say that you had to reset the layout, did you mean you had to recreate the eft file format?
Well, isn't this just lovely how these e-banking things work. It turns out the routing number was right justified by default in GP instead of LEFT. This is fine when the routing number is a perfect 9 characters, but some of the routing numbers were only 8, so this was causing there to be a blank space in front of the routing number, and the checksum was failing. Changed it to left and re-generated the file, now it looks much better. Live and learn, always verify all of the justifications of all of the fields and compare it to what the bank tells you in their specs.
Well Richard and Leslie, it would seem I am having the same issue with GP2013R2. However, I never had the box checked that you refer to, so I am not sure why it's calculating my prenote hash incorrectly.
When we did our testing with about half a dozen vendors in the test company, the hash total was always correct. Now we are trying to send the prenote for all 90 vendors to the bank, and it's incorrectly calaculating the hash total. I thought about breaking it into smaller chunks, but there is no option for that in the window, the cutoff date just indicates send all prenotes again before this date.
So.. off to further troubleshoot. Maybe I can flag it in SQL in the EFT table that the prenote has not been sent for 6 vendors and see if the total comes out right. It says in GP 10 there was a bug, but according to the microsoft KB that bug was resolved in a service pack in 10.
Richard,
Thank you so much for letting us know the solution. I had a customer running with an auto settlement line on for over 10 years. All of a sudden the bank decided they didn't want that anymore and rejected our file. Of course, they didn't tell us what was wrong, but score another win for GP ingenuity.
Kind regards,
Leslie
I found what was the issue. Back when we were first setting this up we discovered that this bank required the auto settlement line be checked. We had adjusted the transit number on that line and had forgotten. I completely reset the layout and now we have a hash total that matches. Thanks.
They are running GP 2015 14.00.0898. I am going to try to update them to 14.00.0952. I am out of ideas.
This does not make any sense. I am looking at other clients of mine and their hash totals are correct. I look at this one and this is what I see:
12400005
02130709
-----------
14530714 is what the hash total should be but what is there is 14500125 on both the 8(Batch Control) and 9(File Control) records for the hash total. I cannot explain what is causing this difference.
Hi again,
I just looked up the official NACHA specs and they have this to say about the Hash totals:
"Hash totals are the sum of all transit routing numbers (first eight digits only) from
each entry detail record in the batch, truncated from the higher order if necessary"
Kind regards,
Leslie
Hi Richard,
I think the hash total is the sum of the first 8 digits of the routing number. Does that match up with anything you have?
Leslie
Stay up to date on forum activity by subscribing. You can also customize your in-app and email Notification settings across all subscriptions.
André Arnaud de Cal... 291,113 Super User 2024 Season 2
Martin Dráb 229,918 Most Valuable Professional
nmaenpaa 101,156