The NACHA file format, explained

Every ACH payment file uploaded to a US bank follows one standard: the Nacha record format. It has not structurally changed in decades, and it is strict enough that a single missing space gets a file rejected. Here is how it works.

Checking a file? The free ACH file validator explains every structural error in plain English, in your browser. Nothing is uploaded to us.

The shape of the file

A NACHA file is fixed-width ASCII text. Every line is exactly 94 characters, and the first character says what the line is:

TypeRecordHow manyWhat it carries
1File Header1, first lineWho the file is from and for, creation date and time, a file ID modifier
5Batch Header1 per batchCompany name and ID, entry class (PPD, CCD, WEB, TEL), statement description, effective date
6Entry Detail1 per paymentTransaction code, receiver routing and account, amount, receiver name, trace number
7Addenda0 or 1 per entry (most classes)Remittance detail, linked to its entry by sequence number
8Batch Control1 per batchEntry count, entry hash, debit and credit totals for the batch
9File Control1, last real lineBatch count, block count, file totals and hash

After the File Control record, the file is padded with lines of 94 nines until the total line count is a multiple of 10 (the "blocking factor"). Source: Nacha ACH Guide for Developers, the format's official free reference.

The fields that cause the most trouble

Immediate origin and Company ID. Banks assign these. The immediate origin in the file header is sometimes your routing number, sometimes "1" plus your EIN, sometimes a fixed value the bank gives you. The Company ID in the batch header is likewise ODFI-assigned. Using your bare EIN when the bank expects its own value is one of the most common rejection causes.

Transaction codes. Two digits on every entry: 22 is a checking credit, 27 a checking debit, 32 and 37 the savings equivalents. Codes ending in 3 and 8 (23, 28, 33, 38) are prenotes: zero-amount test entries. Getting credit and debit backwards moves money the wrong way, which is far worse than a rejection.

Amounts and dates. Amounts are 10 digits of implied cents, no decimal point: $1,234.56 is 0000123456. The effective entry date is YYMMDD and should be a banking day; operators roll stale dates forward rather than reject.

Control math. The batch and file control records carry entry counts, debit and credit totals, and an "entry hash": the sum of every entry's 8-digit receiving routing number, keeping only the rightmost 10 digits. Banks recompute all of it. If your software writes one entry and forgets to update a total, the file bounces.

Balanced vs unbalanced files

An unbalanced file carries only your payment entries; the bank settles against your account itself. A balanced file adds an explicit offset entry so debits equal credits. Which one your bank wants is a per-bank, per-agreement fact: Chase forbids offsets, other banks require or merely tolerate them. It is the first thing to check when a structurally valid file is still rejected.

Can QuickBooks create a NACHA file?

No. Intuit has confirmed in its own support threads that NACHA export is not available in QuickBooks Online or Desktop. Sage 50 cannot either. The usual workaround is exporting a CSV and converting it, which is exactly the kind of hand-formatting that produces control-math and field-width errors. The free NACHA file generator converts that CSV in your browser instead: it validates routing check digits, batch totals, and field widths before you download, and your payment data never leaves your computer.

Your bank's specific requirements

The standard is uniform; bank rules on top of it are not. Documented, source-cited pages for banks whose ACH upload requirements we have verified:

Some large banks do not publish their specs at all. For those, the pages explain what the portal calls the feature and exactly what to request from the bank:

Bank not listed, or rejecting your files anyway? The format setup service gets it working with you, or start with the free validator.

Rule changes worth knowing in 2026

Since March 20, 2026, Nacha requires standardized statement descriptions for two cases: PPD credit batches paying wages must say PAYROLL, and WEB debits for consumer e-commerce purchases must say PURCHASE, in the batch header's company entry description field. Separately, phased fraud-monitoring rules now require originators to run risk-based checks on the entries they originate. Format positions did not change. Source: Nacha rule pages.

This page is general information, not banking or legal advice. This site's tools format and check files only and move no money; funds move solely through your own bank. Bank names are trademarks of their owners, used only to identify compatibility; no affiliation or endorsement is implied.