web
You’re offline. This is a read only version of the page.
close
Skip to main content

Notifications

Announcements

No record found.

News and Announcements icon
Community site session details

Community site session details

Session Id :
Dynamics 365 Community / Forums / Microsoft Dynamics GP (Archived) / AP EFT ACH file not ac...
Microsoft Dynamics GP (Archived)

AP EFT ACH file not accepted by bank GP 2015

(0) ShareShare
ReportReport
Posted on by Richard Wheeler 75,848 Moderator

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

I have the same question (0)
  • L Vail Profile Picture
    L Vail 65,271 on at

    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

  • L Vail Profile Picture
    L Vail 65,271 on at

    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

  • Richard Wheeler Profile Picture
    Richard Wheeler 75,848 Moderator on at

    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.

  • Richard Wheeler Profile Picture
    Richard Wheeler 75,848 Moderator on at

    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.

  • Suggested answer
    Richard Wheeler Profile Picture
    Richard Wheeler 75,848 Moderator on at

    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.

  • L Vail Profile Picture
    L Vail 65,271 on at

    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

  • Rob Klaproth Profile Picture
    Rob Klaproth 1,730 on at

    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.

  • Rob Klaproth Profile Picture
    Rob Klaproth 1,730 on at

    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.  

  • RJarrell Profile Picture
    RJarrell 319 on at

    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?

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

Quick Links

Responsible AI policies

As AI tools become more common, we’re introducing a Responsible AI Use…

Neeraj Kumar – Community Spotlight

We are honored to recognize Neeraj Kumar as our Community Spotlight honoree for…

Congratulations to the November Top 10 Community Leaders!

These are the community rock stars!

Leaderboard > 🔒一 Microsoft Dynamics GP (Archived)

#1
Community Member Profile Picture

Community Member 2

#2
mtabor Profile Picture

mtabor 1

#2
Victoria Yudin Profile Picture

Victoria Yudin 1

Last 30 days Overall leaderboard

Featured topics

Product updates

Dynamics 365 release plans