What is an ACH prenote? How the zero-dollar check works

Short answer

An ACH prenote is an optional non-monetary entry that checks whether account information can accept ACH entries. No money moves. The entry mirrors the planned live payment except for the amount and transaction code, so the receiving bank can return incorrect data or send a correction before live entries begin.

At a glance

• Value$0; a prenote does not credit or debit the account
• PurposeCheck whether the account is open and able to accept ACH entries
• UseOptional for all Standard Entry Class codes
• WEB debit validationA prenote meets Nacha’s minimum account-validation standard
• Not proof ofAccount ownership, the payer’s identity or a valid authorization
• AlternativeMicro-entry verification or another account-validation service

Sources: Nacha ACH Guide · Nacha WEB debit account-validation FAQs · Checked October 25, 2026

What the prenote contains

A prenotification entry, usually shortened to prenote, travels through the ACH Network without transferring funds. Nacha says it should look like the later live-dollar entry apart from its amount and transaction code. That gives the receiving depository financial institution, or RDFI, the same routing and account data it will see on the real payment.

The originator sends the prenote through its bank, the originating depository financial institution or ODFI. The RDFI then tests the account information against its records. If it cannot accept the entry, it can return the prenote. If the data needs correcting, it can send a Notification of Change.

A prenote is not a tiny payment. That is the key difference from micro-deposits, which move small amounts and require the customer to confirm information back to the originator.

What a successful prenote proves

For a consumer WEB debit, Nacha’s fraud-detection standard requires the originator to validate first-use account information. Nacha lists a prenote as one permitted method.

If the originator sends a prenote and receives no return or Notification of Change by the end of the applicable response period, Nacha says it may treat that as confirmation that the account is open and can accept ACH entries. The standard is narrow. It tests the account number’s ability to receive the entry.

It does not prove all of the following:

• that the person entering the account number owns the account;
• that the name supplied matches the bank’s account title;
• that the person has authority to debit the account;
• that the account will have enough money for the live debit; or
• that a future payment will not be returned for another reason.

Nacha also warns that a prenote may not be commercially reasonable for every business model or risk profile. An originator may need stronger checks, such as ownership matching, bank-login verification or additional fraud controls.

Prenote versus micro-entry verification

Both methods can help validate an account, but their evidence is different.

Nacha is explicit about the last row. With micro-entries, an originator cannot assume that silence means success merely because the bank did not return them. The verification step must be completed. A prenote works differently: the network response, or lack of one after the applicable period, is the validation signal.

When businesses use prenotes

Prenotes are common before payroll, vendor payments, insurance debits, loan payments and other recurring ACH activity. They can reduce avoidable live-entry returns caused by a closed account, an invalid account number or incorrect account type.

The rules were also updated in 2024 to reflect revalidation. Nacha removed language that had limited prenotes to the period before the first live credit or debit. An originator can therefore use a prenote to recheck a dormant or inactive account before renewed activity.

That does not make a prenote mandatory for every ACH payment. Nacha calls prenotes optional for every Standard Entry Class code. The business, its bank and their risk policies decide whether to use one, subject to any account-validation rule that applies to the payment.

Returns and Notifications of Change

A returned prenote means the originator should not simply send the live entry unchanged. The return code tells the parties why the receiving bank could not accept it. Common account-data problems are covered in our guide to ACH return codes.

A Notification of Change, or NOC, is different. It tells the originator that the entry reached the right banking relationship but one or more fields should be corrected. For example, a bank merger or account conversion may change routing or account information. The originator should apply the corrected data under the Nacha rules and its agreement with the ODFI.

Keep the prenote, response and any correction linked to the payment setup. If a live debit is disputed later, the prenote proves only that the account data passed this network check. It does not replace the customer’s authorization record.

A practical implementation checklist

1. Collect authorization separately. A prenote is account validation, not permission to debit.
2. Build the live entry first. The prenote should use the same account data, except for the amount and transaction code.
3. Track the response window. Do not release the live entry until the applicable prenote period has ended.
4. Stop on a return. Review the code and correct the setup before trying a live payment.
5. Apply an NOC carefully. Store the bank’s corrected data and an audit trail.
6. Choose stronger checks where needed. A higher-risk product may need ownership or identity signals beyond the prenote.
7. Monitor the live entry. A valid prenote cannot prevent later returns for insufficient funds, revoked authorization or other reasons.

For settlement timing after the entry is sent, see how long ACH takes. If a payment is already late, start with ACH transfer pending.