What is the NACHA file format?

A NACHA file is unformatted ASCII text. Every record — every line — is exactly 94 characters long, with each field occupying a fixed position rather than being separated by commas or tabs. Opened in a text editor, a well-formed file looks like a wall of tightly packed letters and digits in neat 94-character rows.

The file is organized as one or more batches. Each batch groups entries that share the same originator, the same purpose, and the same Standard Entry Class code — a payroll run in one batch, vendor payments in another. This batch structure is why one file can carry your entire payment run in a single upload.

The format has been in continuous use for decades, which is precisely its value: every US financial institution on the ACH network reads the same structure, so a correctly built file works whether you bank with a national institution or a local credit union.

The format is defined by Nacha (originally the National Automated Clearing House Association), the body that administers the ACH network’s rulebook. The technical standard lives in the Nacha Operating Rules and Guidelines, which are updated on an annual cycle — the format itself changes rarely, but the rules governing how entries must be described and monitored change more often. Four rule changes take effect across 2026 alone; see our NACHA 2026 rule changes reference for the dates and what each one requires.

The network the files travel on is operated by two ACH operators: the Federal Reserve’s FedACH and The Clearing House’s Electronic Payments Network. As an originator you never deal with the operators directly — your bank does. What you deal with is your bank’s own layer of requirements on top of the standard: which portal accepts uploads, what cutoff times apply, and whether your file must be balanced. The format is national; the submission experience is bank-specific.

A NACHA file contains six functional record types, and understanding what each one does is enough to reason about most file problems without ever counting byte positions:

The file header opens the file and identifies who created it and for which bank. The batch header opens each batch and declares the originator, the Standard Entry Class code, and the description receivers will see. Entry detail records are the payments themselves — one per credit or debit, carrying the receiver’s routing number, account number, and amount. Addenda records optionally follow an entry to carry remittance detail. The batch control record closes each batch with entry counts and dollar totals, and the file control record closes the file with grand totals. Files are also padded to a multiple of ten lines, which is why a valid file often ends with rows of 9s.

The arithmetic matters more than the layout: the control records must exactly total the entries they summarize. Most rejections are failures of this internal bookkeeping, not exotic formatting errors.

What this page deliberately does not cover is the character-by-character field layout. Those specifications are published in the Nacha Operating Rules, and if you are hand-building files at that level you need the rules themselves, not a summary.

Every batch declares a Standard Entry Class (SEC) code, and for most small and mid-sized originators the choice is between two:

PPD (Prearranged Payment and Deposit) is for entries to personal bank accounts: payroll direct deposit, 1099 contractor compensation, expense reimbursements, and refunds paid to individuals. If the receiving account belongs to a person, the entry is PPD.

CCD (Corporate Credit or Debit) is for entries to business accounts: vendor invoices, rent paid to a company, franchise remittances, transfers between related companies. If the receiving account belongs to a business, the entry is CCD.

The deciding factor is the receiver’s account type, not yours. A sole proprietor paying an incorporated supplier sends CCD; a large corporation paying an individual contractor sends PPD. Getting it wrong is not cosmetic — consumer entries are covered by different authorization and return rules than corporate entries, and a receiver’s bank can return or dispute an entry sent under the wrong class.

Where CTX fits. CTX (Corporate Trade Exchange) is the third code you will hear about in business payments. Functionally it is CCD with structured remittance attached: a CTX entry can carry up to 9,999 addenda records holding invoice-level detail in EDI 820 syntax, so the full remittance advice travels inside the payment itself. It is standard in enterprise accounts payable, where trading partners exchange EDI. If your business does not produce EDI remittance data, you almost certainly want CCD, not CTX — the payment moves identically; CTX just adds a remittance envelope you would have nothing to put in. If a large trading partner has asked you to send CTX, that request is really about their remittance processing, and it is worth confirming whether they will accept CCD with the invoice reference in the entry’s addenda record instead.

PayFile Pro generates PPD and CCD batches — a single file can carry both, with payments to individuals in the PPD batch and payments to businesses in the CCD batch.

