ACH File Format: Record Types, Key Fields, and Same-Day Rules

The ACH file format is a fixed-width plain-text specification, maintained by Nacha, that tells banks how to move money electronically between U.S. accounts. Every line is exactly 94 characters, every field sits at a predetermined position, and the whole file is organized as a set of nested records identified by a single-digit code at the start of each line. The ACH network moved over 35 billion payments worth $93 trillion in 2025, and every one of them traveled inside a file built to these rules.¹ Nacha writes and enforces the operating rules that govern the format, and every bank, credit union, and payment processor in the network follows them.²

The 94-Character Line and Blocking Factor

Every line in an ACH file is exactly 94 characters long. There are no commas, tabs, or other delimiters. Each piece of information occupies a predetermined position on the line, and the file uses only plain ASCII text.³ When a data field doesn’t fill its allotted space, the remaining characters are padded. Alphanumeric fields such as account names are left-justified and filled with trailing spaces. Numeric fields such as dollar amounts are right-justified and filled with leading zeros.

ACH files also use a blocking factor of 10, meaning the total number of lines must be a multiple of ten. When a file naturally ends at line 23, seven additional lines filled entirely with the digit 9 are appended to bring the count to 30.³ These padding lines contain no real data. The blocking requirement dates back to tape-based batch processing, and the Federal Reserve’s systems still enforce it.

Record Type Hierarchy

An ACH file is structured as a set of nested envelopes, each identified by a single-digit record type code at the start of the line. The outermost envelope holds the entire file. Inner envelopes group related transactions into batches, and inside each batch sit the individual payment instructions. The nesting looks like this:

1 – File Header Record (one per file, at the top)
5 – Batch Header Record (one per batch)
6 – Entry Detail Record (one per transaction)
7 – Addenda Record (optional, follows an entry)
8 – Batch Control Record (one per batch, closes the batch)
9 – File Control Record (one per file, at the bottom, plus 9-filled padding lines)

Getting this nesting wrong is the fastest way to produce a file every bank will reject.

File Header and File Control

The file always opens with a single File Header Record, marked by the digit 1 in position one. This line identifies the sending and receiving financial institutions using their routing numbers, stamps the file with a creation date and time, and sets the record size at 094 and the blocking factor at 10.³ A File ID Modifier field (a single letter or digit) lets an originator send multiple files to the same destination on the same day without collision.

At the bottom of the file sits the File Control Record, starting with the digit 9. It tallies every batch’s worth of data into cumulative totals: the number of batches, the total entry and addenda count, a combined entry hash, and the sum of all debits and credits across the entire file.³ If any of these totals disagree with the actual records above, the receiving system flags the file as corrupt.

Batch Header and Batch Control

Between the file-level records sit one or more batches. Each batch begins with a Batch Header Record (digit 5) and ends with a Batch Control Record (digit 8). The Batch Header identifies the originating company, sets the Standard Entry Class code that governs the transactions inside, and provides the effective entry date.³ Batches let a single company separate payroll credits from vendor debits, or split consumer transactions from corporate ones, within the same file.

The Batch Control Record sums up the entry count, total debits, total credits, and an entry hash for only the entries inside that batch.³ These batch-level totals feed into the file-level totals in the File Control Record, creating a chain of checksums. Alter a dollar amount in a single entry, and the batch total won’t match, the file total won’t match, and the discrepancy triggers a rejection before any money moves.

Entry Detail and Addenda

The Entry Detail Record (digit 6) is where the actual payment instructions live. Each line represents one transaction: a credit or debit to a specific bank account. These records are the most numerous part of any file and carry the routing number, account number, dollar amount, and individual name for each receiver.³

Some entries include an optional Addenda Record (digit 7) immediately following the detail line. The addenda provides up to 80 characters of freeform payment-related information, such as an invoice number or remittance detail. Whether that information actually reaches the recipient depends on their bank’s systems; not all banks display addenda data in online banking or statements. For PPD, CCD, and WEB entries, only one addenda record is allowed per entry. Corporate Trade Exchange (CTX) entries are the exception, supporting up to 9,999 addenda records for detailed remittance data.⁴

Standard Entry Class Codes

The three-letter Standard Entry Class (SEC) code in each Batch Header Record determines which authorization rules, consumer protections, and processing requirements apply to every entry in that batch. Using the wrong code isn’t cosmetic. Nacha enforces compliance through a formal system of warnings and fines.⁵ The most common codes break down by who authorized the payment and how.

PPD (Prearranged Payment and Deposit) is the workhorse code for consumer transactions where written authorization exists. Direct deposit payroll, recurring mortgage payments, and insurance premiums all use PPD.⁴
CCD (Corporate Credit or Debit) is used for business-to-business payments such as vendor invoices, cash concentration between a company’s own accounts, and funding disbursement accounts.⁴
WEB (Internet-Initiated/Mobile Entries) covers debit entries authorized online or through a mobile device, along with person-to-person credit transfers. WEB triggers additional fraud-detection requirements because internet-based authorizations are harder to verify than signed paper forms.⁴
TEL (Telephone-Initiated Entries) applies to single or recurring debits authorized orally over the phone. TEL entries cannot carry addenda records.⁴

Routing a consumer internet authorization through a CCD batch instead of WEB strips the transaction of the fraud-detection requirements that WEB mandates and can trigger a Nacha rules enforcement action even when the payment itself processes successfully.⁵

Key Fields in the Entry Detail Record

The Entry Detail Record packs all the information needed to route a payment into a single 94-character line. Getting these fields right is the difference between a clean settlement and an expensive return.

Routing Number and Check Digit

