PPD vs CCD: when to use each, and why a file that passes can be wrong

PPD vs CCD comes down to the receiving account: PPD (Prearranged Payment and Deposit) is the ACH Standard Entry Class code for a credit or debit to a consumer's account, such as payroll to an employee, and CCD (Corporate Credit or Debit) is the code for a credit or debit to a business's account, such as a payment to a supplier. The difficulty is that both are valid codes, so an ACH file with vendor payments coded PPD passes a format validator, reaches the network, and tells every receiving bank the wrong thing about the payment. Botminds' Treasury Management Onboarding checks each test file a new treasury client sends twice: against the Nacha format, and against what the payees are and what the client's signed schedule permits.

The worked example is a fictional sample client, Halvorsen Freight Systems, whose first test file to a fictional bank carried 38 vendor payments coded PPD. The rules come from Nacha, the non-profit that writes the ACH Operating Rules, and from the OCC, linked where they appear.

PPD vs CCD in one sentence each

Nacha's developer guide defines PPD as "a single or a recurring ACH credit or debit sent by an originator to a consumer account to make or collect a payment", and CCD as "a single or a recurring ACH credit or debit originated to a corporate account" (Nacha, ACH Guide for Developers). Everything else follows from that difference: the authorization each needs, the return rights that apply, and the information each can carry.

When to use PPD vs CCD: six common payments

Use PPD when the money lands in, or comes out of, an individual's personal account under a standing arrangement; use CCD when the account on the other side belongs to a business. The guide frames the code exactly that way: it indicates "whether the funds transfer affects a consumer account or a corporate account at the RDFI." The payer's own status does not matter. A business paying its employees uses PPD; the same business paying a supplier uses CCD.

Payroll providers show both classes working together. Nacha's risk staff describe them as third-party senders "that typically use CCD debits to pull from their employer customers, and use PPD credits to pay employees on expected cycles" (Nacha, Why are Exposure Limits So Important?). One payroll, two classes, because the accounts on the far side differ. Whether such a processor is a third-party sender changes what the bank owes Nacha; originator vs third-party sender sets out the test.

CCD vs PPD vs CTX

CTX is the third option, and it differs from CCD in the amount of information it can carry, not in who receives the payment. Both are corporate classes. CCD "can contain a single addenda record", while CTX "supports up to 9,999 addenda records" and is used "in trading partner relationships because a full ANSI ASC X12 message or payment-related UN/EDIFACT information can be sent" with it (Nacha, ACH File Details).

The practical test for a treasury client is what the supplier's receivables team needs. A payment covering one invoice fits a CCD with an addendum. A payment settling 140 invoices, with deductions, needs CTX, and a receiving business that cannot read CTX remittance from its bank will call the payer instead. Neither choice changes the consumer-or-corporate question; that is answered by the account.

What happens if you use the wrong SEC code?

Using the wrong SEC code misstates the payment to every bank that handles it, and the consequences land on the originating bank first. The rules leave no room for treating the code as a formality: "SEC codes must be applied correctly based on the application and Receiver (corporate vs. consumer)" (Nacha, RMAG Originator Essentials). Four things follow from a miscoded entry.

The return window is wrong. Corporate classes carry a two-day standard right of return and consumer classes a 60-day extended one. The OCC warns that on debits the originating bank carries credit risk from the moment it makes the funds available until the debit can no longer be returned (ACH origination credit risk sizes that window), and that banks "need to be aware of the extended return time frames for consumer debit transactions" (OCC Bulletin 2006-39). A consumer debit disguised as CCD hides two months of exposure.

The receiving bank may flag it. Since March 20, 2026, large receiving banks, and since June 2026 all of them, must run risk-based processes to identify credits authorized under false pretenses. Nacha's own FAQ names the first warning sign:

A Standard Entry Class Code that does not align with the type of receiving account, such as a corporate CCD entry to a consumer account.

Nacha, Fraud Monitoring Phase 1 FAQs, on what an RDFI may look for

A client's legitimate payments that look like that pattern invite questions, delays or returns from receiving banks that are now required to look.

It may breach the client's own agreement. Nacha's risk group notes that banks may limit SEC codes to match an originator's expected business needs. The OCC's underwriting standards likewise include a list of "permissible Standard Entry Class (SEC) types" for each originator, and Nacha's risk group counts a class the origination agreement does not permit among the anomalies exposure limits exist to catch (Nacha, 2025; the ACH origination agreement template shows the clause). And it attracts scrutiny. The OCC tells banks to check SEC codes from time to time, because miscoding is one way fraud is disguised (ACH fraud filter vs fraud monitoring quotes the bulletin).

