NACHA File Format
Read the fixed-width record hierarchy, field roles, control calculations, and padding rules used in an ACH payment file.
The 94-character record hierarchy
A NACHA file is plain text. Every physical record is exactly 94 characters. One file contains one or more batches, each batch contains Entry Detail records, and eligible entries may be followed by Addenda Records. Batch and File Control records reconcile the hierarchy.
| Type | Record | Purpose |
|---|---|---|
| 1 | File Header | Destination, origin, creation time, and transmission settings. |
| 5 | Batch Header | Company, SEC code, description, effective date, and ODFI. |
| 6 | Entry Detail | Routing, account, transaction code, amount, receiver, and trace number. |
| 7 | Addenda Record | Payment information or specialized Return and NOC data. |
| 8 | Batch Control | Entry count, routing hash, debit and credit totals, and identifiers. |
| 9 | File Control | Batch count, block count, entry count, hash, and file totals. |
File Header and Batch Header fields
The type 1 File Header identifies the immediate destination and origin, records when the file was created, and carries transmission settings such as the file ID modifier, record size, blocking factor, and format code. These values often come from the ODFI rather than the payment spreadsheet.
Each type 5 Batch Header identifies the company and payment purpose. It contains the service class, company name and ID, Standard Entry Class code, Company Entry Description, effective entry date, ODFI identification, and batch number. The SEC code applies to every entry in that batch.
Entry Detail and Addenda Records
A type 6 Entry Detail carries the receiving routing number, account number, amount, receiver identification, receiver name, discretionary data, addenda indicator, and trace number. Fixed positions matter: inserting or removing one character can shift every field that follows.
The transaction code identifies checking or savings and credit or debit. Common examples include 22 for checking credit, 27 for checking debit, 32 for savings credit, and 37 for savings debit. It is separate from the batch-level SEC code.
A type 7 Addenda Record follows its related entry and carries payment-related information or specialized Return and Notification of Change data. Eligibility, content, sequence fields, and allowed record counts depend on the SEC code and use case. Use the ACH addenda builder to inspect supported entry relationships.
How control totals reconcile the file
Batch-level checks
A type 8 Batch Control repeats the service class and company identification, counts Entry Detail and Addenda Records, totals debits and credits, and stores the batch entry hash. Its batch number should match the opening Batch Header.
File-level checks
The type 9 File Control totals all batches. It stores the batch count, block count, combined entry and addenda count, entry hash, and file-wide debit and credit totals. The entry hash is built from the first eight routing digits and retains the low-order ten digits.
Block count, padding, and line endings
The blocking factor is normally ten. After the File Control, all-9 padding records bring the physical record count to a multiple of ten. Padding records must still be 94 characters and are included in the block count, but not in the entry and addenda count.
Line endings separate physical records but are not part of the 94 characters. CRLF and LF handling can vary by bank channel. A validator should report the detected structure rather than silently treating a wrapped or truncated line as a valid payment record.
Formatting errors that affect downstream processing
- A record is shorter or longer than 94 characters.
- A Batch Header is not closed by the matching Batch Control.
- An Addenda Record is detached from its Entry Detail.
- Counts, entry hashes, debit totals, or credit totals do not reconcile.
- Trace numbers do not follow the expected ODFI and sequence structure.
- The File Control is followed by the wrong number of padding records.
Review an example with the sample NACHA file and check an actual file with the ACH file validator. Confirm bank-specific identifiers and transmission requirements with the ODFI before operational use.
Where can you continue learning or build a file?
Which authoritative sources support this page?
Technical explanations are checked against these primary sources. Bank-specific requirements can be narrower than general format guidance.
- Nacha ACH File Details — Official record-field guidance, including Batch Header SEC codes and addenda capabilities.
- Nacha ACH File Overview — Official explanation of files, batches, entries, controls, and batch grouping.
- Nacha: How ACH Works — Official overview of ACH participants, consumer and corporate payments, and authorization responsibilities.
- Nacha Operating Rules Topics — Current rule changes and implementation topics published by Nacha.
Sources reviewed August 20, 2026. Nacha owns and maintains the linked materials.
Frequently asked questions
How long is each ACH record?
Every physical record is exactly 94 characters. A short or long line shifts field positions and should be corrected before the file is transmitted.
Why are type 9 records repeated at the end?
After the File Control, additional all-9 records pad the physical record count to a multiple of ten. They do not represent payments.
What is the difference between an SEC code and a transaction code?
The SEC code classifies a batch by payment application and authorization context. The transaction code classifies an individual entry by account type and credit or debit direction.
Can one file contain several SEC codes?
Yes. A file may contain several batches, and each batch may use its own SEC code. Entries with different SEC codes cannot share one batch.
Does a structurally valid file guarantee bank acceptance?
No. An ODFI can impose enrollment, identifier, effective-date, balancing, and transmission requirements beyond structural checks.