How a NACHA ACH file is built
A NACHA file is plain ASCII text made of fixed-width records, each exactly 94 characters long. The first character of every record says what it is:
| Type | Record | What it carries |
|---|---|---|
| 1 | File header | Immediate destination (ACH Operator or bank routing number), immediate origin, creation date and time, file ID modifier, record size 094, blocking factor 10, format code 1. |
| 5 | Batch header | Service class code (200 mixed, 220 credits, 225 debits), company name and identification, SEC code (PPD, CCD, CTX, WEB…), company entry description, effective entry date, originating DFI, batch number. |
| 6 | Entry detail | Transaction code, receiving DFI routing number and check digit, account number, amount in cents, ID number, receiver name, addenda indicator, 15-digit trace number. |
| 7 | Addenda | Payment-related information (type 05), a return (type 99) or a notification of change (type 98). |
| 8 | Batch control | Entry/addenda count, entry hash, total debits, total credits for the batch. |
| 9 | File control | Batch count, block count, entry/addenda count, entry hash and debit/credit totals for the whole file — followed by lines of 94 nines to fill the last block of 10. |
Numeric fields are right-justified and zero-filled; alphanumeric fields are left-justified and space-filled. Amounts have no decimal point: 0000245000 is $2,450.00.
Entry hash, totals and blocking — why banks reject files
Most ACH rejects are arithmetic, not content. The bank or ACH Operator recomputes the control records and refuses the batch or the whole file when they disagree:
- Entry hash — the sum of the 8-digit receiving DFI identifications (positions 4–11 of every 6 record), keeping only the rightmost 10 digits. The file entry hash is the sum of the batch hashes, again truncated to 10 digits.
- Entry/addenda count — the number of 6 and 7 records in the batch (and in the file).
- Total debit and credit amounts — the sum of the amounts of debit and credit entries. The second digit of the transaction code decides: 1–4 are credits (22 checking credit, 32 savings credit), 5–9 are debits (27 checking debit, 37 savings debit). Prenotes (23, 28, 33, 38) and zero-dollar entries carry a zero amount.
- Block count — the number of 10-record blocks. The file is padded with records of 94 nines so the record count is a multiple of 10.
- Routing check digit — the 9th digit of an ABA routing number makes 3·d1 + 7·d2 + 1·d3 + 3·d4 + 7·d5 + 1·d6 + 3·d7 + 7·d8 + 1·d9 a multiple of 10. A wrong digit is returned as R28 or R13.
- Trace numbers — 15 digits: the ODFI's 8-digit routing prefix and a 7-digit sequence number that must ascend within each batch and be unique in the file.
SafeACH recomputes all of these and shows the declared and recalculated values side by side in Batches & totals. The Anonymize & fix tab writes a corrected file in which every 8 and 9 record and the padding are rebuilt from the entries.
Transaction codes
| Account | Credit | Credit prenote | Debit | Debit prenote | Returns / NOC |
|---|---|---|---|---|---|
| Checking | 22 | 23 | 27 | 28 | 21, 26 |
| Savings | 32 | 33 | 37 | 38 | 31, 36 |
| General ledger | 42 | 43 | 47 | 48 | 41, 46 |
| Loan | 52 | 53 | 55 (reversals) | — | 51, 56 |
Codes ending in 4 or 9 (24, 29, 34, 39, 44, 49, 54) are zero-dollar entries that carry remittance data.
Return reason codes and notifications of change
Returns arrive as entries with a type 99 addenda; notifications of change (NOCs) arrive in COR batches with a type 98 addenda carrying the corrected data. SafeACH decodes every code. The most common ones:
| Code | Meaning |
|---|---|
| R01 | Insufficient funds |
| R02 | Account closed |
| R03 | No account / unable to locate account |
| R04 | Invalid account number structure |
| R07 | Authorization revoked by customer |
| R08 | Payment stopped |
| R10 | Customer advises originator is not known and/or not authorized |
| R16 | Account frozen / entry returned per OFAC instruction |
| R20 | Non-transaction account |
| R29 | Corporate customer advises not authorized |
| C01 | NOC: incorrect DFI account number |
| C02 | NOC: incorrect routing number |
| C05 | NOC: incorrect transaction code |
2026 Nacha rules: PAYROLL and PURCHASE
Since 20 March 2026 the Nacha Operating Rules require two standard Company Entry Descriptions (batch header positions 54–63): PAYROLL for PPD credits that pay wages, salaries and similar compensation, and PURCHASE for WEB debits for consumer e-commerce purchases. SafeACH warns when a PPD credit batch or a WEB debit batch looks like payroll or an online purchase but uses another description. It cannot know the purpose of a batch for certain, so these are warnings, not errors.
Sharing an ACH file safely
Banks, payroll vendors and processors routinely ask for “the file” when a batch is rejected. A raw ACH file carries employee names, account numbers and sometimes Social Security–style ID numbers. Masking them by hand breaks nothing visible — but if you also trim the file to a few entries, every count, hash and total in the 8 and 9 records is now wrong and the file no longer reproduces the problem.
SafeACH replaces names, account numbers, ID numbers, company details and addenda text with consistent tokens (the same original value always becomes the same token), keeps routing numbers, amounts, dates and trace numbers, optionally keeps only the first entries of each batch, and then recalculates every batch control, the file control, the block count and the padding. The rebuilt file is parsed and checked again before you download it.
How to use SafeACH
- Open DevTools → Network if you want to watch: reading a file makes no requests.
- Open or drop the ACH file (or paste its text). Files without line breaks are split into 94-character records automatically.
- Read the verdict and the Checks tab. Click a line reference to jump to the record; the faulty field is highlighted in red.
- Use Entries to search and export the payments, and Batches & totals to compare declared and recalculated controls.
- In Anonymize & fix, pick what to mask and download the rebuilt file for your ticket or test environment.
FAQ
Is my ACH file uploaded anywhere?
No. SafeACH is a single web page that parses the file with JavaScript in your browser tab. The page's Content-Security-Policy blocks every network destination except the Polar license check, which only sends a license key. You can verify it in DevTools → Network and keep using the page offline once it has loaded.
Which NACHA formats does SafeACH support?
All standard 94-character NACHA files: PPD, CCD, CTX, WEB, TEL, ARC, BOC, POP and the other SEC codes, prenotes, zero-dollar entries, returns (type 99 addenda), notifications of change (COR batches with type 98 addenda) and IAT batches. For IAT it checks structure, counts, hashes and totals but does not validate the seven mandatory IAT addenda field by field.
How is the entry hash calculated?
Add up the 8-digit receiving DFI identification (positions 4–11) of every entry detail record in the batch and keep the rightmost 10 digits. The file control's entry hash is the sum of all batch entry hashes, again truncated to 10 digits. The check digit in position 12 is not part of the hash.
Why does my file need lines of 9s at the end?
NACHA files use a blocking factor of 10, so the total number of records must be a multiple of 10. After the file control record the file is padded with records of 94 nines, between zero and nine of them. The block count in the file control is the number of 10-record blocks.
Can SafeACH fix a file with wrong totals?
Yes. In Anonymize & fix, leave all masking off and keep “Recalculate batch & file controls” and “Pad to a multiple of 10” on. SafeACH rewrites every batch control, the file control, the block count and the padding from the entries and re-checks the result. It does not change entries, so problems such as a wrong routing check digit are still reported.
Does masking keep the file valid?
Yes. Masked values keep the field widths, routing numbers and amounts are kept, and the control records are recalculated, so the rebuilt file still balances and parses in bank and vendor tools. The same original value always maps to the same token, so duplicates and patterns survive.
Does SafeACH check the 2026 Nacha PAYROLL and PURCHASE descriptions?
Yes. It warns when a PPD credit batch looks like payroll, or a WEB debit batch looks like an e-commerce purchase, but its Company Entry Description is not PAYROLL or PURCHASE. These standard descriptions are required since 20 March 2026.
Is SafeACH a replacement for my bank's validation?
No. SafeACH checks the NACHA record formats, the arithmetic and a set of Nacha rules so you catch most rejects before you upload. Your bank and the ACH Operator apply their own edits, limits and risk checks, and their result is the final word.