Why a format validator passes a miscoded batch

A Nacha format validator checks that the file is well formed: 94-character records in the right order, numeric fields that are numeric, control totals that add up, and an entry class that is one of the valid three-character codes. PPD is a valid code. So is CCD. A validator cannot know that "MERIDIAN PARTS SUPPLY" is a business with a business account, because nothing in the file's structure says so.

That is what happened in the sample. The client's accounting system produced a file of 212 payments in two batches: 174 payroll credits for $266,410.00, correctly coded PPD and described PAYROLL, and 38 vendor payments for $146,450.00, also coded PPD. Every structural check passed. The client's signed schedule permitted both classes, so even a check against the permitted list would have passed. The error only shows when the class is compared with who the payees are.

Click a drafted setting and read the line the client signed

The payroll batch now has its own word: PAYROLL

Since March 20, 2026, the Nacha Rules require originators to use the Company Entry Description "PAYROLL" for "PPD credits for payment of wages, salaries and similar types of compensation" (Nacha, Company Entry Descriptions). The word must sit in the leftmost seven characters of the ten-character field in the batch header; the remaining three may carry the originator's own suffix. Nacha lists business-to-business vendor payments among the uses that must not carry it.

For a new treasury client the rule adds a second test to the PPD batch. An accounting system configured years ago may still describe payroll as "SALARY" or "WAGES", which a format check accepts. And a vendor batch miscoded as PPD must not borrow the payroll description, which would compound one error with another. A setup-aware check reads the class and the description together.

Can a business pay a consumer with CCD?

No. When the receiving account is a consumer's, the payment belongs in a consumer class, whatever the payer's reason. The common case is a small supplier, a sole trader paid into a personal account: the entry class follows the account it lands in, so the supplier list a client brings to onboarding should record account type, not only business name. Where a client cannot tell, it should ask the supplier, because a CCD credit to a consumer account is exactly the pattern Nacha now tells receiving banks to watch for.

The reverse case, consumer-class entries to business accounts, is the one in the sample, and it arises easily: a file built from a payroll template carries PPD into every batch unless someone changes it, so a client that adds vendor runs to an export first set up for payroll can send business payments under the consumer class.

Three checks a format validator cannot make

A validator built only on the Nacha file specification cannot make the three checks that catch a miscoded batch. Each needs information outside the file.

The fix, when one of these fails, is rarely technical. In the sample, the controller needed to change one setting on one batch. The hard part is saying so in words a controller recognizes, without turning the message into a lesson on Nacha field names.

The fix, written in the words the client's controller uses

The corrected file came back the same morning with the vendor batch coded CCD and passed in 36 seconds. The same test file also carried a second, unrelated error, a company identifier from the client's previous bank, which the guide to the ACH company ID explains. For how a validator and a setup-aware check differ in general, see what a Nacha file validation tool checks, and what it cannot; for the agreement that lists the permitted classes, the ACH origination agreement template. The solution itself is at Treasury Management Onboarding.

Questions people ask

Is payroll PPD or CCD?

Payroll credits to employees' personal accounts are PPD, and since March 20, 2026 they must carry the description PAYROLL. Moving money to fund a payroll account the company holds at another bank is CCD, because that account is corporate.

What does PPD stand for in ACH?

Prearranged Payment and Deposit. It covers single or recurring credits and debits to consumer accounts under a standing authorization, such as direct deposit of wages or a monthly utility debit.

What is the return time frame for CCD vs PPD?

Nacha's risk group summarizes it as two days for the standard right of return on corporate classes such as CCD, and 60 days for the extended right of return on consumer classes such as PPD. The difference is why a consumer debit miscoded as CCD understates the originating bank's exposure.

Can an ACH file be rejected for the wrong SEC code?

A file with a valid but wrong code is usually not rejected by format checks, because the code itself is valid. It can be stopped by the originating bank if the class is not permitted in the client's agreement, flagged by a receiving bank's fraud monitoring, or returned later. Catching it in testing is far cheaper than any of those.

Should vendor payments with invoice detail use CCD or CTX?

CCD carries one addenda record, enough for a short remittance reference. When a payment settles many invoices and the supplier expects an EDI remittance, CTX carries up to 9,999 addenda records. Both are corporate classes.