What Is a NACHA File? Structure, Returns, and Security

A NACHA file is a standardized, fixed-width text file used to send payment instructions through the Automated Clearing House (ACH) network, and every ACH transaction in the United States, from payroll direct deposits to vendor payments to mortgage drafts, moves through this format. The format was developed by the National Automated Clearing House Association (now branded as Nacha) to replace paper checks with a uniform electronic alternative.1ACH Guide for Developers. ACH File Overview If you’re setting up direct deposit, paying vendors in bulk, or debiting customers on a schedule, the file your software produces and your bank accepts is a NACHA file.

How the File Is Structured

A NACHA file is plain ASCII text. Every line is exactly 94 characters, every character position has a defined purpose, and each line is called a record.1ACH Guide for Developers. ACH File Overview There is no XML, no JSON, no flexibility in spacing. A single misplaced character will cause the receiving system to reject the whole file, which is why precision matters more here than in almost any other business file format.

Files come in two flavors. A balanced file includes the offset (settlement) account inside the file itself, so credits and debits net to zero. An unbalanced file leaves the offset to the originating bank.1ACH Guide for Developers. ACH File Overview Most small and mid-sized businesses submit unbalanced files; larger organizations with multiple settlement accounts sometimes prefer balanced files for tighter internal controls.

The Six Record Types

Every file follows the same rigid sequence. Getting the structure wrong is the most common reason banks reject a file outright.

  • File Header Record (type 1). Always the first line, starts with “101.” Contains the routing number of the originating bank, a date-time stamp, and the company name.1ACH Guide for Developers. ACH File Overview
  • Batch Header Record (type 5). Starts with “5.” Groups similar transactions and specifies the Standard Entry Class (SEC) code, settlement date, and whether the batch contains credits, debits, or both.
  • Entry Detail Record (type 6). Starts with “6.” This is where the actual payment lives: recipient account number, routing number, name, dollar amount, and credit-or-debit indicator.
  • Addenda Record (type 7). Starts with “7.” Optional for most transactions, required for certain SEC codes. Carries supplemental data such as invoice numbers or payment descriptions.
  • Batch Control Record (type 8). Starts with “8.” Sums entry count and dollar totals for the batch and includes a hash total computed from routing numbers.
  • File Control Record (type 9). Always the last line. Tallies all batches, all entries, total credits, total debits, and another hash total for the entire file.

Those hash totals are the backbone of data integrity. They’re the sum of routing numbers across all entries, so if even one digit changes during transmission, the hash won’t match and the file is rejected. When a system moves trillions of dollars a year, there is no room for “close enough.”

What You Need to Build One

Before you can produce a file, you need specific data for the sender and every receiver. The originator supplies a Company Identification number in the Batch Header. This is commonly the company’s federal tax identification number, though Nacha rules also allow other identifiers assigned by the originating bank. For each recipient, you need their nine-digit ABA routing number and bank account number, usually captured through a signed authorization form or voided check.

Transaction amounts have to be exact to the penny. Rounding errors or miskeyed amounts create reconciliation problems that can trigger bank holds or secondary review. The transaction type (credit or debit) and account type (checking or savings) are set at the entry level, and getting the account type wrong is a surprisingly common cause of returns.

Standard Entry Class Codes

The SEC code in the Batch Header tells the network what kind of transaction this is and what authorization rules apply. The two codes you’ll see most often are PPD and CCD. PPD (Prearranged Payment and Deposit) covers transactions between a company and an individual consumer, such as payroll direct deposit or recurring bill payments authorized in writing. CCD (Corporate Credit or Debit) handles company-to-company payments like vendor invoices, cash concentration between business accounts, and funding of disbursement accounts.2ACH Guide for Developers. ACH File Details – Section: Commonly Used SEC Codes

Picking the wrong code is more than a formatting issue. Debiting a consumer account with a CCD code instead of PPD triggers return code R05 and counts toward your unauthorized return rate. Other codes cover telephone-authorized debits (TEL), internet-initiated entries (WEB), and international transactions (IAT), each with their own authorization and formatting requirements.

Authorization Records

Nacha rules require you to obtain and keep proof of authorization before originating any entry. For PPD, you need written authorization signed by the consumer. For TEL, you need either an audio recording of the verbal authorization or a confirmation letter sent before settlement, documenting the date, amount, customer name, account details, and revocation instructions. For WEB, you need a digital authorization capturing identity, assent, transaction terms, revocation instructions, and a timestamp.

Whichever code applies, Nacha requires authorization records to be kept for two years after the last transaction under that authorization. Losing them leaves you unable to defend against unauthorized return claims, which is where enforcement trouble usually starts.

Generating and Submitting the File

Very few organizations build NACHA files by hand. Most use payroll platforms, ERP systems, or accounting software that exports directly to the format. Standalone ACH file generation tools exist for businesses that need more control, and some banks offer their own file-creation portals, though those tend to work best at lower volumes. Whatever tool you use, the output is the same 94-character fixed-width file described above. Opening the file in a text editor before submission to eyeball record counts and batch totals catches errors cheaply.