ABA routing numbers are nine digits long.⁶ In the Entry Detail Record, the first eight digits of the receiving bank’s routing number occupy one field (the Receiving DFI Identification), and the ninth digit sits in a separate one-character Check Digit field. That ninth digit is calculated by multiplying each of the first eight digits by repeating weights of 3, 7, and 1, then summing the results. The check digit is whatever value brings that sum to the next multiple of ten. This catches most single-digit typos and about 90 percent of transposition errors.

Account Number

The DFI Account Number field is 17 characters wide and alphanumeric. It is left-justified and padded with trailing spaces when the actual account number is shorter than 17 characters. A common mistake is zero-padding this field on the right, which can cause the receiving bank to interpret the zeros as part of the account number and reject the entry.

Amount and Transaction Code

The transaction amount is stored in cents with no decimal point. A payment of $1,250.00 appears as 0000125000 in a ten-character field. A two-digit Transaction Code tells the receiving bank what to do with the money and which type of account to apply it to:

22 – Credit to checking (deposit)
27 – Debit from checking (withdrawal)
32 – Credit to savings
37 – Debit from savings
23 / 33 – Prenotification for checking / savings (zero-dollar test entries)

Swapping a 22 for a 32 sends a payroll deposit into someone’s savings account instead of checking. Swapping a 22 for a 27 turns a deposit into a withdrawal, which is far worse. File-building software should validate transaction codes before submission.

Entry Hash

The Entry Hash is an integrity check calculated by summing the first eight digits of every receiving bank’s routing number across all entries in a batch or file. If the sum exceeds ten digits, only the rightmost ten are kept. The hash has no financial meaning; its sole purpose is to confirm that no entry records were added, removed, or altered in transit.

File Balancing and Offset Records

Every ACH file must balance internally. The Batch Control Record sums all credits and all debits separately, and the File Control Record aggregates those sums across every batch. A file where total credits and total debits don’t reconcile will not pass validation at the originating bank or the Federal Reserve’s processing systems.

Some banks require balanced files where total debits exactly equal total credits within each batch. To achieve this, the originator includes an offset record that settles the difference into a single designated account at the originating bank. If a payroll batch contains $50,000 in credits to employee accounts, a $50,000 debit offset record pulls that money from the company’s funding account, bringing the batch to a net-zero balance. Whether offset records are required depends on the originating bank’s policies; some handle the settlement outside the file.

Same-Day ACH and the File Format

Standard ACH entries submitted to the Federal Reserve settle at 8:30 a.m. Eastern Time on the next business day.⁷ Same-Day ACH accelerates that timeline, but the file format itself does not change. The originating bank flags entries for same-day processing based on the effective entry date and the submission window.

Same-Day ACH files can be submitted through three daily windows:

Window 1 – submit by 10:30 a.m. ET, settles at 1:00 p.m. ET
Window 2 – submit by 2:45 p.m. ET, settles at 5:00 p.m. ET
Window 3 – submit by 4:45 p.m. ET, settles at 6:00 p.m. ET

The per-payment limit for Same-Day ACH is currently $1 million. Nacha announced in April 2026 that this limit will increase to $10 million, but that change does not take effect until September 17, 2027.⁸ Any single entry above the current limit must use standard next-day settlement or move through a different payment rail such as Fedwire.

Common Formatting Mistakes That Cause Rejections

Most ACH file failures come down to a handful of recurring errors.

Mismatched totals top the list. Manually editing an entry’s dollar amount without recalculating the Batch Control and File Control totals will fail validation before the file ever reaches the Federal Reserve. The same applies to the entry hash: adding or removing an entry without updating the hash produces a checksum mismatch. File-building software handles this automatically, but hand-editing a file bypasses those safeguards.

Line-length errors come next. Every line must be exactly 94 characters. An extra space, a missing padding character, or a line break in the wrong encoding (Windows-style CRLF versus Unix-style LF) can shift every field in subsequent lines by one or more positions, turning valid data into gibberish from the receiving bank’s perspective.

Account number formatting trips up originators who zero-pad instead of space-pad the DFI Account Number field. The field is alphanumeric and left-justified, so trailing zeros become part of the account number. A seven-digit account followed by ten zeros will not match the receiver’s actual account and will come back as an R03 (no account found) or R04 (invalid account number) return.

Protecting the File Itself

An ACH file sitting on a server contains raw bank account numbers and routing numbers for every payee in the batch. Nacha’s data security rule requires non-financial-institution originators, third-party senders, and third-party service providers whose annual ACH volume exceeds 2 million entries to render all stored account numbers unreadable.⁹ Organizations that cross the 2-million-entry threshold in any year must comply by June 30 of the following year.

Nacha is intentionally neutral on how you meet the requirement. Encryption, tokenization, truncation, and destruction are all acceptable methods.⁹ Financial institutions themselves are exempt from this specific rule because banking regulators already impose their own data security requirements. If you’re a payroll company, a property manager collecting rent via ACH, or a software platform originating payments on behalf of clients, the rule applies to you.

For file transmission, the industry standard is SFTP (Secure File Transfer Protocol), which encrypts data in transit. Many banks also require PGP digital signatures on uploaded files, which cryptographically verify both the sender’s identity and the file’s integrity. The signature confirms the file wasn’t altered between the moment it was created and the moment the bank received it. Keeping private signing keys in secure storage rather than plain-text configuration files is a basic but frequently overlooked step.

1
Nacha. ACH Network Volume and Value Statistics
2
Nacha. Nacha Operating Rules – New Rules
3
NACHA. ACH Guide for Developers – ACH File Overview
4
NACHA. ACH Guide for Developers – ACH File Details
5
Nacha. Compliance
6
American Bankers Association. ABA Routing Number
7
Federal Reserve Financial Services. FedACH Processing Schedule
8
Nacha. Same Day ACH Per Payment Limit to Increase to $10 Million
9
Nacha. Supplementing Data Security Requirements