NACHA is a fairly straight-forward process that is easily managed once
set up between a company and their bank. I am consistently surprised
with the misconceptions about this process. NACHA is a file format that
allows funds transfers from one banking institution to another. The
file goes through a "clearing house" which moves the funds from one bank
account to another with 24 hours. As an example, "Direct Deposit" uses
a NACHA formatted file to transfer money from a company's bank account
to the multiple bank accounts of its employees. When one looks more
closely, most of the Accounts Payable direct payments by banks are
nothing more than the bank printing a check and letting the check travel
through the previously tested, stable, and error free environment of the
banking system check-clearing system.
It is a long and arduous process for the banking system to process a
paper check. To pay a bill, a paper check needs to be issued and
delivered. This paper check would then need to be physically attached
to a deposit ticket for the recipient and taken to the bank. The bank
would run this check through their system and the MICR would be read and
funds would be transferred from the bank of the check to the bank of the
deposit. All of this time and effort (at the guts level of processing)
is bypassed via a NACHA formatted file, which makes NACHA a
significantly cheaper process.
As customers understand that a bank is overcharging for NACHA
processing, the price will come down. If the price doesn't come down
(the banks are a monopoly in this area), then customers will be trying
other methods of funds transfers, which are more insecure, unstable,
costly, and time-consuming.
Remember, if there are 5,000 item brought into billing, someone had to
write that check, mail or deliver it, it had to be posted by hand into
your system, attached to a deposit ticket, taken to the bank, the bank
has to process it, deliver it to a processing center, it's processed
there, and returned to the sending bank, where it is either scanned or
returned to the original issuer. All this is resolved by a single NACHA
file with 5,000 lines in it (well...maybe 5,008 lines). Why would the
first method be free to the bank but the second method cost $.35/line or
$1,750. From this perspective I'd think we would all be outraged with
those greedy bankers, who are not much more than puppets for the Feds
these days. :-)
...just a few thoughts. :-)
Bill
------------------------------------------------------------------------
----- Original Message -----
*From:* jvar...@soft-target-tech.com
*To:* 'U2 Users List' <u2-users@listserver.u2ug.org>
*Date:* 6/22/2012 11:06 AM
*Subject:* Re: [U2] ACH Functionality in ManFact
That's pretty much what we're doing here. I've talked to the bank and have
their specifications in hand.
Did you run into any issues while setting this up?
-----Original Message-----
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Mark Eastwood
Sent: Friday, June 22, 2012 12:38 PM
To: 'U2 Users List'
Subject: Re: [U2] ACH Functionality in ManFact
We don't use ManFact - but did it for Accounts Payable in our system
(instead of sending checks to vendors, transfer via ACH).
It's not too difficult - I would suggest you call your Bank and tell them
what you want to do (ours was BoA). They were very help with sending layouts
etc.
The only real 'pain' was when testing; they charged us a transaction fee for
every test - ouch.
Mark
-----Original Message-----
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of John Varney
Sent: Friday, June 22, 2012 8:07 AM
To: 'U2 Users List'
Subject: [U2] ACH Functionality in ManFact
I've been tasked with writing a bolt on module to give ManFact the ability
to utilize ACH processing. Has anyone done this already? If so, any words of
wisdom?
_______________________________________________
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