Before sending live payments to a new account, you can submit a prenotification. A prenote is a zero-dollar entry that validates the recipient’s routing number, account number, and account type without moving any money.3Nacha. Micro-Entries Phase 1 If the account can’t be located, the prenote comes back as a return and you’ve caught the problem before it hit a real payment. Prenotes aren’t required by Nacha, but they’re a cheap way to avoid returns on a first run. An alternative is micro-entry validation using two small credit amounts the recipient confirms; Nacha rules require that the Company Name in micro-entries be recognizable to the recipient and match the name that will appear on future entries.

Finished files are transmitted to the originating bank through SFTP, a dedicated banking portal, or another secure channel the bank supports. The bank runs its own validation and either acknowledges the file or rejects it. Rejections at this stage are almost always formatting problems: wrong record count, hash mismatch, character out of position.

Timing matters. Standard ACH entries settle on the next business day after the bank forwards them to the network. Same-day ACH is available for transactions up to $1 million per payment4Federal Reserve Financial Services. Same Day ACH Resource Center but requires submission before one of three daily cutoff windows set by the Federal Reserve’s FedACH schedule: 10:30 AM ET, 2:45 PM ET, and 4:45 PM ET.5Federal Reserve Financial Services. FedACH Processing Schedule Miss a window and the entry rolls to the next one, or to the next business day if you miss the last cutoff. Banks typically charge a per-transaction fee for same-day processing on top of standard ACH fees.

Returns and What They Cost You

Not every entry completes. When a receiving bank can’t process one, it sends back a return with a reason code. The ones you’ll see most often:

  • R01 (Insufficient Funds): the account doesn’t have enough money.
  • R02 (Account Closed): the recipient closed the account.
  • R03 (No Account/Unable to Locate): the account number doesn’t match any account at that bank.
  • R04 (Invalid Account Number): the account number itself is structurally invalid.
  • R07 (Authorization Revoked): the consumer revoked their authorization.
  • R10 (Customer Advises Not Authorized): the consumer claims they never authorized the entry.
  • R29 (Corporate Customer Advises Not Authorized): same as R10, for business accounts.

Most returns (R01 through R04) must be processed by the receiving bank within two banking days of settlement. Unauthorized returns (R07, R10, R11, R29) get a much longer window of up to 60 calendar days from settlement, meaning an unauthorized claim can surface two months after you thought the transaction was final. That’s why authorization records matter.

Return Rate Thresholds

Nacha monitors three return-rate thresholds. Exceeding any of them puts your origination activity under review.

Breaching a threshold triggers review of your origination activity, and your bank may be directed to bring the rate down. The 0.5% unauthorized rate is the one that catches originators by surprise: five unauthorized returns out of a thousand debits puts you over. Fines for repeated or unresolved violations can run from hundreds of dollars to as much as $500,000 per month, and in serious cases Nacha can suspend origination privileges entirely.

Data Security for Stored Account Numbers

NACHA files contain bank account and routing numbers that have to be protected. Nacha rules require any non-bank originator, third-party service provider, or third-party sender processing more than 2 million ACH entries annually to render account numbers unreadable when stored electronically.8Nacha. Supplementing Data Security Requirements Organizations crossing the 2-million threshold in any calendar year have to comply by June 30 of the following year.

The requirement is technology-neutral. Encryption, tokenization, truncation, or having your bank store and tokenize account numbers on your behalf all satisfy it.8Nacha. Supplementing Data Security Requirements The volume count combines all ACH entries across every settlement account and every originating bank you use, so splitting volume across banks doesn’t help. Below 2 million entries the rule doesn’t technically apply, but protecting stored account data is still sound practice.

Two Boundaries Worth Knowing

International payments and consumer debits sit outside the standard rules in ways that trip up originators who assume the basics cover them.

When an ACH payment involves a financial institution outside the United States, the entry must use the IAT SEC code, carry extra addenda records identifying the foreign institution and parties, and be screened against OFAC sanctions lists by the originator before submission. OFAC penalties can include imprisonment for the responsible employee and civil fines reaching millions of dollars per violation.9NACHA. International ACH Transactions (IAT) Frequently Asked Questions – Corporate Customers

ACH debits from consumer accounts also fall under Regulation E (12 CFR Part 1005), which caps consumer liability for unauthorized transfers based on how quickly the consumer reports the problem.10Consumer Financial Protection Bureau. 12 CFR 1005.6 – Liability of Consumer for Unauthorized Transfers For originators, the practical takeaway is that consumers have strong legal backing to dispute unauthorized debits and their banks have up to 60 days to return those entries. No language in your authorization form overrides those limits, so clean authorization records and a low unauthorized return rate are the only real defense.