ACH authorization requirements: what to collect before you debit

How to accept ACH payments: the steps in order

An ACH debit is a request to pull money from someone else’s bank account. The rules allow it only with the account holder’s permission, so accepting ACH payments starts with the authorization, not the payment button.

Think of it as five steps, in this order. Not every step applies to every payment; the sections below say when each one does.

1. Get the authorization. Capture the customer’s permission in the form the rules require for that payment. Recurring consumer debits and business debits have different requirements.
2. Pick the SEC code. The Standard Entry Class code reflects who is paying and how they gave permission: PPD, CCD, CTX, WEB or TEL.
3. Validate the account. For consumer debits authorized online (WEB), account validation is required the first time you use an account number and whenever it changes, with a method such as micro-entries or a prenote.
4. Describe the entry. Some payments need a specific Company Entry Description, such as PURCHASE for consumer debits for online purchases of tangible goods.
5. Keep the proof. Store each authorization so you can produce proof of authorization quickly when asked, and protect the account numbers you keep.

In the rules, the business that collects the payment is the Originator. When your customers collect through your software, the authorization usually happens on screens your platform builds, and your platform’s role decides which further duties land on you.

Why authorization decides your return risk

When a customer tells their bank a debit was not authorized, the debit can come back as an ACH return. Several return codes concern the authorization, such as R07 when the customer has revoked it, and two go straight to whether this debit was authorized. R10 means the customer says the Originator is not known to them or was not authorized to debit the account. R11 means an authorization exists, but the entry did not match its terms, such as a wrong amount or date.

Either way, keep a clear record of what the customer agreed to. ACH returns have no card-style representment, so the record will not reverse a return inside the network, but it can be requested.

When proof of authorization is requested, the ODFI (the Originator’s bank) has 10 banking days to provide it. Since the Meaningful Modernization rules took effect on September 17, 2021, the ODFI may instead agree to accept the return. If the record cannot be produced in time, the ODFI’s only option is to accept the return.

The same rules set a floor for what a consumer authorization looks like: it must be readily identifiable and use clear and readily understandable terms. Nacha’s guidance on proof of authorization for WEB debits lists what a good one contains:

• Express language that the customer authorizes the debit.
• The amount and the timing or frequency of the debits.
• The account and routing numbers being debited.
• Revocation language that tells the customer how to withdraw the authorization.

For what each code means and what to do after a return, see our guide to ACH return codes and what to do next.

ACH authorization requirements by SEC code: PPD, CCD, CTX, WEB and TEL

Every ACH entry carries a three-letter Standard Entry Class (SEC) code. It tells the banks what kind of account is involved and how the payment was authorized, and each code has its own authorization rules.

PPD (Prearranged Payment and Deposit) covers credits or debits to consumer accounts under a standing arrangement, such as payroll direct deposit or recurring bill pay. A PPD debit needs the consumer’s authorization in writing, signed or similarly authenticated. An electronic signature that meets the E-SIGN Act counts. The consumer must get a copy.

CCD (Corporate Credit or Debit) and CTX (Corporate Trade Exchange) are for payments to business accounts. A CCD entry carries at most one addenda record. A CTX entry can carry up to 9,999 addenda records of remittance data, which suits trading partners that send invoice detail with the payment. Authorization for both rests on an agreement between the businesses, covered under business debits below.

WEB is for consumer debits authorized or initiated over the internet or a wireless network, such as a payment set up in a customer portal or an app. It is also the code for person-to-person credits. WEB debits carry three extra duties. The Originator must use a commercially reasonable fraudulent-transaction detection system, which includes validating the account. It must also authenticate the consumer’s identity in a commercially reasonable way and check that routing numbers are valid.

TEL is for consumer debits authorized orally over the telephone. For a single TEL debit, the Originator must either record the oral authorization or send the consumer written notice confirming it before the entry settles, and keep the recording or notice for two years from the date of authorization. When a phone authorization sets up recurring debits, Regulation E applies too, and the records are kept for two years from termination or revocation.

