A Nacha file validation tool reads an ACH file and checks it against the Nacha file format: that every line is a 94-character record in the required order, that each field holds the right kind of value in the right positions, that codes are valid, and that the batch and file control totals agree with the entries. That catches malformed files, which is necessary but, in treasury onboarding, rarely enough: the files that cost implementation teams days are well formed and still wrong, because they carry a company ID the client's bank never assigned or an entry class that does not fit the payees. Botminds' Treasury Management Onboarding validates every test file a new treasury client sends twice, against the Nacha format and against that client's signed setup, and writes each error beside its record in words the client's controller can act on.
The examples come from a fictional sample client, Halvorsen Freight Systems, testing its first ACH file at a fictional bank. The format rules come from Nacha's public developer guide and rule pages, linked where they appear; the full specification sits in Appendix Three of the Nacha Operating Rules.
One sample test file, read twice
216records
212 payments in two batches, with headers and controls
38seconds
to read every record against the format and the client's setup
8of 10
checks passed, including every structural one
2errors
that a format-only validator would have passed
What does a Nacha file validator check?
A Nacha file validator checks structure: the shape of the file, the format of each field and the arithmetic that ties records together. Nacha's guide sets out the basics: "An ACH file is a fixed-width, ASCII file, with each line exactly 94 characters in length," and "In a properly formatted file, records must follow a specific order" (Nacha, ACH File Overview). A good validator tests each of the following, and says which record and positions failed.
The structural checks a Nacha file validator should make
| Check | What the format requires | Where |
|---|---|---|
| Record length | Every line exactly 94 characters; the file header's record size is always "094" | Every record; file header positions 35–37 |
| Record order | File header (1), then batches of batch header (5), entries (6), addenda (7), batch control (8); then file control (9) | First character of each line |
| Blocking | Blocking factor 10; the file padded with lines of 9s to a multiple of ten lines | File header positions 38–39; end of file |
| Field formats | Alphanumeric left-justified, space-padded; numeric unsigned, right-justified, zero-padded; codes in upper case | Every field |
| Codes | Valid service class (200, 220, 225), transaction codes (22, 23, 27, 28, 32, 33, 37, 38 and others), a valid SEC code | Batch header 02–04 and 51–53; entry 02–03 |
| Batch arithmetic | Entry/addenda count, entry hash (sum of the receiving routing fields), debit and credit totals; service class and batch number match the header | Batch control (8) |
| File arithmetic | Batch count, block count, entry/addenda count, entry hash and totals agree with the batches | File control (9) |
| Trace numbers | Ascending, though not necessarily consecutive, within a batch | Entry detail, positions 80–94 |
| Duplicate file | A File ID Modifier unique for each file sent on the same day | File header position 34 |
Every one of those checks can be made from the file alone, which is why free and built-in validators exist and are useful. None of them needs to know who sent the file, what the client agreed, or who the payees are.
Why was my ACH file rejected? The structural failures
At the structural stage the causes are few: a record of the wrong length, a control total that does not match its entries, a field holding the wrong kind of value. A file built or edited in a spreadsheet can produce all three: a line trimmed of trailing spaces is no longer 94 characters, an amount with a decimal point is not an unsigned number, and a hand-edited entry breaks the batch's entry hash and totals.
Characters are a quieter cause. Nacha's rule on "Currently Accepted Characters in the ACH Network", effective January 1, 2027, documents the characters both ACH Operators accept, and notes that "if a batch or file is submitted to an ACH Operator containing a character that it does not accept, the batch/file may be pended or rejected." The rule also says ODFIs "may accept all valid characters or a subset from their Originators," and that multi-byte characters "are not recommended for use in an ACH Record, as adjustment is needed to ensure an ACH Record line does not exceed 94 bytes" (Nacha). An accented letter in a payee name can therefore pass one validator and fail at the bank.
Then there are rejections that are not structural at all: a file after the bank's cut-off, an effective date that is not a processing day, a company ID the bank cannot tie to an agreement, a total above the client's exposure limit. Those come from the bank's own intake rules, and a generic validator cannot know them.
Can a Nacha file pass validation and still be wrong?
Yes, and those are the files that cost onboarding teams days. A file can be perfectly formed and still carry the wrong company ID, an entry class that does not fit the receiving accounts, a payroll batch without the description the rules now require, or an effective date the client's authorizations do not support. Nacha's guide is blunt about the last: "It is a Nacha Rules violation to debit a Receiver prior to the authorization date."
The bank cannot treat those as the client's problem. The FFIEC's examination handbook puts the warranty on the originating bank: it vouches for every entry a service provider sends on its behalf, including that the receiver authorized it (FFIEC IT Handbook, Retail Payment Systems; third-party sender vs third-party service provider quotes the handbook). A validation that stops at the format leaves the bank warranting content nobody checked.
A format validator and a setup-aware check, on the same file
Format validator: Ten alphanumeric characters: passes.
Checked against the client's setup: Matches the value on the signed origination agreement, in every place it appears?
Format validator: PPD is a valid code: passes.
Checked against the client's setup: Permitted by the client's schedule, and right for these payees' accounts?
Format validator: Any ten characters: passes.
Checked against the client's setup: PAYROLL on wage credits, as required since March 20, 2026; not on vendor payments?
Format validator: Six digits in YYMMDD form: passes.
Checked against the client's setup: A processing day, inside the client's cut-off, and not before any debit authorization?
Format validator: Totals agree with entries: passes.
Checked against the client's setup: Inside the approved daily credit and debit limits, across settlement dates?
Format validator: Prenote transaction codes valid: passes.
Checked against the client's setup: Sent to new receivers as far ahead as the schedule requires, and none returned?
The two errors in the sample were of exactly this kind: a company ID carried over from the client's previous bank, and 38 vendor payments coded for consumer accounts. Each has its own guide: what the ACH company ID means, and PPD vs CCD.
The 2026–27 rule changes a validator must know
A validator built against an old specification will pass files the current rules treat as wrong, so ask any vendor which rule changes its checks cover and when they were added. Three matter for treasury clients now.
Since March 20, 2026, originators must use the Company Entry Description "PAYROLL" for PPD wage credits and "PURCHASE" for consumer debits for online purchases of goods, in positions 54–63 of the batch header (Nacha, Company Entry Descriptions). From January 1, 2027, the accepted-characters rule above takes effect. And on September 17, 2027, the per-entry limit for Same Day ACH rises from $1 million to $10 million (Nacha, New Rules), so a check that flags any same-day entry over $1 million will need to change on that date.
What to look for in an ACH file validation tool
For a bank onboarding treasury clients, the right tool is the one that checks the file against the client's setup and explains failures in the client's terms; structure is the minimum, not the product. These are the questions worth asking before buying, or before building.
Questions to ask before buying a Nacha file validation tool
- Does it check against each client's setup, or only the format?
Company ID, permitted entry classes, cut-off, limits and prenote rules come from the signed schedule. Ask how they get into the tool, and who keeps them current.
- Does it say which record and positions failed, and why?
"Batch 2 invalid" is a puzzle for the specialist. "Batch 2 header, positions 51–53: PPD, your schedule and payees call for CCD" is an instruction.
- Can it write the fix for the client's controller?
The person who fixes the file reads accounting-software menus, not field names.
- Which rule versions does it implement?
PAYROLL and PURCHASE descriptions from March 20, 2026; accepted characters from January 1, 2027; the Same Day ACH limit from September 17, 2027.
- Does it ever change the file?
A tool that "repairs" a client's file creates a file nobody at the client approved. It should explain and stop.
- Where does the file go?
A payroll test file holds employees' names and account numbers. It should stay inside the bank's own controls.
- What does it leave behind for audit?
Each file read, each error found, each message sent and by whom.
Free online ACH file validators: when they are enough
A free online ACH file validator is enough for a developer checking that a file generator produces well-formed output from made-up data. It is not enough for a bank checking a client's test file, for two reasons. It checks structure only, so it will pass the errors that matter most in onboarding. And a real payroll or vendor file contains people's names and account numbers, which should not be uploaded to a site outside the bank's information security program.
For a client's own accounting team, the same logic applies in reverse. A free validator is a sensible first test before sending a file to the bank, as long as it runs on test data. The bank's validation is the one that knows the agreement.
One test file, read by the File agent
In Treasury Management Onboarding, the File agent reads each client test file overnight or on arrival, against the Nacha format and against the setup drafted from the client's signed schedules. The sample client's file arrived on Monday at 4:12 PM: 212 payments for $412,860.00 in two batches. The agent read it at 6:40 the next morning in 38 seconds. Every structural check passed, as did the immediate destination, record size and format, service class, transaction codes, control totals, effective date and prenotes. Two checks failed: the company ID in the file header and both batch headers, and the entry class of the vendor batch.
From a client's test file to a passing one: what agents do and what people decide
Agent
File agent readsEvery record against the Nacha format and the client's signed setup; writes each error beside its record and positions.
Never: changes the client's file or sends anything to the network
Agent
Client agent draftsThe fix in the controller's words: what to change, where, and what stays the same.
Never: sends a message without a named person's approval
A person decides
Specialist decidesReads the errors and the draft, edits if needed, and sends it under their own name.
A person decides
Client fixes and resendsChanges the settings in its own accounting system and sends a new file.
Agent
File agent re-readsConfirms both errors are gone and nothing else changed: same payments, same total.
A person decides
Second implementer and managerCheck entitlements and limits, and confirm go-live once every line is signed.
The corrected file comes back and passes in 36 seconds
What the agent never does with a client's file
The File agent never edits a client's file and never sends one to the network, and the reason is not caution for its own sake. A file the bank repaired is a file the client's system did not produce, so the next live file, built by the same unchanged system, fails the same way, in production. The fix has to happen where the file is made. The agent's job is to make that fix fast: name the field, the record and the positions, and draft the instruction.
The same boundary runs through the rest of the solution: agents read, check and draft; a person sends, approves and decides. The overnight view on the sample desk shows the scale it works at, with 37 client test files read, 14 failed and 23 passed, each failure already explained before anyone arrived.
One client's implementation, with the test file's errors on their records
For where test files sit among the other steps to go-live, see the treasury management checklist. To see the File agent on your own clients' files, start from Treasury Management Onboarding.
Questions people ask
What is a Nacha file?
It is the fixed-width text file used to send ACH payments, laid out to Nacha's specification: a file header, one or more batches of entries each with a header and control record, and a file control record, every line exactly 94 characters. Banks and their business clients exchange payments in this format.
Is there a free ACH file validator online?
Several exist, and they are useful for checking that software produces well-formed files from test data. They check structure only, and a real payroll or vendor file holds names and account numbers that should not leave the bank's or the client's controls.
What is the most common reason an ACH file is rejected?
No public statistic ranks the causes. Structurally, record lengths and control totals that do not match are frequent; in onboarding, the costly failures are well-formed files that do not match the client's setup, such as a company ID from a previous bank or a vendor batch coded PPD.
Does a Nacha file validator check the SEC code?
It checks that the code is a valid one, and some check it against a list of permitted codes. Whether PPD or CCD is right for a batch depends on whether the receiving accounts are consumer or corporate, which a format check cannot see.
Should a bank's validator fix errors in a client's file?
No. A file the bank repaired was not produced by the client's system, so the next live file fails the same way. The validator should say exactly what to change and where, and the client should fix its own system.