PPD vs CCD: Which NACHA SEC Code Should You Use?

An ACH payment file can have valid routing numbers, amounts, and control totals yet still be wrong for the intended receiver if its Standard Entry Class (SEC) code does not match the payment context. In this generator, the decision is deliberately simple: choose PPD for consumer-account payroll/direct-deposit use cases and CCD for corporate/vendor payments.

What the SEC code controls in this generator

The SEC code is a file-level setting, not an Excel column. The generator writes it in the Batch Header (record type 551-53, as the three-character Standard Entry Class Code. Every entry in the generated single batch therefore shares the same SEC decision.

Record type 5: Company/Batch Header
Positions 51-53: PPD or CCD

For the rest of the fixed-width record layout, see What Is a NACHA File? The Fixed-Width ACH Format Explained. This guide focuses on choosing the code before the file is built.

PPD: consumer accounts, payroll, and direct deposit

PPD (Prearranged Payment or Deposit) is the implemented consumer-account preset. Use it when the payment is going to or from an individual account, including payroll and direct deposit. The NACHA_PPD profile fixes the file-level SEC code to PPD; its default entry description is PAYROLL.

In the Entry Detail layout, the same positions are interpreted for PPD as an individual identification number and individual name. That matches the generator's payroll/direct-deposit preset, but it does not make a vendor payment a PPD transaction merely because the recipient name is a person's name.

CCD: corporate and vendor payments

CCD (Corporate Credit or Debit) is the implemented business-to-business preset. Use it for payments to corporate/business accounts, such as vendor or supplier payments. The NACHA_CCD profile fixes the file-level SEC code to CCD; its default entry description is VENDOR PMT.

The generator uses the same PPD/CCD Entry Detail layout, but the field at positions 40-54 is documented as a CCD identification number and positions 55-76 as the receiving company name. Keep the recipient type and selected profile aligned rather than treating the code as a label you can change after generation.

Decision table: who receives the payment?

Salary Mode and the SEC selection

For NACHA output, the SEC choice is exposed as a selectable payment type and defaults to PPD. Selecting CCD switches the active bank profile to NACHA_CCD. Salary Mode is not a separate hard-coded SEC assignment in the generator, so a payroll user should confirm that the selected NACHA payment type remains PPD before downloading.

This separation is intentional at the file-model level: SEC code comes from the bank profile, while receiving routing number, account number, amount, receiver name, optional ID, and remittance are mapped per row from Excel.

What happens when you choose the wrong code

The implementation does not invent bank return codes for an SEC mismatch. Operationally, selecting a code that does not reflect the receiver type can lead to a rejected or returned payment and a compliance review by the originating bank. Treat the SEC decision as part of payment classification, not a formatting preference.

• Do not use CCD just because a payroll payment is in a business file; classify the recipient/account context.
• Do not use PPD for a vendor simply because the vendor contact has a personal name.
• Do not mix the two populations into one generated batch and attempt to repair the Batch Header afterward.

What this tool does not support

The SEC enumeration, bank profiles, API validation, and generator support PPD and CCD only. CTX, WEB, TEL, and other SEC codes are not selectable or generated by this product. If your bank requires one of those classes, use a workflow that explicitly supports it rather than relabelling a PPD or CCD output.