The NACHA file format is the fixed-width text layout that businesses and banks use to submit ACH payments. Every line is exactly 94 characters, every line starts with a one-digit record type, and the file is padded so its line count is a multiple of 10, according to Nacha's ACH Guide for Developers. That format carried 35.2 billion ACH Network payments worth $93 trillion in 2025, per Nacha's January 29, 2026 volume release.
​

Most published references for the format are bank PDFs listing field positions. This article walks through the structure the way an operations or engineering team actually meets it: the six record types, the fields that matter in each, a complete 10-line sample file decoded line by line, and the validation errors that cause files to be rejected.
​

The NACHA file format is a plain ASCII, fixed-width file where each 94-character line is a record. Records nest like brackets: a file header opens the file, batch headers open groups of payments, entry detail records hold individual payments, and matching control records close each batch and the file with counts and totals for validation.
​

Nacha, the organization that governs the ACH Network, publishes the specification in the Nacha Operating Rules and summarizes it in its free developer guide. The guide describes an ACH file as "a fixed-width, ASCII file" where each line is a record made of fields at fixed positions. Because fields are positional rather than delimited, a single missing space shifts every field after it and breaks the file.
​

The file travels from an Originator (the company paying or collecting) to its bank, the Originating Depository Financial Institution (ODFI). The ODFI forwards entries to one of two ACH Operators, the Federal Reserve Banks or The Clearing House's Electronic Payments Network, which route them to the Receiving Depository Financial Institution (RDFI), as described in Nacha's How ACH Works page. For where ACH sits among other rails, see payment rails explained.
​

Two formatting rules apply to every field. Per the developer guide, alphanumeric fields are left-justified and padded with trailing spaces, while numeric fields are unsigned, right-justified, and padded with leading zeros. Code fields must use uppercase characters only.
​

A NACHA file uses six record types identified by the first character of each line. Type 1 is the file header, 5 is the batch header, 6 is an entry detail, 7 is an addenda, 8 is the batch control, and 9 is the file control. Lines of all 9s pad the file to a full block.
​

The record order is strict. A file contains one file header, then one or more batches, then one file control. Each batch contains one batch header, one or more entries (each optionally followed by addenda), and one batch control. The developer guide compares this pairing of header and control records to braces or XML tags.
​

The file header always begins with "101": record type 1 followed by priority code 01. Positions 4-13 hold the Immediate Destination, which Nacha defines as the nine-digit routing number of the institution receiving the file, preceded by a blank. Positions 14-23 hold the Immediate Origin. The rest of the line carries the creation date (YYMMDD, positions 24-29), creation time (HHMM, 30-33), a File ID Modifier at position 34, the fixed values 094 (record size), 10 (blocking factor), and 1 (format code) in positions 35-40, and two 23-character name fields. All positions come from the ACH File Details page.
​

The File ID Modifier accepts A-Z or 0-9 and distinguishes multiple files sent on the same day. A second file with the same date and modifier can look like a duplicate to the receiving bank.
​

The batch header sets context for every entry beneath it. Positions 2-4 hold the Service Class Code: 200 for mixed debits and credits, 220 for credits only, and 225 for debits only, per the developer guide. The Standard Entry Class code sits in positions 51-53, the Company Entry Description in 54-63, and the Effective Entry Date in 70-75. Positions 76-78 hold the Julian settlement date, which the ACH Operator fills in, so originators leave it blank. The batch closes with the ODFI's eight-digit routing identifier (80-87) and a seven-digit batch number (88-94), per Nacha's field tables.
​

The Company Entry Description is the text a receiver often sees on a bank statement, such as PAYROLL. For debit WEB entries, Increase's SEC code documentation notes the description must start with PURCHASE.
​

Each entry is one payment. The two-digit transaction code in positions 2-3 says which way money moves and to what account type. Nacha's overview lists 22 (checking credit), 27 (checking debit), 32 (savings credit), and 37 (savings debit), with 23, 28, 33, and 38 used for zero-dollar prenotifications.
​

The receiving bank's routing number is split in two: the first eight digits go in positions 4-11 and the check digit goes alone in position 12. The account number takes positions 13-29 (17 characters, left-justified), and the amount takes positions 30-39 as ten digits with an implied decimal, so $1,500.00 is written 0000150000. Positions 40-54 carry an identification number, 55-76 the receiver's name, 79 the addenda indicator (0 or 1), and 80-94 the 15-digit trace number. Field positions follow Nacha's PPD/CCD entry layout.
​

An addenda record follows the entry it describes and carries up to 80 characters of payment-related information in positions 4-83. The standard addenda type code for this purpose is 05, and positions 88-94 repeat the last seven digits of the parent entry's trace number, according to the addenda layout. How many addenda an entry may have depends on the SEC code, covered below. Remittance detail carried here is the ACH equivalent of a remittance advice.
​

The batch control repeats the service class code, then records the count of entries plus addenda (positions 5-10), the entry hash (11-20), total debits (21-32), and total credits (33-44). The file control records the batch count, the block count, the file-wide entry and addenda count, the entry hash (22-31), and file totals for debits (32-43) and credits (44-55), per Nacha.
​

The entry hash is a checksum. Nacha defines it as the sum of all the Receiving DFI Identification fields (the eight-digit routing numbers without check digits) in the entry records, truncated to the rightmost 10 digits if the sum overflows. A receiving system recomputes it and rejects the batch or file when the values disagree.
​

Every record is exactly 94 characters, and records are grouped in blocks of 10. If the final block is short, the file is filled with lines consisting entirely of the digit 9. The file control's block count equals total lines divided by 10, so the padding keeps that math whole.
​

