NACHA 2026 rule changes for ACH originators

Nacha now requires two standardized values in the Company Entry Description field, the short descriptor in the batch header record that tells the receiving bank what a batch of entries is for.

• PAYROLL is required for PPD credit entries that pay wages, salaries, or similar compensation to a consumer account. If you originate direct-deposit payroll, the batch carrying those credits must use PAYROLL as its Company Entry Description.
• PURCHASE is required for WEB debit entries — consumer-authorized e-commerce debits for online purchases of goods.

Other descriptions — ACH PMT, VENDOR PAY, EXPENSES, and similar — remain valid for entries that are not payroll credits or WEB e-commerce debits. The rule standardizes two specific cases; it does not replace the field’s general use.

The intent is fraud detection. A consistent PAYROLL descriptor lets receiving banks recognize compensation deposits and flag payroll-redirection fraud — a fake “direct deposit change” that points an employee’s pay at an attacker’s account. Standardized values make duplicate or redirected payroll easier to catch.

This is the only 2026 change that affects the contents of an ACH file. If you originate PPD wage credits, the batch must carry PAYROLL.

Phase 1 requires documented, risk-based ACH fraud monitoring. It applies to:

• All ODFIs (Originating Depository Financial Institutions — the banks that send entries into the network).
• Originators, Third-Party Service Providers (TPSPs), and Third-Party Senders (TPSs) whose 2023 ACH origination or transmission volume was 6 million entries or more.
• For inbound credit monitoring: RDFIs (Receiving Depository Financial Institutions) that received 10 million or more ACH credits.

The 6-million-entry threshold is large. A small or mid-sized business running payroll for tens or hundreds of employees is well below it. Most SMBs were not in scope for Phase 1 — but Phase 2 removes the threshold entirely.

This is a procedural requirement — fraud-monitoring controls and documentation. It does not change the ACH file.

Phase 2 eliminates the volume threshold. Every non-consumer originator, TPSP, and TPS must have documented, risk-based ACH fraud monitoring — regardless of size. A small business that originates direct-deposit payroll for a handful of employees is a non-consumer originator and is in scope.

For most SMBs this is a procedural compliance task, not a file-format change. Nacha does not prescribe a specific technology or require transaction-by-transaction review. A risk-based program scaled to a small originator generally means:

• A written ACH fraud risk assessment specific to the entries you originate (for most PayFile Pro users, that is PPD payroll and vendor credits).
• Monitoring controls aligned to those risks — for example, noticing changed payroll bank details, newly added recipients, or unusual jumps in batch volume.
• Exception handling — a defined step to review and approve flagged entries before a file is released.
• An annual review of the assessment and controls.

This is something you document and operate as a business process. It is not a setting in your ACH file and not something a file generator can satisfy on your behalf. If your bank or ACH provider has issued guidance, follow it — and treat Nacha’s own materials at nacha.org as the authoritative source.

This rule changes how fast receiving banks must make money available, not how files are originated. It removes the earlier 5:00 p.m. receipt condition: an RDFI must make a non–Same Day ACH credit available to the receiver by 9:00 a.m. local time on the settlement date, regardless of when the file was delivered to it.

In practice this benefits payees — employees and vendors see deposits earlier and more predictably, including payroll sent in evening batches. It is a posting-behavior obligation on the receiving bank. It requires no change to the file you originate and no action on the originator’s side.

A separate change effective the same day updates the definition of IAT (International ACH Transaction) entries. That affects only originators sending international ACH entries and is out of scope for this page.

PayFile Pro generates NACHA-format ACH files in the browser. Of the four 2026 changes, only one touches the file itself — and it is already handled.

• Standardized Company Entry Descriptions — applies. When you generate a PPD credit batch for wages or salaries, the Company Entry Description must be PAYROLL. Set that value when you build a payroll batch. This is the single 2026 rule change that lives inside the file.
• PURCHASE — does not apply. PURCHASE is required only for WEB e-commerce debit entries. PayFile Pro does not generate WEB debits, so this value is not relevant to the files it produces.
• Fraud Monitoring Phase 2 (June 22) — not a file change. This is a procedural obligation on your side: a written risk assessment, monitoring controls, exception handling, and an annual review. No file generator — PayFile Pro included — can satisfy it for you. The honest framing is that this is a business-process task, not a software toggle. Use your bank’s guidance and Nacha’s materials.
• September 18 funds availability — no action. This governs how quickly receiving banks post credits. It does not change the file you generate.

Where PayFile Pro does help on the file side: it validates a file’s structure before you download it, so format errors that cause an outright rejection get caught before the file reaches your bank. That is a separate matter from the 2026 fraud-monitoring rules, but it is the kind of error this product is built to prevent. For a per-bank walk-through of the upload step, see the US ACH origination page.