What Is a NACHA File? The Fixed-Width ACH Format Explained

A NACHA file is a fixed-width text instruction for ACH payments. It is not CSV and it is not XML: every record is exactly 94 characters, and the meaning of a value depends on its position. A correctly spelled account name in the wrong character range is still malformed if it shifts the amount, routing number, or control total one position to the left or right.

The record sequence this generator supports

The generator creates one homogeneous batch per file. It writes the following record types and, when remittance information exists, an optional addenda record after the related entry:

Why 94 characters changes everything

Each field has a fixed start position and width. Numeric values are right-aligned and zero-filled; text values are left-aligned and space-filled. The generator explicitly asserts that every line is 94 characters long, writes a 10-record blocking factor, and pads a short final block with 94-character rows of 9s.

1... File Header
5... Batch Header
6... Entry Detail
7... Optional Addenda
8... Batch Control
9... File Control
999999... Block padding, if needed

PPD, CCD, and Salary Mode

The product supports two configured Standard Entry Class codes:

• PPD is the consumer-account preset for payroll and direct deposit. Salary Mode uses PPD.
• CCD is the corporate/business-account preset for vendor payments.

The selected SEC code is file-level configuration, not a per-row Excel field. The same is true of the company identification, ODFI routing number, immediate origin/destination, effective entry date, payment direction, and account-type default. Per-row mapping supplies the receiving routing number, receiving account, amount, receiver name, optional individual ID, and optional remittance.

What the generator calculates for you

• It validates each receiving routing number as exactly nine digits and checks its ABA check digit.
• It selects checking or savings credit/debit transaction codes from the file-level payment direction and account type.
• It calculates entry/addenda counts, entry hash, debit/credit totals, trace sequences, and the file block count.
• It rejects a single amount that cannot fit in the 10-digit cents field instead of truncating it.

Why hand-formatting from Excel is risky

Excel is useful for source data, but it is a poor fixed-width file editor. It removes meaningful leading zeros, does not preserve trailing spaces reliably, and gives no natural protection against a 95-character line. A manual formula can also leave file-control totals, the entry hash, or ten-row padding stale after one payment changes.

Use Excel for the business data, map the required columns, and let the converter format the records and calculate controls. If a bank already rejected a file, use the NACHA validator to inspect its record and field positions before changing the source data.