The developer guide states that ACH files "are padded with lines of 9s" so the line count is a multiple of 10. A file with 6 real records therefore gets 4 padding lines, and a file with 23 real records gets 7. The values 094 and 10 are hard-coded into the file header at positions 35-37 and 38-39 (Nacha), a holdover from the tape and punched-card era when record and block sizes had to be declared up front.
​

Fixed width also explains why spreadsheet exports so often fail. A tool that trims trailing spaces from the end of a line leaves a 70-character record, and a tool that drops leading zeros from an amount or account field shifts every later position. Nacha's guide requires numeric fields to be zero-filled and alphanumeric fields space-filled precisely so every line lands at 94.
​

A Standard Entry Class code is a three-letter label in the batch header that tells banks what kind of payment the batch contains and which authorization rules apply. PPD covers consumer accounts under written authorization, CCD covers business accounts, CTX covers business payments with large remittance data, and WEB covers internet-authorized consumer payments.
​

Because the SEC code lives in the batch header, a single batch can hold only one type. A company that runs payroll (PPD) and pays suppliers (CCD) on the same day sends two batches, which may still share one file.
​

The SEC code also changes a few entry fields. In WEB and TEL entries, positions 77-78 become a Payment Type Code rather than discretionary data, per the WEB/TEL entry layout. CTX entries restructure positions 40-78 to carry an addenda count and receiving company name, which is why CTX files need separate parsing logic.
​

A minimal NACHA file has one file header, one batch header, one or more entries, one batch control, one file control, and padding to 10 lines. The example below pays two employees by direct deposit in a single PPD credit batch, then decodes each line against the published field positions.
​

The routing numbers, account numbers, and names are invented for illustration. The routing numbers were chosen so their check digits pass the standard 3-7-1 weighting, and every line was generated at exactly 94 characters. Trailing spaces are part of each record but are not visible on screen.
​

"101" is record type 1 plus priority 01. " 987654320" is the Immediate Destination with its leading blank, and " 123456780" is the Immediate Origin. "260925" is the creation date (September 25, 2026) and "1400" the time. "A" is the File ID Modifier, followed by "094", "10", and "1". The two name fields read DEST BANK and ACME CORP, padded with spaces to 23 characters each. Field positions follow Nacha file details.
​

"5" opens the batch and "220" marks it credits only. ACME CORP fills the 16-character company name, followed by 20 blank discretionary characters. "1123456789" is the 10-character company identification, "PPD" the SEC code, and "PAYROLL" the entry description. The descriptive date is blank, "260926" is the effective entry date, and the three-character settlement date is left blank for the Operator. "1" is the originator status code, "12345678" the ODFI identifier, and "0000001" the batch number. Field positions follow Nacha file details.
​

Line 3 starts "6" then "22", a checking credit. "11111111" and check digit "8" form the receiving routing number 111111118. The account "000123456789" is left-justified in 17 characters. "0000150000" is $1,500.00. EMP001 is the identification number, JANE DOE the receiver name, two blank discretionary characters follow, "0" says no addenda, and "123456780000001" is the trace number: the ODFI's eight digits plus a seven-digit sequence. Line 4 follows the same pattern for $2,125.50 to routing number 222222226. Field positions follow Nacha file details.
​

"8" and "220" echo the batch header. "000002" counts two entries. The entry hash "0033333333" is 11111111 plus 22222222. Total debits are twelve zeros, and total credits are "000000362550", or $3,625.50. The company ID, 25 blank characters for the message authentication and reserved fields, the ODFI identifier, and batch number close the line. Field positions follow Nacha file details.
​

"9" is followed by "000001" batches, "000001" block, and "00000002" entries and addenda. The entry hash "0033333333" and the credit total "000000362550" match the batch control exactly, and the remaining 39 characters are blank. Six real records need four lines of 9s to reach 10, which is why the block count reads 1.
​

Most NACHA file rejections trace back to a small set of problems: lines that are not exactly 94 characters, control totals or entry hashes that do not match the entries, missing padding, invalid routing check digits, wrong transaction codes for the batch's service class, and lowercase characters in code fields.

The underlying rules come from Nacha's file overview, which requires zero-filled numeric fields, space-filled alphanumeric fields, and uppercase codes, and from the field definitions for the entry hash and control totals. Checking all six conditions before upload catches most rejections before the bank's own validator does.
​

One more design choice affects validation: balanced versus unbalanced files. The developer guide describes a balanced file as one that carries the offset (settlement) account entry within the file, so debits equal credits. Some banks require balanced files and others add the offset themselves, so the ODFI's origination agreement decides which format applies.
​

The NACHA format is a batch format built for high volumes of low-cost payments, while wire messages carry one high-value payment each. ACH files group many entries under shared headers and settle on a schedule, including same-day windows, instead of in real time.
​

Scale shows why the batch design persists. Same Day ACH alone handled 1.4 billion payments worth $3.9 trillion in 2025, and B2B ACH volume reached 8.1 billion payments, per Nacha's 2025 results. Nacha has also published an ISO 20022 credit transaction guide mapping pain.001 messages to ACH, which lets companies that already produce ISO 20022 payment files originate ACH without building a separate 94-character generator. For the trade-offs between the two main bank rails, see ACH vs wire transfer.
​

Teams that also move money on newer rails, including stablecoin networks, often keep ACH files for payroll and domestic vendors. Eco works on the stablecoin side of that picture and does not replace ACH origination.
​