There is no free-text memo field on an ACH entry the way there is on a check. What the receiver sees on their bank statement comes mostly from two batch-level fields: the company name and the ten-character company entry description, such as PAYROLL, VENDOR, or EXPENSES. Every entry in a batch shares the same description, which is why ACH statement lines read like SALARY or INV PMT rather than a note about the specific payment.

Per-payment detail travels separately, in an entry’s addenda record — 80 characters of payment-related information, typically an invoice number or reference. Business receiving banks generally deliver addenda content to their customers; many consumer banks do not display it at all. Practical consequence: choose a company entry description your receivers will recognize, because for most of them it is the only context they get.

Note that the entry description is no longer entirely free-form: starting March 20, 2026, Nacha requires PPD credits paying wages or contractor compensation to use a description beginning with PAYROLL. The details and dates are in our NACHA 2026 rule changes reference.

Searches for a NACHA file template or example in Excel are common, and they usually come from a reasonable instinct: the payment data starts life in a spreadsheet, so the file should too. The data half of that instinct is right. The file half is not.

A NACHA file has no delimiters. Excel’s export formats — CSV, tab-delimited, even its fixed-width options — cannot reliably produce 94-character records with every field padded to its exact position. Worse, Excel silently destroys the data itself: routing and account numbers with leading zeros are truncated the moment a cell is formatted as a number, and the resulting file fails the routing number check digit at upload. A spreadsheet that looks perfect on screen can produce a file that is wrong in ways that are invisible until the bank rejects it.

The workable division of labor is: keep the payment data in a spreadsheet, and let software that understands the record layout write the file. That is how accounting-system ACH modules work, and it is how PayFile Pro works — you fill in a spreadsheet template, and the generator validates the data and writes the fixed-width file.

Every US bank on the ACH network processes the NACHA format — the format does not vary by bank. What varies is access and submission mechanics: file upload is generally a business or treasury banking feature that must be enabled on your account, and each bank sets its own portal workflow, cutoff times, and expectations such as whether files must be balanced.

We maintain bank-specific pages covering those submission details: JPMorgan Chase, Bank of America, Wells Fargo, U.S. Bank, PNC, and other US banks.

• Control totals that don’t add up. The batch and file control records must exactly match the count, dollar totals, and hash of the entries they close. Any hand edit to an entry that isn’t reflected in the totals fails validation.
• Invalid routing numbers. The ninth digit of an ABA routing number is a check digit computed from the first eight. A single mistyped digit — or a leading zero dropped by a spreadsheet — fails the check.
• Wrong record length. Lines that are not exactly 94 characters, stray blank lines, or the wrong line-ending convention for the bank’s system all cause rejects at upload.
• Effective date problems. An effective entry date in the past, too far in the future, or on a non-banking day gets flagged or silently adjusted depending on the bank.
• Origin values that don’t match bank setup. Banks validate the immediate origin and company ID fields against what they have on file for your account. A file that is internally perfect still rejects if these identifiers don’t match your bank’s records.
• Balanced-versus-unbalanced mismatch. Some banks require a balanced file containing your offsetting debit; others require an unbalanced file and create the offset themselves. Sending the wrong kind is a common first-upload failure.
• Duplicate file detection. Banks fingerprint files by creation date and file ID modifier. Re-uploading a corrected file without changing the modifier can trigger a duplicate reject.

There are three realistic paths.

• Accounting software or an ERP. Many mid-market systems can produce NACHA files through a built-in module or paid add-on. If your system supports it and it is already configured for your bank, use it.
• Your bank’s own tools. Some bank portals offer manual entry or their own template-based import, which avoids file formatting entirely but typically means rekeying data and living within the portal’s limits.
• A dedicated generator. PayFile Pro generates NACHA-compliant files from a spreadsheet template in your browser. Payment data is processed entirely client-side — it is not sent to any server — and you can preview a file for free without signing up. PayFile Pro generates payment files; it does not transmit them, process payments, or hold funds. You upload the finished file through your own bank portal.