ACH Payments for B2B: A Practical Guide for US Businesses

Last updated: 27 May 2026

The Automated Clearing House — ACH — moves around $80 trillion a year through the US payments system, most of it between businesses. Direct deposit payroll, supplier invoice settlement, recurring vendor charges, account-to-account transfers — the plumbing for most of US B2B finance runs on ACH. If you accept or send business payments and you're not running every transaction through a wire or a card, ACH is what you're using.

This guide walks through what the network actually does, what changed when same-day ACH arrived in 2016, why returns aren't chargebacks, and what to think about if you're collecting ACH details from a customer over the phone.

What ACH actually is#

ACH is a batch-based electronic funds transfer network. It's run by Nacha (the National Automated Clearinghouse Association) as a rule-setting body, with the actual transaction processing handled by two operators: the Federal Reserve's FedACH service and The Clearing House's EPN. Banks send ACH batches to one of these operators, the operator clears them, and funds settle into the receiving bank's accounts.

The defining trait is that ACH is not real-time. Transactions are gathered into batches, sent at scheduled windows, and settled on the following business day for standard ACH — or the same day, within specific cut-off windows, for Same Day ACH. There's no overnight Sunday settlement; ACH respects bank holidays and weekends. A payment initiated Friday afternoon doesn't move until Monday.

Transaction fees are low compared to card payments. Most banks charge somewhere between $0.25 and $1.50 per ACH transaction, depending on volume and provider. Compared to wire transfers ($15-50 per outbound wire, often more) and card payments (1.5-3.5% interchange plus assessments), ACH is the cheapest electronic option for any payment large enough that the percentage savings matter.

The two flow directions#

ACH credits push money from one account to another. The originator instructs their bank to send funds to the receiver's bank. Payroll is the classic example — the employer's bank pushes a credit to each employee's bank account. The receiver doesn't have to authorize the specific transaction; they just have an account that's ready to receive credits.

ACH debits pull money from one account to another. The originator instructs their bank to collect funds from the receiver's bank. Recurring utility bills, subscription charges, mortgage payments — these are typically ACH debits, where the customer has signed an authorization (often called a Nacha-compliant authorization) allowing the merchant to pull from their account on a recurring schedule.

For B2B work, both directions get used heavily. A supplier might push an ACH credit to clear an account-receivable balance, or a buyer might let the supplier pull an ACH debit against a standing authorization. The dispute mechanics are slightly different — pulled debits have a stronger return window than pushed credits — but the underlying rails are the same.

Taking ACH details over the phone? Book a 15-minute demo — we'll show you how to capture routing and account numbers without your agents hearing them.

Same Day ACH — what 2016 changed#

Same Day ACH launched in 2016 as a phased rollout, adding faster processing windows on top of standard ACH. Three settlement windows now exist per business day: morning, midday, and afternoon. A transaction submitted before a window's cut-off settles the same day, instead of the next business day.

The transaction limit on Same Day ACH was raised to $1 million per payment in March 2022. Most ACH transactions, including high-value B2B settlements, can now move same-day if both banks support it. The fee per Same Day ACH credit is small — a few cents on top of standard pricing — and most originating banks make the choice on a per-transaction basis.

Same Day ACH isn't real-time. Even the fastest window has a multi-hour gap between submission and posting. For genuinely instant transfers — money that has to be confirmed in seconds — FedNow and RTP are the rails to use. For B2B work where "same day" rather than "this minute" is the requirement, Same Day ACH gets you there at a fraction of the cost.

The three windows in detail

Each Same Day ACH window has a published cut-off and a published settlement time. The morning window closes around 10:30 AM ET, with funds settled by 1:00 PM ET. The midday window closes around 2:45 PM ET, with settlement by 5:00 PM ET. The afternoon window — added in March 2021 — closes around 4:45 PM ET, with settlement by 6:00 PM ET. Times shift slightly on holiday-shortened banking days, and individual banks may impose earlier internal cut-offs to give themselves processing room.

The afternoon window matters more than it looks. It lets a West Coast originator submit a payment after their lunch break and still get same-day settlement, which the original two-window structure didn't allow. For a finance team based in San Francisco running payroll true-up or supplier emergency settlements, that extra window removed the previous "submit by 11 AM Pacific or wait until tomorrow" constraint.

