James Allman | JA Technology Solutions LLC
How ACH Payments Work: Inside a NACHA File
Every payroll run, vendor payment, and recurring debit rides the ACH network as a fixed-width 94-character file. Here is what is inside it, how the record hierarchy fits together, and what happens when an entry comes back.
Every payroll run, vendor payment, subscription renewal, and insurance premium that moves through the U.S. banking system without a check or a card travels as an ACH (Automated Clearing House) transaction. The ACH network processes billions of these entries each year, and every one of them starts life as a record inside a NACHA-formatted file. If you work in treasury, accounts payable, accounts receivable, or finance IT, you almost certainly generate or receive these files on a schedule. Understanding what is inside them is the first step toward processing them reliably.
The NACHA format is deliberately simple: fixed-width, 94-character text records organized into a strict hierarchy. No XML, no JSON, no variable-length fields. That simplicity is a feature. It dates from an era when batch files moved between mainframes over leased lines, and it has outlasted every successor proposal because it works, handles millions of entries per day, and parses in a few hundred lines of code on any platform.
Credits, debits, and the two parties
ACH transactions move in one of two directions. A credit pushes money from the originator's account at the ODFI (Originating Depository Financial Institution) into a receiver's account at the RDFI (Receiving Depository Financial Institution). Payroll is the classic example: the employer's bank sends credits to each employee's bank. A debit pulls money in the opposite direction: the originator's bank debits the receiver's account at the RDFI and brings the funds back. Subscription billing, recurring insurance premiums, and mortgage drafts work this way.
The ODFI is the bank that accepts the NACHA file, validates it, and submits the entries into the ACH network, which routes them to each RDFI. The originating company (your company, the payroll processor, the biller) is not itself a participant in the ACH network; its bank is. That distinction matters when something goes wrong, because the ODFI assumes liability for the entries it originates and is the entity that answers for return codes and compliance.
Settlement typically happens one or two business days after the origination date. Same-day ACH (SDA) entries, available since 2016, settle the same business day when submitted before the applicable cut-off. Most payroll and vendor payment runs still use the next-day window, but same-day is increasingly used for time-sensitive payments.
The NACHA file hierarchy
A NACHA file uses six record types, each identified by a single digit in position 1. The File Header (record type 1) appears once at the top and carries the immediate origin and destination routing numbers, the file creation date and time, and a file ID modifier that distinguishes multiple files delivered the same day. The File Control (record type 9) appears once at the end and contains the totals that must reconcile against everything in between.
Between the file header and file control, the file contains one or more batches. Each batch opens with a Batch Header (type 5) and closes with a Batch Control (type 8). A batch groups entries that share a company name, SEC code, effective date, and service class code. A payroll batch and a vendor payment batch in the same file will be in separate batch groups even if their effective dates match, because the company name or SEC code differs.
Inside each batch, the Entry Detail records (type 6) carry the actual payment instructions: routing number, account number, amount, transaction code, and individual name. Optional Addenda records (type 7) follow specific entries and carry payment-related information such as invoice numbers, remittance detail, or the reasons for a return. Whether addenda are allowed, required, or prohibited depends on the SEC code for the batch.
Transaction codes
The two-digit transaction code in each Entry Detail record tells the RDFI what kind of account to credit or debit and in which direction. The most common codes for demand deposit (checking) accounts: 22 is a checking credit (money going into the account), 27 is a checking debit (money coming out). For savings accounts: 32 is a savings credit, 37 is a savings debit.
Prenote codes validate account information before any real money moves. Code 23 is a checking credit prenote, 28 a checking debit prenote, 33 a savings credit prenote, 38 a savings debit prenote. A prenote carries a zero amount and goes through the same routing path as a live entry. If the RDFI returns a prenote, the originator knows the account detail is wrong before it sends a payroll file. The ACH rules require a waiting period after a prenote before live entries can follow.
Less common codes cover loan accounts (codes 21, 26, 31, 36) and general ledger entries (codes 23-range variations). The NACHA/ACH File Explorer decodes every transaction code on each parsed entry so you see a plain-English description alongside the raw two-digit value.
SEC codes and what they govern
The Standard Entry Class (SEC) code in the Batch Header is a three-letter code that specifies the authorization method, the allowed addenda count, and the rules the originator must follow. PPD (Prearranged Payment and Deposit) is the most common: written authorization, one optional addenda, used for consumer accounts including payroll direct deposit and recurring bills. CCD (Corporate Credit or Debit) is the B2B equivalent: machine-to-machine payments between businesses, one optional addenda.
WEB covers consumer debits authorized via the internet, and it carries the highest originator obligations: the originator must verify account ownership, meet specific security requirements, and accept annual reauthorization. TEL covers consumer debits authorized by telephone. CTX (Corporate Trade Exchange) allows up to 9,999 addenda records per entry, which makes it the right choice when remittance detail (line-item invoice data) must travel with the payment.
The SEC code matters for your processing logic because it changes what addenda are allowed, what authorization documentation you must retain, and what return rights the consumer or business receiver has. A CCD entry and a PPD entry sent to the same routing and account number travel differently through the ACH rules framework even if the dollar amounts are identical.
Control totals and why they must balance
The NACHA format uses a layered set of control fields that must agree at both the batch and file level. The Batch Control (type 8) carries an entry and addenda count for the batch, a routing number hash, and separate debit and credit totals. The routing number hash is the sum of the 8-digit RDFI routing numbers from each Entry Detail record, with anything above 10 digits truncated from the left. It is not a checksum in the cryptographic sense; it is a cross-check that detects transpositions and dropped entries.
The File Control (type 9) carries batch count, block count, total entry and addenda count across all batches, and the sum of all batch-level hashes. Every NACHA-compliant receiving system will reject a file before processing any entry if these totals do not balance. A count off by one, a hash that does not add up, or a credit total that does not match the sum of the credit entries in the batch will result in a file-level reject, not an individual entry return.
Files must also be padded to a multiple of 10 records (one block). If the total number of records is not divisible by 10, the file is padded with rows of nines (999999999...) at the end. Some processors reject files that are missing the padding. The NACHA/ACH File Explorer surfaces hash mismatches, count discrepancies, and debit/credit imbalances immediately when you drop in a file, which makes it useful for validating generated output before delivery to the bank.
Return codes
When an entry cannot post at the RDFI, the RDFI returns it with an R-prefixed return reason code on an Addenda (type 7) record. The most common returns: R01 (Insufficient Funds), R02 (Account Closed), R03 (No Account or Unable to Locate Account), and R10 (Customer Advises Not Authorized). R03 and R10 indicate data problems that a retry will not fix. R01 may be retriable depending on your agreement with the receiver and your ACH authorization.
Return timeframes are governed by NACHA rules and vary by return reason. Most administrative returns (R02, R03) have a two-banking-day return window. R10 and other consumer authorization returns have a longer window, up to 60 calendar days for certain unauthorized debit claims. Missing a return means the RDFI may use a late return process with different settlement timing.
Returns arrive as records inside a NACHA-format file, structured exactly like a forward file but with specific return batch service class codes and the addenda carrying the return reason. The ACH Return Code Lookup maps every R-code to its description, who can originate it (RDFI or ODFI), and the applicable return window. For the companion article on bank statement file formats that carry the settled view of these transactions, see Understanding BAI2 Files and Understanding OFX and QFX Bank Statement Files.
Building reliable ACH processing
Manual ACH file handling does not scale past a small volume. The daily routine of exporting payment data from an ERP or accounting system, formatting a NACHA file, validating totals, delivering via SFTP, and then matching return files back to the original entries becomes a significant operational burden as transaction counts grow. For companies running payroll, vendor payments, and recurring billing through the same ACH pipeline, the failure modes compound: a missed return, a control total mismatch, or a late file delivery can freeze payments or trigger bank fees.
A well-built ACH pipeline has five stages: extract (pulling payment data from the ERP, AP system, or billing platform), generate (formatting valid NACHA files with correct hierarchy and control totals), validate (checking totals, hashes, and entry counts before delivery), deliver (SFTP to the bank's ACH receiver on the agreed schedule), and reconcile (matching bank acknowledgment and return files back to the original entries and posting results downstream). Related tools: the Positive Pay Generator for check fraud prevention, and for the structured balance reporting that accompanies ACH activity, the BAI2 Explorer.
I build these pipelines against bank ACH receivers, ERP systems including IBM i-hosted accounting platforms, and standalone AP and payroll systems. If your ACH process relies on manual file preparation or hand-matching of return files, there is almost always a direct automation path. See integration services or custom reporting and pipelines for more, or Ask James to talk through your specific setup.