Ask ten US business owners what ACH is and you'll get ten half-right answers. It's the plumbing behind direct deposit, most recurring bills, and a growing share of B2B payments, yet most people who use it every day couldn't tell you what happens between the moment they hit "pay" and the moment the money lands. If you're taking payments over the phone, that detail matters. ACH and cards settle very differently, cost very differently, and carry very different liability rules.
Here's what ACH processing actually looks like under the hood, what NACHA expects from you when you originate a debit, and where it fits alongside card payments and newer US rails like FedNow.
What ACH is, in plain English
The Automated Clearing House network is a batch-based electronic funds transfer system that connects nearly every bank and credit union in the United States. It's operated jointly by the Federal Reserve and The Clearing House, and governed by NACHA, the trade body that writes the rulebook. When you pay your utility bill from your checking account, when your employer direct-deposits your paycheck, when a SaaS vendor pulls its monthly subscription from your business account, that's ACH.
It's batch-based rather than real-time. Payments queue up during the day, get sorted into files, and settle in windows rather than instantly. That's the trade-off: ACH is cheap and ubiquitous, but it's not instant.
ODFI, RDFI, and the two-sided network
Every ACH transaction has two banks involved. The Originating Depository Financial Institution, or ODFI, is the bank that pushes the payment into the network on behalf of the originator. The Receiving Depository Financial Institution, or RDFI, is the bank that receives it for the consumer or business on the other end.
If you're a merchant taking an ACH debit, your processor's sponsor bank is the ODFI. Your customer's bank is the RDFI. Funds flow ODFI to Federal Reserve or TCH operator to RDFI, and NACHA rules sit over the top telling everyone what they can and can't do.
SEC codes: WEB, TEL, PPD, CCD
ACH transactions are tagged with a three-letter Standard Entry Class code that describes how the authorization was obtained. Get this wrong and you're out of compliance with the NACHA Operating Rules. The four you'll meet most often are WEB, TEL, PPD, and CCD.
WEB is for debits authorized over the internet. TEL is for debits authorized by phone, which is the one that matters if you're taking ACH payments on a sales or service call. PPD covers recurring consumer debits with a signed authorization on file, like a gym membership. CCD is for business-to-business debits. Each code has its own authorization language requirements and its own return windows, so your payment platform has to tag transactions correctly.
Same-day ACH and settlement windows
Traditional ACH settles next-day or two days out. Same-day ACH, introduced in phases since 2016, lets you hit three processing windows during the business day, with the latest cutoff at 4:45 PM ET for same-day settlement. The per-transaction limit on same-day ACH rose to $1 million in March 2022.
This matters because customers increasingly expect fast money. If you're collecting a high-value invoice over the phone and the customer wants confirmation the money's moved before close of business, same-day ACH gives you that. It costs a little more per transaction than standard ACH but still well under card rates.
Cost: why CFOs love ACH
A typical card-not-present transaction in the US costs the merchant 2.5% to 3.5% of the sale, plus a fixed per-transaction fee, plus assessments and gateway costs. On a $1,000 invoice that's $25 to $35 in card fees.
ACH typically runs between $0.20 and $1.50 per transaction, flat, regardless of size. On that same $1,000 invoice you might pay $0.50. For recurring B2B billing, insurance premiums, property management, or any industry where invoice sizes run high, ACH is an enormous margin lift. For a $10 coffee, cards still win.
Account validation: the 2021 WEB debit rule
Since March 2021, NACHA rules require originators of consumer WEB debits to use a "commercially reasonable" method to validate that the account being debited is actually a valid, open checking or savings account. That typically means running a pre-note, using a real-time account verification service, or checking against a known-good account database.
TEL debits don't have the same hard requirement, but the best-practice bar keeps rising. If you're originating phone-authorized ACH debits, assume your ODFI will push you toward some form of account validation within a year or two if they haven't already.
Returns and failure codes
Unlike cards, ACH debits can come back days after they're authorized. The RDFI has up to two banking days to return most entries, and up to 60 days for unauthorized consumer debits. Return codes you'll see often include R01 (insufficient funds), R02 (account closed), R03 (no account or unable to locate), R07 (authorization revoked), and R10 (customer says the debit was not authorized).
R10 is the one that bites. It's essentially the ACH equivalent of a card chargeback, and Regulation E gives consumers 60 days from the statement date to dispute an unauthorized debit. Your defense is the authorization record, so if you're taking TEL debits, record and retain the call or keep a written authorization.
Reg E liability on the consumer side
12 CFR Part 1005, known as Regulation E, is the federal rule that protects consumers on electronic transfers. It sets liability caps for unauthorized transfers and timelines for reporting. For businesses originating ACH, the practical effect is that you need a clean authorization and a fast way to handle disputes, because the consumer's bank is going to side with the consumer if you can't produce evidence.
When ACH beats cards, and when it doesn't
ACH wins on high-ticket invoices, recurring B2B billing, and anywhere the customer already has a bank account relationship with you. It loses on speed of confirmation, on chargeback-style reversals that take days to surface, and on low-value one-off payments where the processing fee is a rounding error anyway.
A lot of our US customers run both. Cards for quick one-time sales, ACH for contract renewals and big invoices. If you're building a phone payment workflow, giving the customer a choice on the call and capturing the right one in the right rail is where the savings come from. For the wider picture on what US compliance expects from payment calls, the TCPA rules around payment calls are worth reading alongside this.
How Paytia handles ACH on the phone
On Paytia's US platform, ACH sits alongside card payments as an option the agent can offer during the call. The customer hears a secure prompt, keys in their routing and account numbers on their own phone keypad, and our system masks those digits from the agent and the call recording, exactly the same way we handle card payments with DTMF suppression. The authorization record gets stored with the call, the SEC code is set correctly for a TEL debit, and the transaction drops into the same settlement reporting as your cards.
If you're already taking phone payments and your average ticket is north of $200, running the numbers on ACH is usually worth an afternoon. The fee savings often pay for the whole platform inside a quarter.
Practical things that trip people up
A few details we see catch new ACH originators out. Routing numbers aren't all created equal: the nine-digit ABA on a check is for wire and ACH both, but some banks use different numbers for each, and if you ingest a wire RTN for an ACH origination the transaction returns R13 or R28. Ask for the ACH routing number specifically, and validate the first two digits against the Federal Reserve district codes (01 through 12) before submitting the file.
Descriptor text matters more than people think. The company name that shows on the consumer's statement comes from the Company Name field in the ACH batch header, and it has to match what the consumer agreed to when they authorized the debit. Mismatch between descriptor and authorization is one of the most common grounds for an R10 unauthorized return. Keep the descriptor stable and recognizable.
Finally, don't chase failed debits blindly. NACHA rules put an absolute cap on the number of retry attempts per authorization: three total, including the original, and only for R01 and R09 return reasons (insufficient funds and uncollected funds). If you retry on other return codes or hammer the account beyond three attempts, you're out of rule and the consumer's bank has grounds to return everything. Our ACH payment glossary entry has the full retry logic laid out.
