An ACH file is a plain text file, built to the format defined in the Nacha Operating Rules, that carries one or more batches of payment entries for the Automated Clearing House network in the United States. Businesses, payroll providers and payment companies create ACH files to send credits and debits to their bank, and banks exchange ACH files with the network's central operators.
The file is the basic unit of transport in ACH. Each file may hold many ACH batches, and each batch holds many individual ACH entries. The format has stayed broadly the same for decades, which makes it simple and reliable but also limited compared with newer message standards such as ISO 20022, which are used by real-time systems.
Structure of an ACH file
An ACH file is made of fixed-length records, each exactly 94 characters long, with fields in set positions. Every record starts with a one-digit record type code:
- File header (type 1). Identifies the immediate destination, usually the receiving bank or operator, and the immediate origin, along with the file creation date, time and a file ID modifier that tells duplicate files apart.
- Batch header (type 5). Opens each batch and gives the company name, company identification, Standard Entry Class code, entry description and effective entry date.
- Entry detail (type 6). One per payment, with the transaction code, receiving bank routing number, account number, amount, receiver name or ID and trace number.
- Addenda (type 7). Optional records attached to an entry, carrying remittance details or, for returns and corrections, the reason and original trace number.
- Batch control (type 8). Closes a batch with counts and totals.
- File control (type 9). Closes the file with the batch count, block count, total entries and addenda, file totals and an overall hash.
Records are grouped into blocks of ten. If the last block is not full, it is padded with lines of the digit 9, so that the total number of records is always a multiple of ten.
Built-in controls
Because files may contain thousands of payments, the format includes simple arithmetic checks. Each batch control and the file control carry the total value of debits and credits and the number of entries, which must match the detail records. They also include an entry hash, calculated by adding the first eight digits of each receiving bank's routing number and keeping the rightmost ten digits of the sum. A mismatch shows that records were lost, duplicated or altered. Banks and operators reject files that fail these checks, and many also apply wider payment message validation such as checking routing numbers against directories and screening for duplicates.
How ACH files move
An originator or its third-party sender usually uploads files to its bank, the originating depository financial institution (ODFI), over a secure file transfer link or online banking portal. The ODFI checks the file against limits and risk rules, then combines it with other customer files and sends it to an ACH operator: either the Federal Reserve's FedACH service or The Clearing House's Electronic Payments Network. The operator sorts the entries by receiving bank and delivers outgoing files to each receiving depository financial institution (RDFI). Returns, notifications of change and acknowledgements travel back the same way, also as ACH files.
Operators process files in a series of daily windows. Files submitted before the cut-off for a Same Day ACH window can settle the same business day, while others settle on the next banking day or a later effective date.
Creating and checking files
Accounting systems, payroll packages and enterprise resource planning software often export ACH files directly. Smaller firms use their bank's portal to key in payments, and fintechs increasingly use an ACH API that builds files behind the scenes. Common errors include wrong routing numbers, incorrect Standard Entry Class codes, effective dates on non-business days, mismatched totals and duplicate file ID modifiers. Many firms reconcile each file against their ledger before and after submission as part of payment reconciliation.
Limitations
The fixed 94-character layout limits how much information travels with a payment. Remittance data must be squeezed into addenda records, names are truncated and there is no native support for rich structured data. The file-and-batch model also means payments move in scheduled windows rather than instantly. These limits explain why newer systems, including real-time payment rails, use ISO 20022 messages, though ACH files remain the workhorse for payroll, bill payment and business collections in the United States.