Skip to content
LegacyFile
← Learn

What Is a NACHA File? ACH Batch Files Explained

By LegacyFile ·

Your bank or payroll provider handed you a file called something like PAYROLL_0714.ach, you opened it, and every line is the exact same length with no commas, no headers, nothing that looks like a column. That's a NACHA file — the format that actually moves money through the ACH network — and once you know where the field boundaries fall, it's completely readable. This article explains what's inside one and how the pieces fit together.

What a NACHA file is

NACHA is a fixed-width format: there are no delimiters at all. Every field lives at an exact character position, and every physical line is exactly 94 characters. It's named after NACHA (the National Automated Clearing House Association), the organization that governs the ACH network's operating rules — this file format is the literal set of instructions a bank's ACH origination system submits to move a batch of payments.

That rigid layout is why NACHA files look unreadable at a glance: 622121000248112233445 isn't gibberish, it's a transaction code, a routing number, and the start of an account number, all packed together with zero separators. A parser that knows the field widths reads it instantly; a text editor just shows you a wall of digits.

How a NACHA file nests

Like BAI2 and EDI, NACHA nests: a file contains one or more batches, and each batch contains entries (individual transactions), each of which can optionally carry an addenda record with extra remittance text. Every level opens with a header and closes with a control (trailer) record:

101 121000248 9876543212607141200A094101FIRST NATIONAL BANK    ACME CORPORATION
5200ACME CORP                           9876543210PPDPAYROLL         260715   1121000240000001
6221210002481122334455       0000150000EMP001         JANE DOE                0210002480000001
622071000513998877           0000250000EMP002         JOHN SMITH              1210002480000002
705INVOICE 8842 PAYMENT FOR JULY SERVICES                                          00010000002
820000000300503000900000000000000000004000009876543210                         121000240000001
900000100000100000003005030009000000000000000004000000

Reading it by record type:

  • 1 — File header. Immediate destination (the receiving bank) and immediate origin (the sending company/bank), plus the file's creation date and time.
  • 5 — Batch header. Starts one batch: the company name and ID, the Standard Entry Class (SEC) code — PPD here, meaning a consumer payroll/deposit batch — and the effective entry date the payments should post.
  • 6 — Entry detail. One transaction each. The two-digit transaction code (22 in both examples above) says what kind of movement this is; 22 is a checking account credit — a deposit. Then the receiving bank's routing number, the account number, the amount (in cents, no decimal point — 0000150000 is $1,500.00), and the receiver's name.
  • 7 — Addenda. Optional extra text tied to the entry detail record immediately before it — here, remittance info explaining what the payment was for.
  • 8, 9 — Trailers. Close the batch and file with control totals: how many entries, an entry hash (a checksum built from the routing numbers, used to catch corruption — not a dollar total), and the total debit and credit dollar amounts.

Transaction codes, decoded

The two-digit code on every entry detail record follows a consistent pattern. The account type determines the base number — checking starts at 20, savings at 30, general ledger at 40, loan accounts at 50 — and the last digit says what kind of movement:

  • 2 — a credit (money moving in: a deposit or payment received)
  • 7 — a debit (money moving out: a withdrawal or payment collected)
  • 3 / 8 — a zero-dollar prenotification verifying an account is valid before real money moves on that account

So 22 is a checking credit, 27 is a checking debit, 32/37 are the savings equivalents, and 23/28/33/38 are prenotes. Once you know this pattern, you can read the transaction type of any entry at a glance.

Getting a NACHA file into a spreadsheet

None of this is meant to be read line by line for more than a handful of transactions. The free NACHA Viewer here on LegacyFile runs entirely in your browser — the file is never uploaded, which matters given what's inside (routing and account numbers). Drop the file in and it validates the control totals, translates every transaction and SEC code to plain English, links addenda records to their entries, and flattens everything into one row per entry you can export as CSV, XLSX, or JSON.

If you're troubleshooting a payment that came back rejected rather than reading an outbound file, the return uses a completely different code system — see NACHA return codes explained.