NACHA format
Every NACHA file is plain ASCII text — no binary, no Unicode. This reference explains what's in the file: which characters are allowed, why "café" breaks production, and the byte-by-byte layout of all 7 record types.
It's just text — but stricter than you think
A NACHA file looks deceptively simple in a text editor: rows of digits, letters, and spaces. No XML tags, no JSON braces, no field separators. Just characters arranged in 94-column blocks, repeated until the file ends.
But "just text" is misleading. NACHA files are encoded in plain US-ASCII, and only a narrow subset of ASCII is actually allowed. If you're generating files in a modern programming language with default UTF-8 encoding, you're one customer name away from a rejection.
What happens with "Café" — a real example
Suppose you have a customer named José Café and you're putting them into the Individual Name field of an ACH entry. Here's exactly what happens at the byte level:
Each é is encoded as two bytes (0xC3 0xA9) in UTF-8, both above the 0x7E ceiling. "José Café" looks like 9 characters but is 11 bytes — and 4 are illegal.
The two ways to handle it
Rejected. 4 bytes outside ASCII range.
All bytes within 0x20-0x7E. Lossy but valid.
In Python: unicodedata.normalize('NFKD', s).encode('ASCII', 'ignore').decode(). In Java: Normalizer.normalize(s, Form.NFD).replaceAll("\\p{M}", ""). In Node, the any-ascii package handles transliteration well.
VARCHAR COLLATE utf8mb4, your ETL must transliterate before writing the file.File structure — 4 levels of nesting
A NACHA file is a tree with four levels of nesting. The file wraps batches, batches wrap entries, and entries optionally wrap addenda. Every record is exactly 94 bytes regardless of which level it lives at.
The level a record lives at matters more than its numeric type code. We've color-coded the levels below — once you internalize the hierarchy, the record types are easy.
Record anatomies — every field, every byte
Each section below shows the 94-byte layout of one record type, followed by a complete field-by-field reference. The colored band at the top maps directly to the field list — same color, same position.
File Header Type 1 · 1 per file
The first record in any NACHA file. Identifies the routing of the file, when it was created, and bookkeeping fields like the file ID modifier (used to distinguish multiple files sent on the same day).
1 — identifies this as a File Header.01. Reserved for future routing priority differentiation.YYMMDD format. Often used by RDFIs for sequencing.HHMM format (24-hour). Optional but most ODFIs populate it.A-Z or 0-9) used to distinguish multiple files sent on the same day from the same originator.094 — the byte length of every record in the file.10 — number of records per "block" (a relic of mainframe origins).1.Batch Header Type 5 · 1+ per file
Opens each batch. The most operationally important record — its SEC code (PPD, CCD, WEB...) determines which NACHA rules apply to all entries in the batch, including return windows, authorization requirements, and addenda format.
5.200 = mixed debits/credits, 220 = credits only, 225 = debits only, 280 = automated accounting advices.1 (e.g., 1123456789) or 9 for non-tax IDs.PPD for consumer prearranged, CCD for corporate, WEB for web-authorized). Determines which rules apply.PAYROLL , RENT ). Visible to receivers on their statement.YYMMDD or free-form like JAN 06). Shown on receiver statement.YYMMDD). Must be a banking day.1 for ODFI-originated entries.0000001.Entry Detail Type 6 · 1+ per batch
The actual money. Each Entry Detail represents one payment — a debit from or credit to a single account. The Transaction Code (positions 2-3) determines whether it's a checking debit, savings credit, prenote, etc. The trace number (positions 80-94) uniquely identifies the entry within the ACH network.
6.22 = checking credit, 27 = checking debit, 32 = savings credit, 37 = savings debit. Prenotes use 23/28/33/38.0000010000 = $100.00. Max 9999999999 = $99,999,999.99.0 = no addenda follows. 1 = at least one Type 7 Addenda follows.Addenda Type 7 · 0+ per entry
Optional remittance information attached to an Entry Detail. The format of positions 4-83 (Payment Related Information) varies dramatically by SEC code: PPD allows 1 free-text addenda, CCD allows 1, but CTX can carry up to 9,999 structured ANSI X12 segments. IAT entries require 7 specific addenda types in fixed order.
7.05 = generic remittance (PPD/CCD/CTX). 02 = MTE/POS/SHR. 10-18 = IAT-specific. 98 = NOC. 99 = Return.0001, second is 0002, etc. Resets per entry.Batch Control Type 8 · 1 per batch
Closes each batch with totals that must exactly match the entries in the batch. The entry hash and dollar totals are checksums — if they don't match, the entire batch is rejected. This is the most common cause of batch-level validation failures.
8.200 / 220 / 225 / 280.File Control Type 9 · 1 per file
The mirror image of File Header — closes the file with file-wide totals. Just like Batch Control, every total here must exactly match the sum of the corresponding values across all batches.
9.9-Padding Records Type 9 · 0+ per file
Optional filler rows appended after the File Control record so the total number of records in the file is a multiple of 10 (the blocking factor). Each padding record is exactly 94 nines: "99999...9". They carry no data — they exist purely to satisfy the legacy mainframe block-alignment requirement.
Modern parsers ignore these records entirely. If you're generating a file, use this formula:
padding_count = (10 - (total_records % 10)) % 10
...and write that many lines of 94 nines.