Where Same Day ACH still doesn't fit

If the receiver needs the money confirmed within minutes — closing a real estate transaction, funding a securities trade, settling an emergency vendor payment that's holding up shipment — Same Day ACH still has too much latency. FedNow (the Federal Reserve's instant-payments service, launched July 2023) and RTP (The Clearing House's Real-Time Payments network, live since 2017) settle in seconds, twenty-four hours a day, with no batch windows. Both have lower transaction limits than ACH ($500,000 on FedNow as of 2024, $1 million on RTP), but for moves that fit those limits and need instant finality, they're the right rail.

NACHA SEC codes — knowing which one applies#

Every ACH transaction carries a Standard Entry Class (SEC) code that tells the network what kind of transaction it is and what authorization rules apply. The SEC code isn't a back-office formality — pick the wrong one and your transaction either bounces or fails an audit later.

For B2B work the codes you'll see most often are CCD, CTX, and WEB. CCD (Corporate Credit or Debit) is the workhorse for business-to-business payments where the two parties have a pre-arranged trading relationship — supplier invoices, vendor settlements, intercompany transfers. CTX (Corporate Trade Exchange) is the same idea but carries 9,999 addenda records' worth of remittance data alongside the payment, useful when you're settling dozens of invoices in one transaction and the receiver's AP system needs the line-item detail to reconcile.

WEB (Internet-Initiated Entry) covers debits authorized through a website — typically used when a customer enters their bank details into an online form. TEL (Telephone-Initiated Entry) covers debits authorized over the phone, which we cover further down in the phone-capture section.

For credits sent to consumer accounts, the code is usually PPD (Prearranged Payment and Deposit). Payroll runs are PPD credits. The B2B-vs-consumer distinction matters because PPD has different return windows and authorization rules than CCD — Nacha treats consumer accounts as more protected than commercial ones.

Returns aren't chargebacks — and you have to know the difference#

One of the things that catches finance teams new to ACH is that the return mechanism is fundamentally different to card chargebacks. An ACH return happens when the receiving bank can't or won't credit a payment — wrong account number, insufficient funds, closed account, customer's unauthorized debit dispute. The return is sent back through the network as a coded message (R01, R03, R10, and so on), and the originator's bank reverses the original transaction.

For most return reasons — administrative errors, account closure, NSF — the return window is two banking days. For unauthorized debit returns, where a customer claims they didn't authorize the transaction, the window is 60 days. That's longer than card chargebacks for many disputes, and the burden of proof sits with the originator. If you can't produce a Nacha-compliant authorization, the return stands.

The practical implication for B2B work is that good record-keeping matters. Every recurring ACH debit needs a documented authorization that includes the customer's name, account details, the amount or method of calculating the amount, the frequency, and the customer's signature or electronic equivalent. Nacha's rules on what counts as a valid authorization are detailed and worth reading once before setting up any recurring B2B ACH program.

Returns aren't a fraud signal by themselves. Most returns are mundane account-administration issues. But Nacha tracks return rates and applies fines to originators whose unauthorized-debit return rate exceeds 0.5% of total transactions, and whose administrative return rate exceeds 3%. Both thresholds are hit by businesses that aren't watching their customer-list hygiene closely enough.

The return codes you'll actually see

There are around eighty return codes in the Nacha rulebook, but a handful account for most of the volume in B2B work. R01 (insufficient funds) is the most common return on debits — the customer's account didn't have the money. R02 (account closed) and R03 (no account / unable to locate account) usually mean the customer's banking details are out of date. R04 (invalid account number) is a data-quality issue, often a typo in the original capture.

R07 (authorization revoked by customer) and R10 (customer advises unauthorized) are the ones to watch on debits. R07 means the customer told you in writing to stop, and you took the debit anyway. R10 means the customer told their bank they never authorized it. Both have the 60-day return window and both leave you with a fight to produce the authorization paperwork. R29 (corporate customer advises not authorized) is the B2B equivalent of R10 — same idea, shorter window because the receiver is a business not a consumer.

R20 (non-transaction account) catches debits sent to accounts that can't legally receive ACH debits — savings accounts in certain states with the wrong restriction flag, certain types of trust account. The fix is usually to phone the customer and confirm which account they actually want debited.

If you're seeing more than 1-2% returns across all codes, something's wrong with your data capture or your authorization process. The fix isn't to bury the returns — Nacha is watching the ratio, and the enforcement letters arrive about three months after you cross the threshold.

Where ACH wins against wires and cards for B2B#

Wires are still the right rail for genuinely high-value, time-critical international or domestic B2B payments — real-estate closings, corporate acquisitions, treasury moves where finality matters in the minute. The cost per wire makes them expensive at volume.

Cards win for low-value, frequent, recurring B2B work where the customer expects card convenience — SaaS subscriptions under $5,000, expense-account purchases, travel and entertainment. Card interchange plus processing typically lands at 2-3% all-in. On a $50 SaaS charge that's a rounding error. On a $50,000 supplier invoice, it's $1,500 of pure margin loss every month.

ACH wins everywhere in between. Supplier payments, payroll for businesses without a dedicated payroll provider, recurring service-contract billing, vendor settlements, intercompany transfers — these are the workloads where ACH's fee structure makes the math work. The trade-off is the settlement delay (T+0 same-day, T+1 standard, T+2 for some legacy flows) and the return window.

The cost math on a typical mid-market spend pattern

Take a mid-market US business spending $5M a year on vendor settlements split across 1,200 invoices. The average invoice is around $4,167. Run that through cards at 2.5% all-in and you're paying $125,000 a year in processing fees. Run it through wires at $20 outbound each and you're paying $24,000. Run it through ACH at $0.50 each and you're paying $600. The wire-vs-ACH gap alone is enough to fund a part-time AP analyst — and the ACH option still gives you electronic remittance, audit trail, and same-day settlement when you need it.

The math flips on small, frequent charges. A $25 monthly SaaS bill costs $0.63 on cards (2.5%) but the ACH per-transaction fee is $0.50 either way — so the percentages favour cards. Most businesses end up with a mixed stack: cards for low-value high-frequency charges, ACH for everything mid-to-large, wires reserved for genuinely time-critical or international moves.

Capturing ACH details on a phone call#

This is where it gets relevant to anyone running a contact center that takes B2B payments. To set up an ACH debit, you need the customer's bank routing number (the nine-digit number that identifies their bank) and their account number (typically 8-12 digits depending on the bank). That's sensitive information. Treating it casually is how merchants end up with unauthorized debit disputes, reputational damage, and uncomfortable conversations with their compliance team.

The traditional approach on a phone call is to have the agent read the digits back, or ask the customer to email them, or send them through an online portal mid-call. Each of those approaches has real problems. Agents hearing routing and account numbers means call recordings capture them, screen recordings capture them, and any agent could write them down or remember them. Email isn't secure. A separate portal breaks the call flow.

The cleaner pattern is the same one used for card payments: capture the digits directly from the customer's phone keypad, with the tones intercepted before they reach the agent or any recording system. The agent stays on the call. The customer stays on the call. The conversation continues — the agent just never hears the routing or account number. The digits route directly to the system that stores or initiates the ACH transaction.

This is the same digit-capture pattern most contact centers use for card payments — see our piece on PCI compliance for telephone payments for how the broader category works.

TEL transactions — the specific code for phone-authorized debits

When a customer authorizes an ACH debit over the phone, the transaction carries the TEL SEC code. TEL has its own authorization requirements: the call has to be recorded (or you have to send written notice of the authorization within a defined window), the customer has to verbally confirm the amount, the date, and the account being debited, and you have to retain the recording or the written notice for two years.

That recording requirement is where it gets interesting. If the call is recorded for TEL compliance, the recording contains the verbal authorization — that's the whole point. But if the customer reads their routing and account number out loud, the recording also contains the bank details, which means your call archive needs to be treated as sensitive storage. The cleaner pattern keeps the verbal authorization ("yes, I authorize $4,500 on May 30, debited from my Wells Fargo account") in the recording while keeping the actual routing and account digits out — captured separately via the keypad and masked from the audio stream.

How Paytia handles ACH capture#

Paytia's DTMF masking architecture was built for card numbers, but the underlying principle — separate the sensitive digit stream from the audio the agent and recording hear — applies equally well to ACH details. The customer keys their routing number and account number on their phone, the digits get suppressed in the audio path, and the captured numbers route to the merchant's ACH processing system or treasury platform.

That keeps the routing and account numbers out of call recordings (relevant for any audit), out of agent earshot (relevant for staff training and call-quality monitoring), and out of any screen-recording or QA tool that might be running alongside the agent. The call recording still exists for legitimate quality and dispute purposes — it just doesn't contain the sensitive identifiers.

The architecture isn't ACH-specific. The same approach works for capturing one-time passcodes during phone-based authentication, account verification numbers, and any other sensitive identifier a customer needs to enter during a call. It also pairs naturally with tokenization for stored payment methods — once the bank details are captured cleanly, they can be vaulted at your ACH processor and replaced in your CRM with a token, so no part of your environment ever holds the raw account number.

For businesses already taking card payments over the phone, adding ACH capture to the same flow is usually a configuration change rather than a separate build — the masking layer is agnostic to what digits it's protecting.

Industry use cases — where ACH-over-phone actually shows up#

The pattern matters most in industries where high-value B2B payments are routine and the customer expects a phone call rather than a web form. A few common ones:

Wholesale distribution. Auto parts, building materials, food service supply — credit terms are standard, payments are large, and the AR team usually handles collection by phone. Capturing the buyer's ACH details mid-call is faster than emailing a form and waiting for it to come back. The same pattern works for net-30 invoicing run-outs, where the AR team needs to set up a one-off ACH on a customer who normally pays by check.

Healthcare billing. Patient responsibility balances after insurance often run into thousands of dollars, and many patients prefer to call the billing office and set up an ACH payment plan rather than hand over a card. The phone-capture flow keeps the bank details out of the agent's hearing — relevant under HIPAA as well as the broader sensitive-data rules. See our HIPAA payment processing piece for the wider compliance picture.

Insurance premium collection. Commercial insurance premiums on net-monthly plans get paid by ACH because the dollar amounts make card processing fees prohibitive. When a policy is being set up over the phone — a producer working with a small business owner — the ACH detail capture happens during the same call. Channel separation keeps the bank details out of the producer's recording.

B2B SaaS at the higher tiers. Enterprise SaaS contracts in the five-to-six-figure range routinely pay annually by ACH rather than card. The onboarding call typically includes a procurement contact handing over the company's bank details — and the customer's procurement team is more comfortable when the bank details aren't being read out loud to a sales rep.

Property management. Commercial leases settled via ACH where the tenant's accounts team calls in to set up automatic monthly rent debits. Same recording and authorization rules apply, same digit-capture discipline matters.

Common mistakes — the ones we see most often#

A few patterns come up again and again when businesses set up B2B ACH programs without the right groundwork:

Treating verbal "yes, you can take it" as a valid authorization. Nacha rules require specific information in the authorization — the amount or amount-calculation method, the date or frequency, the receiver's name, and a clear statement that the customer is authorizing the debit. A casual "go ahead, take it from my account" doesn't satisfy the rule. When the R10 return arrives 50 days later, the recording of the call is the evidence — and it has to contain those specific elements.

Reusing an authorization for a different amount or different frequency. If you have authorization for $1,200 monthly and the customer asks you to take an extra one-off $800, that's a new transaction that needs its own authorization. Pulling the extra amount on the existing authorization is exactly the trigger for an R07 (authorization revoked) or R10 (unauthorized) return.

Storing routing and account numbers in your CRM in clear text. Even though there's no formal PCI-equivalent regime for ACH, the practical risk profile is similar — bank details in a CRM are a high-value target for both external attackers and rogue insiders. Tokenize at the processor, store the token, never store the raw numbers.

Ignoring return-rate trends until Nacha sends a letter. The unauthorized-debit threshold (0.5%) and administrative-return threshold (3%) are calculated on rolling 60-day windows. Most businesses that cross them did so over several months of climbing rates that nobody flagged. Set up a monthly dashboard, alert when the rate moves more than 25% month-on-month, and act on the trend before Nacha does.

Submitting Same Day ACH expecting it to be instant. Same Day means "settles within the same business day, in batched windows" — not "the receiver sees the money in five minutes." If the receiver's bank doesn't post until end-of-day, even a 10 AM submission may not show in the receiver's account until after 5 PM. For genuine instant transfers, FedNow or RTP are the right rails.

Not separating the digit capture from the agent. The most common pattern we see is agents typing routing and account numbers directly into the CRM as the customer reads them out. That puts the bank details in the call recording, in the agent's notepad if they were jotting along, in the screen-recording archive, and in the CRM in clear text. Channel separation or DTMF masking removes all of those exposure points in one move.

A short checklist for B2B ACH programs#

Three things tend to make or break a B2B ACH program. First, get the authorization paperwork right — Nacha-compliant, retained, and producible on demand when an unauthorized-debit return shows up. Second, watch your return rates monthly and act on rising trends before they cross Nacha's enforcement thresholds. Third, treat the capture method for routing and account numbers with the same seriousness you treat card numbers — call recordings full of bank account details are a problem waiting to happen, even if there's no formal PCI-equivalent regime for ACH.

None of this is exotic. It's the difference between an ACH program that runs quietly in the background for years and one that generates regular firefighting.

The originator-bank relationship — what banks actually look at#

When you apply to originate ACH through a bank, you're asking the bank to put its name behind your transactions. The bank carries financial liability for unauthorized debit returns up to the 60-day window, which is why ACH underwriting feels more like a credit application than a routine account opening. Three things drive the assessment.

First is your expected volume and average transaction size. A business saying "we'll do maybe twenty $500 transactions a month" gets a faster yes than one saying "we'll do thousands of $50,000 transactions a month" — not because the bigger volume is bad, but because the bank needs to be comfortable that you can cover return liability if things go wrong. Larger volume usually triggers a reserve requirement or a personal guarantee from the principals.

Second is your industry. Some industries — debt collection, payday lending, certain types of recurring subscription business — sit on a higher-risk list with most banks. That doesn't mean you can't get origination; it means you'll need a bank that specifically underwrites those verticals, and the fees and reserves will be higher. Plain B2B settlement work for a stable business in a non-restricted vertical is straightforward.

Third is your returns history if you've originated elsewhere. Banks ask for prior-bank statements showing your unauthorized-debit return rate, your administrative return rate, and any Nacha enforcement actions. A clean history makes the application straightforward. A history of consistent 1%+ unauthorized returns will close most doors.

The whole assessment typically takes 2-4 weeks for a clean small-business applicant. If you're being asked for personal financial statements from the principals, expect another week or two while they're reviewed. The output is an ACH origination agreement that specifies your daily and per-transaction limits, your reserve requirement, and the bank's right to terminate origination if your return rates exceed Nacha thresholds.

Reconciliation — making the returns process workable#

The piece of ACH that catches most finance teams off-guard is reconciliation. A card payment confirms instantly — the gateway returns approved or declined within seconds. An ACH payment doesn't. The transaction submits, your bank confirms receipt, and that's it. Two to five days later, returns trickle back into your ACH return file. You don't actually know which payments succeeded until the return window has closed.

That means your AR system needs a state machine, not a simple paid/unpaid flag. Each ACH transaction goes through "submitted," "settled" (when the originator's bank confirms the receiving bank credited the account), and then either stays "settled" or moves to "returned" if a return code arrives within the window. Most accounting systems handle this badly — they mark the invoice paid on submission and require manual reversal when the return arrives, which leads to ledger discrepancies and customer phone calls asking why their invoice is showing both paid and overdue.

The cleaner pattern is to hold the invoice in a "payment in progress" state until either the return window closes (typically five banking days after settlement for most return codes) or a return arrives. Only then does the invoice flip to fully paid. The 60-day unauthorized-debit window can't be held open that long for accounting purposes — most businesses accept the small risk and book the revenue at the five-day mark, then handle the rare late return as a reversal.

For high-volume B2B work, automate the return-file ingestion. Your ODFI provides daily ACH return files in NACHA format or in a structured CSV. Parse them automatically, match returns back to original transactions by trace number, and post the reversal to the right invoice. Manual ingestion at any volume above a few hundred transactions a month is a reliable source of reconciliation errors.

International considerations — IAT and cross-border B2B#

Standard ACH is a US-only system. If you're settling with international suppliers or international customers, ACH proper doesn't reach them. The closest equivalent is the IAT (International ACH Transaction) SEC code, which carries an ACH transaction across a border — but IAT has stringent OFAC screening requirements, additional remittance information requirements, and tighter return windows. Most businesses settling internationally use wire transfers (SWIFT) or cross-border specialists like Wise (formerly TransferWise) rather than trying to push everything through IAT.

For US businesses with US-only B2B operations, this doesn't matter. For multinationals with a US arm settling against international suppliers, the right answer is usually a mixed treasury approach — domestic ACH for US-to-US settlement, wires for high-value international, and a cross-border specialist for routine smaller international payments where wire fees would be prohibitive.

Frequently asked questions#

What's the difference between Same Day ACH and FedNow?

Same Day ACH runs in batched windows — three per business day, with cut-offs at roughly 10:30 AM, 2:45 PM, and 4:45 PM ET, and settlement a few hours after each cut-off. It only runs on banking days. FedNow runs 24/7/365 and settles in seconds, but has a lower per-transaction limit ($500,000 vs $1M on Same Day ACH) and not every bank supports it yet. Use Same Day ACH when you need same-business-day settlement at low cost. Use FedNow when seconds matter and the amount fits the limit.

How long do I have to keep ACH authorization records?

Nacha rules require originators to retain authorization records for two years after the authorization is terminated. For recurring debit programs where the authorization stays active for years, that means the record has to live as long as the debit relationship plus two more years. Most businesses retain longer than that to cover state-level evidence rules — five to seven years is a common policy.

Can a customer revoke an ACH authorization?

Yes. A customer can revoke an ACH authorization at any time by notifying the originator in writing — though many businesses accept phone or email revocation as well, partly to maintain the relationship and partly because forcing the customer through a slow revocation process tends to backfire with their bank. Once revoked, any subsequent debit is unauthorized and exposes the originator to an R07 return.

Are ACH payments reversible by the originator?

Limited circumstances. Nacha rules allow an originator to reverse an ACH entry within five banking days, but only for specific reasons — duplicate transmission, wrong amount, wrong account. You can't reverse simply because the customer changed their mind. For genuine errors, the reversal has to be sent within the five-day window and clearly labelled as a reversal, not a new transaction.

Do I need a special bank relationship to originate ACH?

Yes. Your business needs an ACH origination agreement with your bank (or with a payment processor that has its own ACH origination capability). The bank will assess your business — credit risk, expected volume, returns history if you've originated elsewhere — before agreeing to act as your ODFI (Originating Depository Financial Institution). Small businesses sometimes find their primary bank won't originate ACH for them, in which case a third-party processor is the alternative.

What's the difference between CCD and CTX SEC codes?

CCD (Corporate Credit or Debit) carries the basic payment information plus one optional addenda record. CTX (Corporate Trade Exchange) carries up to 9,999 addenda records of structured remittance information, typically in EDI 820 format. Use CCD for simple settlements where the receiver just needs the payment amount and a reference. Use CTX when the receiver's AP system needs detailed line-item remittance to reconcile against invoices — typical in larger enterprise B2B where the AR/AP integration matters.

What's the typical setup time for a new ACH program?

The bank application typically takes 2-4 weeks for a small business with no prior origination history, including underwriting and documentation. Larger businesses with established banking relationships can be set up faster. The technical integration with your accounting or treasury system is usually 1-2 weeks once the bank agreement is in place. Add another week or two for testing in the bank's sandbox before you turn live.

Can I run ACH and card payments through the same agent flow?

Yes. Most contact centers offer the customer the choice mid-call — pay by card or pay by bank transfer — and the same masking infrastructure handles both. The agent stays on the call regardless of which method the customer picks; only the digit-capture step differs (card number plus expiry plus CVV for cards, routing plus account for ACH). The captured details route to different processors but the agent-facing call flow is identical.

How do I prove a phone authorization was valid if a customer disputes it?

Retain the call recording, the captured DTMF metadata (which digits were entered at which timestamp, captured by the masking system), and your CRM record showing the customer's account history and the specific transaction details. The combination is usually enough to defeat an R10 dispute. The recording proves the customer verbally authorized; the DTMF metadata proves they entered the routing and account numbers themselves; the CRM history shows the broader relationship context. Keep all three for at least two years per Nacha rules, longer if your industry has stricter retention requirements.

Related reading#

• What Is Tokenization? A Plain-English Guide
• PCI Compliance for Telephone Payments
• What Is an IVR Payment?
• Take Card Payments Over the Phone

Taking ACH details over the phone? Book a 15-minute demo — we'll show you how to capture routing and account numbers without your agents hearing them.