Since Meaningful Modernization, later payments under a standing authorization, called subsequent entries, can use WEB or TEL depending on how each one is initiated.

A field service office that takes a repair payment by phone is a typical TEL case. See how phone and invoice payments fit together in payments for field service software.

Recurring consumer debits under Regulation E

Regulation E is a federal regulation (12 CFR Part 1005), separate from the Nacha Operating Rules. A recurring debit from a consumer account has to meet both. As of October 2026, section 1005.10 includes three requirements for these preauthorized transfers that shape your payment screens.

• A written authorization, 1005.10(b). Recurring debits from a consumer account may be authorized only by a writing the consumer signs or similarly authenticates, and the consumer gets a copy.
• The right to stop a payment, 1005.10(c). A consumer can stop a preauthorized debit by telling their bank at least three business days before it is scheduled.
• Notice when the amount varies, 1005.10(d). If a debit differs from the previous or the authorized amount, the consumer gets written notice of the amount and date at least 10 days before it. The exception is a consumer who chose to be told only when an amount falls outside a set range.

Take rent. If the monthly amount changes, for example when utility charges are added, the resident gets the 10-day notice before the debit. Our page on payments for property management software shows how rent payments fit together.

Monthly gifts work the same way. A donor who sets up a monthly bank gift on a donation page gives a WEB authorization for recurring debits, so the Regulation E rules apply, along with WEB account validation the first time the account is used. See payments for nonprofit and fundraising software for the donor side.

Business debits: CCD and CTX

Debits from business accounts follow a different model. The Nacha Rules prescribe no consumer-style authorization form. Instead, CCD and CTX entries rest on an agreement between the Originator and the business being debited, under which that business agrees to be bound by the Nacha Rules.

On a platform, that agreement can sit in the terms your customer’s business clients accept when they choose to pay by bank. Write the debit permission into those terms in plain language, keep the accepted version on file, and use the business codes only for business accounts.

ACH account validation for WEB debits

Since March 19, 2021, Originators of WEB debits must validate the account the first time they use an account number and whenever the account number changes.

The method is up to the Originator. Prenotes, micro-entries and third-party validation services are all options. The minimum is confirming that the account is open and can accept ACH entries. The rule does not require checking who owns the account. An account with a proven payment history does not need to be validated again.

Our guide to Nacha’s 2026 fraud monitoring rules for platforms covers the monitoring that sits around account validation.

ACH micro-entries

Micro-entries are one way to validate an account. Nacha defines them as ACH credits of less than $1, plus any offsetting debits, used to verify an account. They must carry the Company Entry Description ACCTVERIFY.

Since September 16, 2022, offsetting debits may not exceed the credits, and the credits and debits must settle at the same time. Since March 17, 2023, Originators of micro-entries must use commercially reasonable fraud detection, including monitoring the volume of micro-entries they send and the returns that come back. Reviewing each entry one by one is not required.

ACH prenotes

An ACH prenote is a zero-dollar entry sent to check account details before live payments. It is optional: one validation method among several.

After a prenote, live entries may start on the third banking day after the prenote’s settlement date, as long as no return or Notification of Change (NOC) came back. A NOC tells the Originator that account details need correcting.

If a return or NOC arrives by the opening of business on the second banking day after settlement, the problem has to be fixed before any live entry goes out. If you use prenotes, build that wait into the first payment date your software offers.

Since June 21, 2024, prenotes may be sent at any time, not only before the first payment, for example to revalidate an account that has been inactive. When a NOC arrives for recurring debits, the correction must be applied within six banking days of receiving it or before the next entry, whichever is later.

Company Entry Descriptions since March 20, 2026

Every ACH entry carries a Company Entry Description, a 10-character field that says what the payment is. Since March 20, 2026, two descriptions have been mandatory for specific payments. They join older required descriptions such as ACCTVERIFY for micro-entries and RETRY PYMT for reinitiated debits.

