ACH File Format Explained: NACHA Records & Control Totals
A guide to the US ACH (NACHA) file format: the 94-character record types, the routing check digit, entry hash, and the control totals every file must balance.
Validate your file right now
Free, instant and 100% in your browser - no file is ever uploaded.
What is an ACH / NACHA file?
ACH (Automated Clearing House) is the batch electronic payment network that moves money between US bank accounts. It handles direct deposit of payroll, vendor and supplier payments, tax refunds, insurance premiums, and consumer debits such as utility bills or loan repayments. Instead of settling each payment individually, ACH groups them into batches that are exchanged and settled at set times through the Federal Reserve or a private operator.
The file that carries these payments follows the NACHA format (also called the Nacha Operating Rules format, or simply an 'ACH file'). It is a plain-text, fixed-width format: every line - called a record - is exactly 94 characters long, and records are grouped into blocks of 10. If the last block is not full, it is padded with filler lines of 9s to reach a multiple of 10 records.
Because the format is fixed-width and self-balancing, a single wrong character - a misaligned field, a bad routing number, or a control total that no longer matches the detail records - can cause your bank (the ODFI) to reject the whole file. Validating the file before you send it is the cheapest way to avoid a returned batch and a delayed payroll run.
The record types inside an ACH file
An ACH file is built from six record types, identified by the first character of each 94-character line. They always appear in the same nested order: one File Header, then one or more batches, then one File Control record.
1 - File Header
Opens the file. Contains the immediate origin and destination routing numbers, the file creation date and time, and a file ID modifier. There is exactly one File Header per file.
5 - Batch Header
Opens a batch. Carries the service class code (credits, debits or mixed), the company name and ID, the SEC code (PPD, CCD, WEB...), the effective entry date and the originating bank's routing number.
6 - Entry Detail
One record per payment. Holds the receiver's routing number and check digit, account number, amount, transaction code (checking/savings, credit/debit) and the receiver's name.
7 - Addenda
Optional extra information attached to an entry - for example remittance data (CCD/CTX) or return/correction details. An entry can have zero, one or many addenda records.
8 - Batch Control
Closes a batch. Contains the entry/addenda count, the entry hash, and the total debit and credit amounts for that batch - all of which must match the entries above it.
9 - File Control
Closes the file. Contains the batch count, block count, total entry/addenda count, total entry hash, and total debits and credits for the whole file.
How the routing number check digit and entry hash work
Every US bank is identified by a nine-digit routing number (also called an ABA number or RTN). The ninth digit is a check digit computed from the first eight using the ABA 3-7-1 algorithm: multiply the digits by the repeating weights 3, 7, 1, 3, 7, 1, 3, 7, sum the products, and choose the check digit that makes the total a multiple of 10. A routing number whose check digit does not satisfy this test is invalid and will bounce.
The entry hash is a second safeguard. For each batch, take the first eight digits of every receiving bank's routing number, add them all together, and keep only the rightmost ten digits of the sum (dropping any overflow on the left). The Batch Control record stores this per-batch hash, and the File Control record stores the sum across all batches, truncated the same way.
Together these two checks let the receiving institutions confirm that no entry was dropped, duplicated or altered in transit. A validator recomputes both from the detail records and compares them to what the control records claim - a mismatch almost always means an entry was added, removed or edited without updating the totals.
Control totals and the most common ACH errors
Beyond the entry hash, every ACH file must balance three kinds of totals. The entry/addenda count is the number of type-6 and type-7 records. The total debit and total credit amounts are the sums of the amounts in the entry records, split by whether the transaction code is a debit or a credit. And the block count is the number of 10-record blocks in the file. Both the Batch Control (per batch) and File Control (whole file) records repeat these figures, and all of them must match the detail records exactly.
The errors we see most often are: a record that is not exactly 94 characters (usually a stray space or a trimmed line); a routing number with a wrong check digit; an entry hash or amount total that was not recomputed after an entry was added or removed; a service class code (e.g. 200/220/225) that disagrees with the actual mix of debits and credits in the batch; and a file whose record count is not a multiple of 10 because the final 9-filler block is missing.
Most of these are invisible when you eyeball the file but fatal when the ODFI's parser reads it. Recomputing the check digit, entry hash and every control total - which is exactly what a validator does - catches them before the batch leaves your system.
Validate your ACH file before you send it
Paste or drop your ACH file into the ValidateFin ACH / NACHA validator. It checks record structure, routing check digits, the entry hash and every batch and file control total - entirely in your browser. No ACH file is ever uploaded to a server.
Open the ACH validatorFrequently Asked Questions
What is the difference between ACH and NACHA?
ACH (Automated Clearing House) is the payment network; NACHA (the National Automated Clearing House Association) is the body that writes the rules and defines the file format. People often say 'a NACHA file' and 'an ACH file' to mean the same thing: a batch payment file in the NACHA format.
How long is each record in an ACH file?
Exactly 94 characters. Every record type - File Header, Batch Header, Entry Detail, Addenda, Batch Control and File Control - is padded to 94 characters, and records are grouped in blocks of 10.
How is an ACH routing number validated?
With the ABA 3-7-1 check-digit algorithm. The first eight digits are multiplied by the repeating weights 3, 7, 1; the ninth digit is chosen so the weighted sum is a multiple of 10. If it isn't, the routing number is invalid.
What is the entry hash and why does it matter?
The entry hash is the sum of the first eight digits of every receiving routing number in a batch, truncated to the last ten digits. It is stored in the Batch Control and File Control records so the receiving banks can detect a lost, added or altered entry.
What are the ACH record type codes?
1 = File Header, 5 = Batch Header, 6 = Entry Detail, 7 = Addenda, 8 = Batch Control, 9 = File Control. The type is the first character of each 94-character record.
Why must the number of records be a multiple of 10?
ACH files are transmitted in blocks of ten 94-character records. If the real records don't fill the last block, it is padded with filler lines of all 9s so the total is a multiple of 10. A file that isn't blocked correctly can be rejected.
What causes an ACH file to be rejected?
Common causes are records that aren't 94 characters, a routing number with a bad check digit, control totals or an entry hash that don't match the entries, a service class code that disagrees with the debits and credits in the batch, and incorrect blocking. Validating first catches all of these.
Is it safe to validate an ACH file online?
With ValidateFin, yes - the file is parsed entirely in your browser with JavaScript and never uploaded to a server. Since ACH files contain bank account and routing numbers, client-side validation avoids sending that data anywhere.