NACHA Company Entry Descriptions: PAYROLL and PURCHASE Are Now Mandatory

Short answer: Since March 20, 2026, two company entry descriptions are mandatory in the NACHA batch header: PAYROLL on PPD credits that pay wages or salaries, and PURCHASE on WEB debits for e-commerce purchases. The field sits at positions 54 to 63 of the type 5 batch header record and was previously free text.

Last updated July 2026

This is a small field with an outsized effect. The company entry description is what a consumer sees next to a transaction in their banking app, and until 2026 originators could put more or less anything there. Standardizing two of the most common cases is intended to make transactions recognizable and to make fraud easier to spot, both for consumers and for the banks monitoring the flow.

What is a company entry description?

It is a ten character field in the batch header of a NACHA file, at positions 54 to 63, that describes the purpose of the entries in that batch. Because it lives on the batch header rather than on individual entries, every payment inside a batch shares the same description. Historically it held things like PAYROLL, PAYMENT, BILLPAY, DIRECT DEP, or whatever the originating system happened to put there, with no consistency between companies.

What changed on March 20, 2026

Two specific uses became mandatory rather than conventional:

• PAYROLL must be used as the company entry description on PPD credit entries that pay wages, salaries, and similar compensation.
• PURCHASE must be used on WEB debit entries for e-commerce purchases, meaning a debit authorized online for the purchase of goods or services.

The point is recognizability. A consumer looking at a bank feed can tell at a glance that a credit is their pay and that a debit is an online purchase they authorized, which makes an unexpected entry stand out. It also gives receiving banks a consistent signal to work with in their own monitoring.

Which entries does this actually affect?

Narrower than people often assume. The PAYROLL requirement attaches to PPD credits paying compensation, so it does not sweep in every credit you originate. A vendor payment sent as a CCD credit is not payroll and does not take the PAYROLL description. Reimbursements, distributions, and benefit payments are not wages. Similarly, PURCHASE attaches to WEB debits for e-commerce purchases, not to every WEB debit: a recurring subscription or a bill payment authorized online is not the same thing as a purchase of goods.

If you originate a mix, the practical consequence is that your batching may need to change. Because the description lives on the batch header, you cannot have one batch containing both payroll credits and other PPD credits that need a different description. Batches have to be split by description.

How do I check what description my files are using?

Read positions 54 to 63 of each type 5 batch header record. In a text editor that means counting characters, which is tedious and error prone across a file with many batches. The faster approach is to convert the file so the batch header fields become columns, then filter. A NACHA file to Excel converter carries the batch level fields, including the SEC code and the company entry description, down onto every entry, so you can pivot by description and SEC code and see immediately whether any PPD credit batch is missing PAYROLL.

That pivot is the whole audit, and it is worth running once against a recent production file even if you believe your payroll system was updated. The gap that shows up most often is not the main payroll run, which vendors updated, but a secondary process: an off-cycle bonus file, a correction run, or a batch produced by an older internal script that nobody remembered generates ACH entries.

Who is responsible for getting this right?

The originator. If you send ACH files to your bank, the description is yours to set, and your payroll or ERP system is where it gets populated. If a third-party payroll provider originates on your behalf, they are handling it, but it is still worth confirming rather than assuming, particularly for any off-cycle or manual runs that go through a different path than the regular cycle.

What else changed in the 2026 NACHA rules?

The entry description change landed alongside a broader set of risk management rules focused on fraud monitoring. Phase 1 took effect on March 20, 2026, requiring fraud monitoring processes for all ODFIs, plus larger non-consumer originators, third-party senders and service providers, and larger receiving institutions, with the thresholds based on 2023 volume. Phase 2 extended the requirement in June 2026 to all non-consumer originators, third-party senders and service providers, and all receiving institutions regardless of volume.

Separately, and often confused with these dates: the Same Day ACH limit is still $1 million per payment. NACHA has approved an increase to $10 million, but it does not take effect until September 17, 2027, so anything you read describing a $10 million limit as current is premature.

Common company entry descriptions and when they apply

Outside the two mandated cases the field remains free text, but a handful of descriptions have become conventional, and using the expected one reduces support calls from people who do not recognize a charge. This is how the common ones line up.

Note the REVERSAL row, since it catches people out. When you reverse an entry or a whole file, the description is not optional decoration: it identifies the batch as a reversal, and NACHA rules put tight timing limits on when a reversal may be sent at all. If your process produces corrections by originating an offsetting entry without marking it as a reversal, that is worth reviewing at the same time as the payroll audit.

A short checklist

• Pull a recent production ACH file and convert it so batch fields become columns.
• Pivot by SEC code and company entry description.
• Confirm every PPD credit batch paying wages carries PAYROLL.
• Confirm every WEB debit batch for e-commerce purchases carries PURCHASE.
• Check off-cycle, correction, and manual runs separately from the main cycle.
• Confirm batches are split where two descriptions are now required.

If a batch is wrong, fix it in the system that generates the file rather than editing the file, since hand-editing a NACHA file breaks control totals and hashes. Our guide on validating a NACHA file before sending it to the bank covers those structural checks, and once the payments post, the bank statement reconciliation side matches them back. Payroll teams that also need to keep the underlying pay records as structured data can pull them out with a document data extraction platform.