Every direct deposit, every automatic bill payment, every corporate disbursement your institution processes starts as a string of characters inside an ACH file. To your customers, that transaction is instant and invisible. To the operations team behind it, it is a precisely structured document with its own grammar, and getting that grammar wrong means returned entries, frustrated customers, and compliance exposure. Understanding ACH file format and technical specifications is not just exam material for the Accredited ACH Professional credential. It is the foundation that lets your team troubleshoot problems quickly, support customers with confidence, and keep the payment rails running smoothly under NACHA operating rules.
This week's BankersHub session, part nine of the ten part AAP exam prep series, took a close look at exactly this foundation. Whether you are studying for certification or simply want your frontline and operations staff to speak the same language as your processor, here is what you need to know about how ACH files are built, and why that structure protects everyone who relies on it.
Why File Structure Is More Than a Technicality
It is tempting to think of file format as back office minutiae, something for the technical team to worry about while everyone else focuses on the customer relationship. That thinking sells the topic short. Every ACH file is built from 94 character records, transmitted either unblocked or in blocked groups of ten, using ASCII or EBCDIC encoding. When financial institutions and originators coordinate testing for new files, or when a return reason code or entry description changes, that coordination depends on everyone understanding the same underlying structure. A single misaligned field can cause an entire batch to reject. Knowing the anatomy of the file means your team can diagnose that problem in minutes instead of escalating a mystery to a vendor and waiting on a callback. For compliance and audit purposes, that same structural knowledge helps you explain, with precision, exactly what happened to a transaction and why.
Inside the ACH Record Types
An ACH file is built like a set of nested envelopes, and understanding that sequence makes the whole system click. Nacha's file format defines six record types, each identified by its own type code. The file header (type 1) and file control (type 9) records bookend the entire file. Inside that, one or more batches appear, each opened by a company or batch header record (type 5) and closed by a batch control record (type 8). Within each batch live the entry detail records (type 6), the individual transactions, along with optional addenda records (type 7) that carry supplemental information tied to a specific entry. For every header record that opens a section, there is a matching control record that closes it, similar to the way opening and closing tags work in a markup language. Visualizing this nested structure, rather than memorizing a list, is what makes the specifications usable on the job, not just on an exam.
Mandatory, Required, and Optional: Getting the Field Designations Right
Not every field in an ACH record carries the same weight, and confusing the three designations is one of the more common sources of processing errors. Mandatory fields are essential; without them, an entry simply cannot process. Required fields are necessary for proper handling but will not, on their own, stop a file from processing if they are imperfect. Optional fields exist to support receiver identification and memo style data that add context without being critical to settlement. Knowing which category a field falls into changes how your team responds when something looks off. A missing mandatory field is a stop everything problem. A missing optional field might just mean a memo line displays blank on a statement. That distinction, understood clearly, keeps your team from either overreacting to a minor formatting quirk or underreacting to a genuine processing risk.
Reading Entry Detail and Batch Control Records
The entry detail record is where the transaction itself lives: routing numbers, account numbers, dollar amounts, and the transaction code that tells the receiving institution exactly what kind of entry it is handling. Standard transaction codes such as 22, 23, 27, 28, 32, 33, 37, and 38 cover common checking and savings deposit, payment, and prenotification scenarios, and being fluent in what each one signals is a quiet superpower for customer facing staff fielding questions about an unfamiliar transaction code on a statement. Trace numbers attached to each entry make it possible to follow a single transaction through the file even when it is bundled with thousands of others. Batch control records, meanwhile, act as an internal checksum. They tally entry and addenda counts and hash totals, giving processors a built in error detection layer before a batch is ever accepted. Standard Entry Class codes, the SEC designations like PPD, CCD, WEB, and TEL, are assigned at the batch header level and determine how an entire group of transactions is treated, which is why getting that single code right at the outset matters so much downstream. For a closer look at what happens when an entry cannot be processed, see our explainer guide on ACH returns.
File Control Records: The Final Checkpoint
If the batch control record is a checksum for a single batch, the file control record, the type 9 record, is the checksum for the entire file. It totals batch counts, block counts, entry and addenda counts, entry hash values, and aggregate debit and credit amounts across every batch the file contains. This is the last validation gate before a file is accepted for processing, and it is where discrepancies get caught before they become customer facing problems. Layered on top of this technical validation are the authorization and documentation requirements tied to specific payment types, particularly recurring PPD and CCD payments and web or phone initiated entries under WEB and TEL. Proper authorization records and fraud detection safeguards for these payment types are not just good practice. They are what examiners and Nacha's operating rules expect your institution to demonstrate.
Turning Technical Knowledge Into Everyday Confidence
None of this needs to feel intimidating. Once you see the file as a logical, nested structure rather than a wall of characters, the specifications start to make sense, and that clarity pays off every time a customer calls with a question, every time a file needs troubleshooting, and every time an examiner asks your team to walk through a transaction. Whether you are preparing for the AAP exam or simply building a stronger bench of ACH knowledge at your institution, investing the time to understand file format specifications is one of the most practical things a payments professional can do this year.
Frequently Asked Questions
How many record types are in an ACH file?
Nacha's ACH file format defines six record types, each identified by a type code: the file header (1), company or batch header (5), entry detail (6), addenda (7, optional), batch control (8), and file control (9). Each header record has a matching control record that closes out its section of the file.
What is the difference between mandatory, required, and optional fields in an ACH record?
Mandatory fields must be present for an entry to process at all. Required fields are necessary for proper handling but will not by themselves stop processing if imperfect. Optional fields carry receiver identification or memo style data that add context without affecting settlement.
What do ACH transaction codes like 22 and 27 mean?
Transaction codes identify the type of entry and account involved. Codes 22, 23, 27, and 28 apply to checking account deposits, payments, and their related prenotifications, while codes 32, 33, 37, and 38 apply to the same categories for savings accounts.
What does a file control record check?
The file control record, the type 9 record at the end of an ACH file, totals the batch count, block count, entry and addenda count, entry hash, and total debit and credit dollar amounts across the entire file, giving processors a final validation checkpoint before the file is accepted.
If you want to go deeper on this material and the rest of the ACH body of knowledge, our AAP Exam Prep Bundle walks through all ten parts of this series at your own pace, giving you and your team the structured, exam ready foundation to master ACH from the ground up.