• PURCHASE is for consumer WEB debits for online purchases of tangible goods, including recurring purchases of goods first authorized online. It does not cover services such as telehealth, utilities, internet, gyms or insurance, and it does not cover licenses or recurring bill payments. Nacha also allows PURCHASE on TEL entries under standing authorizations.
• PAYROLL is for PPD credits to consumer accounts for wages, salaries and similar pay, such as tips, bonuses and commissions. It does not cover pensions, expense reimbursements, tax refunds or insurance payouts.

So rent, monthly gifts and software subscriptions do not use PURCHASE: none of them is an online purchase of tangible goods.

Storing account numbers

If your software keeps the bank account numbers behind authorizations and scheduled debits, Nacha’s data security rules matter to you. Under those rules, non-consumer Originators, Third-Party Service Providers and Third-Party Senders with more than 2 million ACH entries a year must make stored account numbers unreadable.

The line was 6 million entries from June 30, 2021, and dropped to 2 million on June 30, 2022. A party that crosses 2 million entries in a year must comply by June 30 of the following year. Encryption, truncation, tokenization and destruction all count, and so does letting the bank store or tokenize the numbers.

Even below the threshold, keeping account numbers unreadable is a sensible default for any system that holds authorization records.

Your platform’s role

A platform that holds the ODFI agreement and sends entries for its customers is a Third-Party Sender. If its customers hold the bank agreement, it is a Third-Party Service Provider. If it sends through another Third-Party Sender, it is a Nested Third-Party Sender. Which applies depends on whose name is on the bank agreement.

The role matters because Third-Party Senders carry duties of their own:

• An annual Rules Compliance Audit.
• A risk assessment of their ACH activities, with a risk program based on it.
• Origination agreements with the ODFI and with the parties they send for.
• Unreadable stored account numbers above 2 million entries a year.

ODFIs must register their Third-Party Senders with Nacha.

Since September 30, 2022, each Third-Party Sender must do its own risk assessment and cannot rely on another party’s assessment or Rules Compliance Audit. Nested Third-Party Sender relationships must be disclosed.

When a platform is the Third-Party Sender, its business customers are the Originators.

ACH authorization checklist for platforms

Use this list when you design or review the bank payment flow in your software.

• Capture the amount, timing and account in every authorization, in clear language, with a way to revoke it.
• Give consumers a copy of every recurring authorization they sign or similarly authenticate.
• Store proof so it can be produced quickly, well inside the ODFI’s 10 banking days.
• Validate the account on the first WEB debit and whenever the account number changes.
• Use the right SEC code and Company Entry Description for how the customer authorized and what they are paying for.
• Send consumers notice before a varying recurring debit, at least 10 days ahead, unless they chose notice only for amounts outside a set range.
• Stop debiting when an authorization is revoked, and get a new one before you debit that account again.

This guide is general information about the ACH rules and Regulation E as of October 2026, not legal advice. See our terms and conditions, and confirm the details that apply to your platform with your provider, your ODFI or your counsel.

Sources

1. Consumer Financial Protection Bureau, Regulation E, 12 CFR 1005.10
2. Nacha ACH Developer Guide, How ACH works
3. Nacha ACH Developer Guide, ACH file details
4. Nacha, WEB proof of authorization industry practices
5. Nacha, Meaningful Modernization
6. Nacha, Supplementing fraud detection standards for WEB debits
7. Nacha, Account validation resource center
8. Nacha, New Nacha rule on Micro-Entries adopted
9. Nacha, Micro-Entries (Phase 2)
10. Nacha, Minor rules topics
11. Nacha, Company Entry Descriptions
12. Nacha, Supplementing data security requirements
13. Nacha, Third parties in the ACH Network
14. Nacha, Third-Party Sender roles and responsibilities