Sage 100

ACH...Is that really just merely a text file with about 6 fields or is there more to creating an ACH solution than that?

Yep! Fixed length fields and sometimes a few more than 6 plus one or two header records depending on the bank. I've done several in Crystal. See how I do it in the attachment.

Not really. The problem is different thinks in those fields.

The banks have lots of different requirements.

We built a custom ACH generation routine in Sage 500 for a client with a large volume of who customers pay automatically via ACH. Bills are sent on the 5th of the month and on the 10th of the month, the client processes an ACH file to automatically withdraw funds from client accounts. Sage has a similar process through SPS but they charge a percentage of the transaction as a fee. The dollars involved paid for a $75,000 project in 3 months. Attached is the documentation the requirements we used in creating a NACHA format file for processing in the US. Some banks may have additional information they want included in the front of top of the file for preprocessing. We find that alot in processing ACH for payroll. However, the core format is the same across the entire United States. Canada uses a different format known as CPA. I have that definition as well if you need to process for Canadian banks. There is a third format for most international processing. I don't have my notes in front of me on those details but it wasn't cost effective to purse the various options for this client. I hope this helps.

Please excuse me. I attached the wron file. Please use this one instead.

Thanks Sent from my Samsung Galaxy S3

And there is typically Header Detail Footer

Actually Wayne, a properly composed file has: file header, group header, details records, group footer, file footer. We have found that with small rural or local banks, these files are forwarded onto Region Federal Depositories for processing. They can be very strick on complaince. Larger banks like HSBC process them internally and exercise their own specifics for certain columns in each section. The sections and the control total calculations are pretty firmly enforced in most cases. An improperly formed file will get rejected more often than not. At lease that's the case based on our experience.

I've found it cheaper to tell the customer to take the ""sure thing"" and buy an ACH add-in. It's only going to take one rejected submission until you are losing money redesigning their file layout (assuming they have not given you an unlimited budget, etc)

I agree with Wayne. Many moons ago, we crated a couple ACH PR files for clients for about half the cost that Sage wanted. And everytime someone gets a new workstation or employee, we have to put our thinking caps on to reconfigure. Files still work great after 10 years, but maintaining them (when necessary) is tedious. It is great that the vendor ACH is included. The PR ACH SHOULD be, but this is Sage and the extra grand that they squeeze seems to be worth it for them.

Are we talking about something other than the built-in ACH features in Sage 100 or 500 here? (for AP?) I haven't run into a situation yet where the NACHA file formats can't be met by the ACH functionality.

I believe Mark was asking about creating the solution as opposed to buying the ACH add-in sold by sage since it appeared simple.

Sent from my Samsung Galaxy S3

There is no purchase in Sage 4.4 + or 500 7.3 + (for AP)

In 100 and 500, Sage has a solution for AP. I believe they still charge a transaction fee based upon a percentage of the dollar amount of each transfer. However, most of the time, this isn't a significant cost. I agree with Wayne, reinventing the wheel is not the best way to go. If you can use a tested solution, take it. Also, I believe Kevin Martin at Martin and Associates wrote a custom solution in 100 for a customer in the past to process automated AR collections through ACH. I don't know that the 100 interface with SPS covers the AR side of the house like it does in 500. If you have recurring billings and can get a customer to sign up like your utility, it's an efficient way to reduce days open is AR. In our case, the client was processing $2 to $3 million in ACH transactions per month. The average transaction was about $250,000. Paying 1 to 2% of the transaction amount as a processing fee was not ecomonically the right way to go. Thus why we went to the trouble of writing something custom.

The banks charge a processing fee for ACH transactions but Sage is not involved in the middle. The ACH file is directly upload to the bank by logging into the bank's site.

In the case of Sage SPS and Sage 500 in 2010, SPS created the file and transmitted it directly to the federal reserve for processing. They did not have an option for creating a NACHA format file for submitting directly to you bank. At least they didn't on the AR side of the house at that time. Thus their reasoning for why the charged the fee.

yes - AR is a different animal.