eCheck vs ACH: A Comprehensive Comparison
Categories: ACH Payments
Categories: ACH Payments
An eCheck isn’t a separate payment network — it’s a type of ACH transaction. Specifically, it’s an ACH debit that mimics a paper check, usually coded as a WEB or TEL entry, authorized online or by phone. “ACH” is the broader electronic network (governed by Nacha) that moves money between U.S. bank accounts, and it also carries payroll, vendor payments, and recurring bills that aren’t eChecks at all. So every eCheck is an ACH transaction, but not every ACH transaction is an eCheck.
If you’ve landed here trying to figure out which term applies to a payment you’re building, receiving, or troubleshooting, here’s the short version — and then the detail that actually matters for finance operations, credit unions, and the engineers building on top of ACH.
An eCheck (electronic check) is a digital version of a paper check: instead of writing a check and mailing it, a customer authorizes a debit from their checking account using their routing and account number, typically through an online form or over the phone.
Under the hood, an eCheck is processed as an ACH debit — most commonly using the WEB Standard Entry Class (SEC) code for online-authorized payments, or TEL for phone-authorized ones. Nacha requires the originator to obtain and retain proof of authorization for either method, since these are treated as lower-friction (and higher-risk) authorization types than a signed paper form.
In practice, eChecks are used for:
The Automated Clearing House (ACH) is the electronic network that moves money between U.S. bank accounts in batches, rather than one transaction at a time. It’s governed by Nacha (formerly known as NACHA), a nonprofit association whose Operating Rules are contractually binding on participating banks and credit unions.
ACH transactions fall into two directions:
ACH transactions are also tagged with an ACH SEC code that tells participating banks how the payment was authorized and what kind of entry it is:
| SEC Code | Meaning | Typical use |
| PPD | Prearranged Payment and Deposit | Payroll, consumer bill pay, direct deposit |
| WEB | Internet-Initiated Entry | eChecks authorized through an online form |
| TEL | Telephone-Initiated Entry | eChecks authorized by phone |
| CCD | Corporate Credit or Debit | Business-to-business payments |
| CTX | Corporate Trade Exchange | B2B payments with remittance data attached |
it’s the actual technical distinction that engineers building ACH integrations need, and it’s what makes the “eCheck vs. ACH” question resolvable in one sentence — an eCheck is just ACH under a WEB or TEL SEC code.
When an eCheck or ACH debit can’t be completed, the RDFI sends back a standardized return code explaining why:
| Code | Meaning | Common cause |
| R01 | Insufficient Funds | Account balance too low at time of debit |
| R02 | Account Closed | Account was closed before the debit posted |
| R03 | No Account / Unable to Locate | Account number doesn’t match bank records |
| R04 | Invalid Account Number | Account number fails the bank’s check-digit or format validation |
| R10 | Customer Advises Not Authorized | Account holder disputes the debit |
| R29 | Corporate Customer Advises Not Authorized | Business account holder disputes the debit |
A return costs a business somewhere in the $2–$15 range in processor fees, plus the time cost of re-invoicing and re-collecting. R03 and R04 in particular are almost entirely preventable: they happen when a routing or account number is mistyped, stale, or belongs to a closed account — exactly what real-time account validation checks before the debit is ever submitted.
A quick numeric scenario: A mid-size PropTech platform collecting monthly rent via eCheck from 5,000 tenants, with a typical 2–4% R01/R03/R04 return rate, might see 100–200 failed debits a month. At even $5 per return in processor and operations cost, that’s $500–$1,000 in avoidable monthly cost — before counting the late-rent friction with tenants. Validating account and routing numbers (and confirming account ownership) before submission is how platforms like ACHGenie reduce that return volume, rather than discovering the problem after the fact.
| eChecks | General ACH Payments | |
| What it is | A specific ACH debit type mimicking a paper check | The broader network covering credits and debits of all kinds |
| SEC code | WEB or TEL (occasionally PPD) | PPD, CCD, CTX, WEB, TEL, and others depending on use |
| Direction | Debit only (pulling funds) | Both credit (push) and debit (pull) |
| Processing time | 1–3 business days (standard) | 1–3 business days (standard); same-day available |
| Typical fees | ~$0.10–$1.50 per transaction | ~$0.20–$1.50 per transaction |
| Best for | One-time or occasional bank-to-bank payments | Payroll, recurring billing, B2B, direct deposit |
| Authorization | Online form or verbal (WEB/TEL) | Varies by SEC code; often written/signed (PPD) |
| Governing rules | Nacha Operating Rules | Nacha Operating Rules |
Nacha’s rule updates are rolling out in two phases, and they affect anyone originating eChecks or ACH debits:
Nacha has been explicit that it does not mandate a specific tool or vendor for this — but it does require documented, risk-based monitoring. For businesses originating eChecks at scale, that’s a direct argument for validating account ownership and routing/account number accuracy before a transaction is submitted, not just monitoring for fraud after the fact.
Choose eCheck-style setup (via a payment processor) when:
Choose broader ACH infrastructure (via your bank or AP/payroll software) when:
In both cases, the account and routing number entered at authorization is the single point of failure most likely to cause a return — which is why validating that data before submission matters regardless of which SEC code you’re using.
Whether you’re running eChecks through a checkout form or automating recurring ACH debits through AP software, the transaction only succeeds if the account and routing number are valid and the account is open and able to accept the debit. ACHgenie checks bank account and routing number validity and account ownership in real time, before a transaction is submitted — which is aimed specifically at reducing R02/R03/R04-type returns and the fraud risk Nacha’s 2026 rules are asking originators to monitor for. Bank routing number and account number validation checks reduce upstream issues during ACH processing.
Not exactly. An eCheck is a specific type of ACH debit — typically coded WEB or TEL — designed to replicate a paper check. All eChecks are ACH transactions, but not all ACH transactions are eChecks; payroll, B2B payments, and recurring bills are ACH too, just under different SEC codes.
Standard eChecks settle in 1–3 business days, the same timeline as standard ACH. Same-day processing is available for eligible transactions at an added fee.
“ACH check” usually refers to a paper check that’s been converted into an electronic ACH debit at the point of deposit or collection, rather than processed as a physical check through the check-clearing system.
Do eChecks or ACH payments process on weekends?
No. Both run on the ACH network’s processing schedule, which follows business banking days — weekends and federal holidays don’t count toward the 1–3 day settlement window.
The receiving bank returns it with a standardized code (see the table above) — most commonly R01 for insufficient funds or R03/R04 for account-number mismatches. The originator is notified and can attempt to correct and resubmit within Nacha’s rules, though repeated unauthorized-return codes like R10/R29 can trigger additional scrutiny.
Yes, when authorization and account validation are handled correctly. eChecks run over the same Nacha-governed network as any other ACH transaction, with the same underlying security standards — the main risk is accepting invalid or fraudulently provided account details, which is what pre-transaction validation is designed to catch.
