What Is a NACHA File? The ACH Payment Format Explained

If you've ever processed payroll, received a direct deposit, or worked with bank transfers in bulk, you've probably encountered a NACHA file — even if you didn't know what it was called. These files sit quietly behind some of the most common financial transactions in the United States, yet most people outside of accounting or fintech have never heard the term.

Here's what they actually are, how they work, and what determines how they're used in practice.

What a NACHA File Actually Is

A NACHA file (sometimes called an ACH file) is a specially formatted text file used to initiate and process Automated Clearing House (ACH) transactions — the electronic network that handles direct deposits, bill payments, and bank-to-bank transfers in the U.S.

The name comes from NACHA (the National Automated Clearing House Association), the organization that governs the ACH network and defines the strict formatting rules these files must follow.

When a company wants to pay 500 employees via direct deposit, it doesn't send 500 individual bank transfer requests. Instead, it creates a single NACHA file that batches all 500 transactions together and submits it to its bank (called an Originating Depository Financial Institution, or ODFI). The bank then routes those transactions through the ACH network to the appropriate receiving banks.

How a NACHA File Is Structured

NACHA files are fixed-width text files — meaning every line is exactly 94 characters long. There are no commas, no tabs, no XML tags. Just rigid, positional formatting where every character position has a defined meaning.

The file is organized into a hierarchy of records:

Each file can contain multiple batches, and each batch can contain multiple entry detail records. This structure lets a single file carry thousands of transactions at once.

What Information Goes Inside

Each Entry Detail record contains the core data needed to move money:

• Routing and transit number of the receiving bank
• Account number of the recipient
• Transaction code (indicating whether it's a checking credit, savings debit, etc.)
• Dollar amount
• Individual name (the recipient's name, up to 22 characters)
• Individual ID number (an internal reference)
• Trace number (a unique identifier for the transaction)

The transaction code is particularly important — it specifies not just the account type but the direction of the transaction. A code of 22 means a credit to a checking account (like a payroll deposit). A code of 27 means a debit from a checking account (like a bill payment pull). Getting this wrong causes rejections.

Who Creates and Uses NACHA Files 🏦

NACHA files aren't something individuals generate by hand. They're typically produced by:

• Payroll software (like ADP, Gusto, or enterprise HR systems) when processing direct deposit runs
• Accounting platforms that handle vendor payments or batch invoicing
• Banks and payment processors that offer ACH origination services
• Custom-built financial systems at larger organizations that need direct control over batch payment processing

The people who interact with NACHA files directly are usually payroll administrators, treasury analysts, accounts payable teams, and fintech developers building payment infrastructure.

Common Transaction Types Carried in NACHA Files

ACH transactions cover a wide range of use cases, and NACHA files batch them by Standard Entry Class (SEC) code:

• PPD (Prearranged Payment and Deposit) — Used for consumer direct deposits and recurring personal debits
• CCD (Corporate Credit or Debit) — Business-to-business payments
• CTX (Corporate Trade Exchange) — B2B payments with structured addenda data
• WEB (Internet-Initiated) — Payments authorized online
• TEL / ARC / POP — Phone-authorized or check-conversion transactions

The SEC code appears in the Batch Header record and tells the receiving bank how the payment was authorized. Using the wrong SEC code is a compliance issue, not just a formatting error.

The Variables That Change How This Works in Practice

The NACHA format is fixed — but how organizations generate, validate, and submit these files varies considerably based on several factors:

Volume and frequency matter a lot. A small business running payroll twice a month has very different needs than a large enterprise submitting ACH files daily. Some banks accept files via secure FTP; others use web portals or API connections.

Same-day ACH vs. standard ACH is a meaningful distinction. Standard ACH typically settles in one to two business days. Same-Day ACH, introduced by NACHA to modernize the network, settles within the same business day but has per-transaction dollar limits and requires explicit support from the originating bank.

Validation and prenoting add complexity for some organizations. A prenote is a zero-dollar test transaction sent before a live payment to verify that an account and routing number are valid. Some systems do this automatically; others skip it and handle rejections reactively.

File generation method varies by technical setup. Some teams use dedicated ACH file generators or libraries (there are open-source tools in Python, Java, and other languages). Others rely entirely on their payroll or ERP platform to handle the file invisibly.

Error handling looks very different depending on the originator's system. Return codes — like R01 (insufficient funds) or R03 (no account) — come back from the ACH network, and how those get surfaced and managed depends entirely on the software and processes in place.

Why the Format Has Stayed Rigid for Decades ⚙️

The 94-character fixed-width format feels archaic next to modern APIs and JSON payloads — and it is, by design. The ACH network connects thousands of financial institutions, and the rigid format guarantees that any compliant file can be processed by any participant without custom parsing logic. Interoperability at scale requires that kind of strictness.

NACHA does update its rules periodically (same-day ACH being the most significant recent change), but the core file structure has remained stable because changing it would require coordinated updates across the entire U.S. banking system simultaneously.

Whether a NACHA file is the right approach for a given payment workflow — versus a modern payment API, wire transfer, or card network — depends on transaction volume, timing requirements, the technical capabilities of the systems involved, and the banking relationships already in place. 🔍