NACHA file format explained, record by record

A NACHA file (also called an ACH file) is a plain-text file that a US business uploads to its bank to send many ACH payments at once – payroll direct deposits, vendor payments or collections. Every line is a record of exactly 94 characters, and the first character says what kind of record it is. Banks reject files where a single line is too short, a total is off by one cent, or the hash does not add up.

This guide walks through a real two-payment payroll file, produced by our NACHA file generator and checked by an independent parser. Field positions follow Nacha's own ACH Guide for Developers.

The example file

101 02100002111234567892610020930A094101JPMORGAN CHASE         EXAMPLE CORP
5220EXAMPLE CORP                        1123456789PPDPAYROLL         261005   1021000020000001
622021000021123456789        0000150000EMP001         JANE DOE                0021000020000001
632011000015987654321        0000225050EMP002         JOHN SMITH              0021000020000002
822000000200032000030000000000000000003750501123456789                         021000020000001
9000001000001000000020003200003000000000000000000375050
9999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999
...                                     (filler lines up to a multiple of 10)

Trailing spaces are not shown; in the real file every line is padded to 94 characters. The routing numbers are well-known public examples, the account numbers are made up.

The structure

1 – File header

5 – Batch header

• Service class code (2–4): 220 credits only, 225 debits only, 200 mixed. A payroll file without an offset line is 220.
• Company name (5–20, 16 characters): what employees or vendors see on their statement.
• Company identification (41–50): usually 1 + your 9-digit EIN, but your bank assigns it.
• SEC code (51–53): PPD for payments to consumer accounts (payroll), CCD for business accounts (vendors). Others such as WEB, TEL, CTX and IAT have their own rules.
• Entry description (54–63): for example PAYROLL or VENDOR PMT.
• Effective entry date (70–75, YYMMDD): the banking day you want the payments to settle. Positions 76–78 (settlement date) stay blank; the ACH operator fills them in.
• Originating DFI (80–87): the first 8 digits of your bank's routing number, then the batch number (88–94).

6 – Entry detail (one per payment)

6 22 02100002 1 123456789         0000150000 EMP001          JANE DOE               00 0 021000020000001
│ │  │        │ │                 │          │               │                      │  │ └ trace number (ODFI + sequence)
│ │  │        │ │                 │          │               │                      │  └ addenda indicator
│ │  │        │ │                 │          │               └ receiver name (22)   └ discretionary data
│ │  │        │ │                 │          └ identification number (15)
│ │  │        │ │                 └ amount in cents (10 digits) = $1,500.00
│ │  │        │ └ account number (17, left-aligned)
│ │  │        └ check digit (9th routing digit)
│ │  └ receiving bank routing, first 8 digits
│ └ transaction code
└ record type

Spaces added between fields for readability; the real line has none.

The transaction code says which kind of account and which direction:

Amounts have no decimal point: 0000150000 is $1,500.00. The routing number is split: 8 digits plus the check digit, which must pass the ABA checksum (weights 3, 7, 1).

8 – Batch control and the entry hash

The entry hash (positions 11–20) is the sum of the 8-digit receiving-bank numbers of all entries, keeping only the last 10 digits. In the example: 02100002 + 01100001 = 03200003, written as 0003200003. Then come total debits (21–32) and total credits (33–44) in cents: 000000375050 = $3,750.50. The company ID and batch number must repeat the batch header exactly.

9 – File control and blocking

The file control repeats the totals for the whole file, adds the batch count and the block count. NACHA files are written in blocks of 10 records ("blocking factor 10"). If the number of lines is not a multiple of 10, the file is padded with lines of 94 nines. Our example has 6 real records, so 4 filler lines are added and the block count is 000001.

Common reasons a bank rejects a NACHA file

• A line shorter or longer than 94 characters (often trailing spaces removed by an editor, or Windows/Excel adding extra characters).
• Entry hash or totals in the 8 or 9 record that do not match the 6 records.
• A routing number with a wrong check digit, or an account number longer than 17 characters.
• Wrong company ID or immediate origin – each bank has its own expectation.
• Balanced vs. unbalanced: some banks want an offset entry that debits your own account for the total (service class 200); most add it themselves.
• An effective date on a weekend or holiday. ACH settles on banking days, so check how your bank treats such a date.

Our files pass structural checks (record lengths, hash, totals, blocking) with an independent parser. They have not been run through every bank's ACH validator, so send a small test file or a prenote the first time.

Sources

• Nacha – ACH Guide for Developers: ACH file details (record layouts)
• Nacha Operating Rules, Appendix Three (full record specifications)

Related guides

• How to create a NACHA ACH file from Excel
• The ABA (Cemtex) bulk payment file, explained
• SEPA XML file rejected: what the error codes mean and how to fix them

Published 2026-10-03 by Karuna Labs. Our tools check file structure and checksums; always review outputs (and payment files in your bank's preview) before relying on them. This is general information, not financial, tax or legal advice.