Your ODFI will recompute every control total in the file and reject the whole thing if one is off by a cent. This validator recomputes the same numbers first: entry hash, batch and file debit and credit totals, entry and addenda counts, block count, plus record length, routing check digits and addenda linkage. You get the line number and the exact field of every problem.
Last updated August 2026
NACHA / ACH file validator
Pick your ACH file and see exactly what a bank would reject. Nothing is uploaded: it validates in this browser tab.
| Line | Severity | Check | Detail |
|---|
This checks the file's own structure and arithmetic. It cannot confirm an account exists, that you hold authorization, or that your bank will accept your ODFI details.
A NACHA file validator is a tool that checks an ACH file against the NACHA record layout before you send it to your bank. It confirms every record is exactly 94 characters, that record types appear in the required 1, 5, 6, 7, 8, 9 order, and that the batch and file control records agree with the entries above them on entry hash, debit total, credit total and record count. Banks reject the entire file for any one of these, without telling you which line caused it.
An ODFI validates the file arithmetic before it looks at a single payment. When something fails you usually get a rejection reference and nothing else, so the whole file comes back and you are left reading 94 character lines by eye. These are the six faults that cause most of it.
Someone edited an amount, deleted a row, or appended a payment, and the type 8 and type 9 records still carry the old totals. The file looks perfectly normal in a text editor and fails instantly at the bank.
The entry hash is the sum of positions 4 to 11 across every entry detail record, truncated to the rightmost 10 digits. Almost nobody recomputes it by hand, so any change to a routing number quietly invalidates both the batch and the file control record.
Trailing spaces get stripped by an editor, a name field runs long, or a spreadsheet export pads the wrong side. Every field after that point is read from the wrong position, so one short line corrupts an entire record.
ACH files travel in blocks of ten records and must be padded with lines of ninety-four 9s. Files built by a script routinely stop at the file control record, which fails the block count check and the blocking rule at once.
The ninth digit of an ABA routing number is a checksum over the first eight. A transposed pair still looks like a routing number and passes every format check, then comes back days later as an R03 or R04 return with a fee attached.
A batch header that declares 220 is promising credits only. Put a single debit in it and the batch is inconsistent, which is a common failure the moment someone adds an offset entry to a payroll file.
It reads the file by character position the same way a receiving bank does, recomputes what the control records claim, and reports the difference rather than a pass or fail.
Batch and file debit totals, credit totals, entry and addenda counts and the entry hash are all recalculated from the entries themselves and compared against what the type 8 and type 9 records declare. When they differ you get both numbers.
Every line is measured against the 94 character rule and the total record count is checked against the blocking factor of 10, including how many filler records are missing.
Each receiving DFI identification is run through the 3-7-1 weighted mod 10 test and compared to the check digit in position 12, which catches transposed routing numbers before they become returns.
Record types must appear in the right order, every batch header needs its control record, addenda must follow the entry that promised them in position 79, and the addenda sequence must point back at the parent trace number.
Service class codes, standard entry class codes, transaction codes, prenote amounts, effective entry dates and 15 digit trace numbers are all checked, along with the file header record size, blocking factor and format code.
An ACH file holds live routing and account numbers for real people. This validator runs in your browser tab with no upload and no account, so the file never touches a server.
Nothing to install, no account, and the file never leaves the browser.
Use the raw ACH file your accounting system, payroll software or treasury workstation produced. Extensions vary: .ach, .nacha, .txt, .dat, or no extension at all.
Tip: Files with no line breaks at all still work.
Each row gives the line number, the severity, the check that failed and the exact field positions involved, so you can go straight to the character in question instead of counting.
Tip: Errors block the file, warnings are bank specific.
Correct the source data, regenerate the file, and run it through again. Download the findings as a CSV if you need to hand them to whoever owns the system that built the file.
Tip: Fix the source, not the output file.
Anyone who originates ACH, and anyone who has been on the receiving end of a rejected file at 4pm on a Friday with payroll due Monday.
Prove a file balances before it goes to the ODFI, and confirm the debit and credit totals match what the funding entry expects.
Catch a bad routing number in a direct deposit file before payday rather than fielding calls about a missing paycheck two days later.
Check an outbound vendor payment file, or a collections debit file, when the accounting system exports something the bank silently refuses.
Test a file generator against the control record arithmetic during development, without needing a bank test window to find out the hash is wrong.
Validate the ACH output of a new payroll or ERP configuration during a go live, and show the client exactly which field the system is populating wrong.
Confirm that a transmitted payment file ties to the payment register, entry by entry and total by total.
Load the file into a validator that reads by character position and recomputes the control records, then fix the source system rather than the output. Doing it manually means confirming every line is 94 characters, summing positions 30 to 39 separately for debit and credit transaction codes, summing positions 4 to 11 for the entry hash and taking the rightmost 10 digits, counting entry and addenda records, and comparing all of that against the type 8 and type 9 records. It is arithmetic, which is exactly why it should not be done by hand on a file with 800 payments in it.
One habit worth keeping. When the validator finds a mismatch, resist editing the ACH file to make the totals agree. The file is an output. If the totals were wrong, the system that wrote it has a bug or was fed bad data, and patching the artifact means the next file is wrong too.
There are three layers, and a file can pass the first two and still fail at the bank. Structure is whether the records are the right shape and in the right order. Arithmetic is whether the control records tell the truth. Content is whether the codes and identifiers are valid values. This validator covers all three.
| Check | Where it looks | Why the bank cares |
|---|---|---|
| Record length | Every line | Fields are read by position. A 93 character line shifts everything after it. |
| Record sequence | Position 1 of each line | 1 opens the file, 5 opens a batch, 6 and 7 carry payments, 8 closes the batch, 9 closes the file. |
| Entry hash | Type 8 positions 11 to 20, type 9 positions 22 to 31 | Proves no entry was added, removed or edited in transit. |
| Debit and credit totals | Type 8 positions 21 to 44, type 9 positions 32 to 55 | The bank funds the file from these numbers. |
| Entry and addenda count | Type 8 positions 5 to 10, type 9 positions 14 to 21 | A count that is one low usually means a record was dropped. |
| Block count | Type 9 positions 8 to 13 | Total records divided by the blocking factor of 10. |
| Routing check digit | Type 6 positions 4 to 12 | A failed checksum is a routing number that does not exist. |
| Service class code | Type 5 and type 8 positions 2 to 4 | 200 mixed, 220 credits only, 225 debits only. It must match what the batch contains. |
| Addenda linkage | Type 6 position 79, type 7 positions 88 to 94 | An entry that promises addenda must have it, pointing back at the right trace number. |
| Prenote amounts | Type 6 positions 2 to 3 and 30 to 39 | Transaction codes 23, 28, 33 and 38 must carry zero dollars. |
In practice the failures cluster. Over and over, the same handful of causes account for most rejected files, and almost all of them come from a file being edited or assembled after the originating system produced it.
| Symptom | Usual cause | Fix |
|---|---|---|
| Totals do not balance | A payment was added or removed by hand after generation | Regenerate the file from the source system with the corrected data. |
| Lines are not 94 characters | An editor stripped trailing spaces on save | Use an editor that preserves trailing whitespace, or stop editing the file. |
| Whole file reads as one line | Mainframe output with no line terminators | Normal and valid. Split into 94 character chunks to read it. |
| Block count rejected | Missing filler records at the end | Pad with lines of ninety-four 9s until the record count is a multiple of 10. |
| Batch out of balance | An offset entry added to a 220 credits only batch | Change the service class code to 200, in both the type 5 and type 8 records. |
| Entries returned days later | Bad routing or account numbers that passed format checks | Validate check digits before sending, and clean the vendor or employee master. |
Nothing. They are two names for the same thing. ACH describes the network the payment travels on, and NACHA is the organization that publishes the file format and the operating rules, so people say NACHA file when they mean the file and ACH file when they mean the payments inside it. A bank asking for a NACHA formatted file and a bank asking for an ACH file want the identical 94 character fixed width text file.
What does differ is what your bank layers on top. The NACHA format is a floor, not a ceiling: individual ODFIs require particular values in the immediate destination and origin fields, some refuse balanced files with offset entries, some do not accept prenotes, and many restrict which standard entry class codes you may originate. This validator checks the format itself. It cannot know your bank's implementation guide, so read that too.
Take positions 4 to 11 of every entry detail record, which is the first eight digits of each receiving routing number, add them together as plain integers, and keep the rightmost 10 digits of the result. Addenda records are not included and the check digit in position 12 is not included. The batch control record carries the hash for its own batch, and the file control record carries the sum of the batch hashes, truncated the same way.
A worked example. Three entries with receiving DFI identifications of 11100002, 02100002 and 31100022 sum to 44300026, which is under 10 digits, so the entry hash is 44300026 padded to ten characters as 0044300026. The truncation only matters on large files, where the sum genuinely runs past 10 digits and the leftmost digits are discarded rather than rounded.
As a rule, no. An ACH file contains full routing numbers, full account numbers and the names attached to them, for everyone in the file. Sending that to a server you do not control is a data exposure, and for a payroll file it is your employees' banking details. Plenty of online ACH tools do exactly that.
The validator on this page reads the file with the browser's own FileReader and does all the work in the page. Nothing is transmitted, there is no account, and you can confirm it by opening your browser's network tab while you validate, or by disconnecting from the internet after the page loads and running it anyway. If you would rather not use any web tool at all, the open source moov-io ACH library does the same checks locally.
A clean file is the start. Once it is sent, the same 94 character records come back to you in other forms, and the questions change from does this parse to what happened to my money. Converting the file to rows makes both jobs easier, which the NACHA file to Excel converter handles, and the field by field layout is documented in the NACHA file format reference if you need to read a record by hand. The walkthrough on how to open a NACHA ACH file in Excel covers the import settings that keep leading zeros intact.
Then there are returns. Entries that fail after settlement come back with a two character code, and ACH return codes explains what R01 through R29 mean, which are administrative and which count against Nacha's unauthorized return rate. Remittance detail riding along with a corporate payment is X12, which the EDI 820 to Excel converter reads, and the reporting files your bank sends back are a different family again: BAI2 balance reporting, MT940 SWIFT statements, and camt.053 ISO 20022 XML. The bank file format converter compares all of them if you are not sure what landed in your folder. For check issuance rather than ACH, the positive pay file format reference covers the upload your bank matches against presented checks, and tying the whole day back to the statement is bank statement reconciliation. If the underlying problem is that approving and paying invoices is manual in the first place, accounts payable automation is the layer above the file.
It is a tool that checks an ACH file against the NACHA record layout before your bank sees it. It confirms every record is 94 characters, that record types run in the required 1, 5, 6, 7, 8, 9 order, and that the batch and file control records agree with the entries above them on entry hash, debit total, credit total and record count.
Run it through a validator that reads the file by character position and recomputes the control totals, then compare what it calculates against what the type 8 and type 9 records claim. The validator on this page does that in your browser and returns the line number and field positions for every mismatch.
Most rejections come from six causes: control totals that went stale after a manual edit, a record that is not exactly 94 characters, a record count that is not a multiple of 10, an entry hash that no longer matches the routing numbers, a service class code that contradicts the entries in the batch, and a routing number that fails its check digit.
Exactly 94, for every record type. There are no delimiters anywhere in the file, so each field is identified by its character position. The file header declares this itself: positions 35 to 37 hold 094 as the record size and positions 38 to 39 hold 10 as the blocking factor.
ACH files are transmitted in blocks of ten records, so the total record count must be a multiple of 10. Files are padded at the end with filler records made of ninety-four 9s. The block count in positions 8 to 13 of the file control record is the total record count divided by 10.
Add positions 4 to 11 of every entry detail record together as integers, then keep the rightmost 10 digits. That is the first eight digits of each receiving routing number, without the check digit. Addenda records are excluded. The file control hash is the sum of the batch hashes, truncated the same way.
They are the same file. ACH is the payment network and NACHA is the body that publishes the format and the operating rules, so the terms get used interchangeably. A bank asking for a NACHA formatted file wants the same 94 character fixed width text file as a bank asking for an ACH file.
Almost always an arithmetic or structural fault rather than a payment problem. The batch or file control record disagrees with the entries, a line is the wrong length, the record count is not blocked to 10, or a batch header and its control record do not match on service class code, company identification or batch number. Validating the file first tells you which.
Generally not, because the file holds full routing numbers, account numbers and names for everyone paid in it. This validator avoids the problem by never uploading: it reads the file with the browser FileReader and runs entirely in the page, which you can confirm in your browser network tab.
Turn the ACH file into spreadsheet rows.
Every record type, field by field.
Read the remittance riding with the payment.
Compare bank file formats side by side.
Cancel anytime from your account settings · refund policy
Get started converting bank statements to spreadsheets.
USD
per month
billed as
$288 yearly
Choose speed vs accuracy when extracting
| Base AI Faster | 2,500 pages |
| Pro AI Best accuracy | 500 pages |
Scale statement conversion across your team with automation.
USD
per month
billed as
$888 yearly
Choose speed vs accuracy when extracting
| Base AI Faster | 10,000 pages |
| Pro AI Best accuracy | 2,000 pages |
Enterprise-grade bank statement conversion and controls.
USD
per month
billed as
$ yearly
Choose speed vs accuracy when extracting
| Base AI Faster | pages |
| Pro AI Best accuracy | pages |
