An ACH payment is an electronic bank-to-bank transfer that moves money between two US bank accounts over the Automated Clearing House network. If you're a US business processing recurring billing, payroll, vendor payouts, or B2B invoices, ACH is somewhere between 10 and 30 times cheaper than card payments — yet most companies still default to cards because that's what their checkout already supports.
The interesting bit isn't the cost. It's that the gap between ACH economics and ACH adoption isn't a pricing problem — it's a checkout-friction problem. ACH needs a bank account and routing number, neither of which fits cleanly into a card-shaped form field, and absolutely doesn't fit into a phone call where the customer is reading numbers aloud into a recorded line. This post walks through how ACH actually works, the return codes that bite the businesses running it, and how we handle ACH capture on the phone at Paytia.
What is an ACH payment?#
The Automated Clearing House network is a US batch-processing system for moving money between bank accounts. It's run jointly by the Federal Reserve (FedACH) and The Clearing House (EPN), governed by rules written by NACHA — the National Automated Clearing House Association. The network's been around since 1974, and it's not slowing down: NACHA reported 32.6 billion payments across the network in 2024, worth roughly $86 trillion.
An ACH payment isn't a card payment with a different label. There's no card network involved — no Visa, no Mastercard, no interchange fees. It's also not a wire transfer. Wires move money between banks one transaction at a time, settle the same day, and cost $15-$35 per transfer. ACH batches thousands of transactions together, sweeps them several times a day, and costs cents.
If you've ever been paid by direct deposit, paid a utility bill by autopay, or had Netflix charge your checking account instead of your card, that was ACH. It's the rail almost every recurring US payment runs on, and most people who use it daily don't know its name.
How ACH actually moves money#
The flow is more involved than card payments, and the timing surprises people who haven't worked with it before. Here's what happens when a US business debits a customer's account.
The customer authorizes the debit — verbally on a recorded call, in writing, or via a web form (the authorization channel matters for NACHA dispute rules, more on that in a moment). The business sends the transaction to its bank, the Originating Depository Financial Institution (ODFI). The ODFI batches that transaction with thousands of others and hands the batch to an ACH operator, either FedACH or EPN. The operator routes each transaction to the customer's bank, the Receiving Depository Financial Institution (RDFI). The RDFI debits the customer's account, the funds settle between the two banks via the Fed, and the business sees money in its account.
The whole process takes one to three business days for standard ACH. Same-Day ACH is available if both banks support it and the transaction is submitted before the operator's same-day window (currently three windows a day, with a operators accept files until 4:45 pm ET, settling by 6:00 pm ET — but your bank's cutoff is usually earlier (2:00–3:30 pm ET)). Same-Day ACH costs the originator a small per-transaction surcharge and caps individual transactions at $1 million, but it's a real option for businesses that need ACH speed without the cost of a wire.
One detail that catches people out: ACH is a batch system. Money doesn't move continuously. The Fed sweeps batches several times a day, and a transaction submitted at 11 am doesn't leave the originating bank until the next batch window. If you're building a product that promises "instant" anything on top of ACH, read the operating windows first — you're building on a rail that wasn't designed for instant.
Want to see this working in your setup? Book a working-demo call — we'll wire up your actual phone system and show you a live capture.
ACH credit vs ACH debit#
ACH transactions come in two flavors, and the distinction matters more than people expect. An ACH credit pushes money from the sender's account to the receiver's. Payroll is the classic example — your employer originates an ACH credit for $X and the network pushes it into your checking account. Vendor payments work the same way: you push money to your supplier.
An ACH debit pulls money from a different account into yours. Subscription billing, utility autopay, gym memberships, B2B recurring invoicing — all ACH debits. The receiver originates the transaction; the sender's bank releases the funds.
Why does the direction matter? Two reasons. First, the authorization rules are different. An ACH debit needs explicit consumer authorization with specific language NACHA defines, retained for two years after the last debit. An ACH credit you originate from your own account doesn't carry the same consent burden — you're moving your own money out. Second, the dispute window for an unauthorized consumer debit is 60 days, which is long, and the burden of proof sits with the originator. That's the rule we'll come back to under R10 below.
NACHA classifies ACH entries by Standard Entry Class (SEC) code. A few you'll see often: PPD covers consumer prearranged payments and deposits (payroll, recurring bills with a signed authorization). WEB covers debits authorized over the internet. TEL covers debits authorized by phone. CCD covers business-to-business transactions. If you're capturing ACH payments by phone, you're originating TEL entries, and TEL has its own retention and verification rules — your processor will handle the SEC code mechanics, but you need to know yours is TEL because the rules differ from WEB.
ACH return codes and what they mean#
This is where the rubber meets the road. ACH transactions fail, and they fail in specific, codified ways. NACHA defines over 80 return codes; here are the ones that actually show up in a US business's return file.
R01, insufficient funds, is the workhorse — typically around half of all returns. The customer's account doesn't have enough money to cover the debit. You can retry once or twice within NACHA's reinitiation rules; after that you stop, or you'll start tripping return-rate thresholds.
R02, account closed. The account exists on paper but the customer shut it down. You can't reinitiate; you need to contact the customer.
R03, no account or unable to locate account. The routing number is valid but no account at that bank matches the number you gave. Almost always a data-entry error.
R04, invalid account number. Either the format is wrong or the account doesn't exist. Again, data-entry territory — and a reason to validate account numbers at capture rather than discovering the problem three days later.
R07, authorization revoked. The customer told their bank they no longer authorize you to debit them. The bank passed that revocation through ACH. Don't retry.
R10, customer advises not authorized. This is the expensive one. The customer told their bank the debit was never authorized in the first place. NACHA treats this as the ACH equivalent of a chargeback, the funds are reversed, and the burden is on you to produce the authorization on file. If your return rate for R10 (and the related R05, R07, R29, R51) exceeds 0.5% of total debit volume over a rolling 60-day window, NACHA's Risk Management framework requires your originating bank to put you on a remediation plan or unwind you from the network. Card processors call this a "high chargeback ratio." Same idea, different name.
The point isn't to memorize every code — your processor's dashboard will surface them. The point is that ACH returns aren't free, your aggregate return rate is a compliance metric, and "the customer changed their mind" is an expensive way to find out you didn't capture authorization cleanly the first time.
ACH vs cards vs FedNow vs RTP#
This is the comparison most US businesses actually want, so here's the honest version.
ACH costs somewhere between $0.20 and $1.50 per transaction, depending on volume and processor. Same-Day ACH adds maybe $0.50 on top. Card payments cost 1.5-3% of the transaction value plus a per-transaction fee — for a $500 charge, that's $8-$15. For a $5 charge, it's still 30-50 cents because the per-transaction fee dominates. ACH wins on cost the moment ticket size gets above about $50, and it wins by an enormous margin on B2B invoicing where ticket sizes can run into thousands.
Settlement: ACH is 1-3 business days standard, same-day if you submit before the cutoff. Cards settle to your bank account the next business day for most acquirers, but the customer's account is debited instantly. FedNow and RTP — the two US instant-payment rails — settle in seconds, 24/7/365. They cost $0.01 to $0.045 per transaction, which is cheaper than ACH on paper, but transaction limits are lower (currently $1 million for FedNow, $10 million for RTP) and not every bank supports them yet.
Reversibility: ACH debits can be returned by the customer for up to 60 days for unauthorized debits, two business days for "wrong amount" or "wrong date" disputes. Cards carry chargeback rights for 120 days or longer depending on the network and reason code. FedNow and RTP are credit-push only and effectively irrevocable — once the money's sent, it's gone unless the receiver agrees to send it back.
Use ACH for recurring billing, B2B invoicing, payroll, and any high-ticket payment where the cost saving over cards is meaningful and you can tolerate 1-3 day settlement. Use cards where the customer expects to use a card, ticket size is small, or you need the chargeback infrastructure cards provide. Use FedNow or RTP for instant credit-push scenarios — funding a wallet, paying a contractor at the end of a job — where the irreversibility is actually a feature. In the UK, the closest equivalent to FedNow is Faster Payments, and the equivalent of ACH debit is open banking variable recurring payments, which we cover in our Pay-by-Bank guide.
How businesses accept ACH payments by phone#
Here's the problem nobody talks about until they're trying to fix it. ACH needs the customer's bank account number and routing number. On a phone call, that means the customer reads those numbers aloud, the agent types them in, and the whole exchange sits in the call recording. Call recordings get stored, transcribed, accessed by QA teams, and occasionally leaked. A bank account number and routing number in a recording is a fraud vector — and unlike a card PAN, there's no PCI DSS framework forcing you to handle it carefully.
That doesn't make it less dangerous. It makes it worse, because the standards are softer.
At Paytia, we built ACH capture on the phone the same way we built card capture: the customer enters their account and routing numbers on their phone keypad while talking to the agent, the DTMF tones are masked from the call audio and from the agent's screen, and the digits are sent directly to the processor over an encrypted channel. The agent never hears the numbers. The recording doesn't contain them. The customer stays on the call the entire time. We cover the broader pattern in our piece on DTMF masking, and the ACH-specific flow in bank payments. The same approach works for card capture — see our phone card payments page for the equivalent on the card side.
If you're a US business looking at ACH because the card costs are killing your margin on recurring billing, the friction question is the one that matters. Cheap money rails only help you if your customers can actually pay you on them. For background terminology, our glossary entries on ACH payment, NACHA, FedNow and RTP are short and link out where it helps.
Frequently asked questions#
A few questions we hear from US businesses evaluating ACH for the first time.
Related reading#
- Pillar guide: ACH Payment Processing Explained for US Businesses
Want to see this working in your setup? Book a working-demo call — we'll wire up your actual phone system and show you a live capture.
