Below is a complete, balanced PPD payroll file in NACHA format, all ten records, every line exactly 94 characters, with the entry hash and the batch totals worked out so the numbers actually foot. Each record is then decoded field by field. If you have a real file rather than an example, the converter above turns it into spreadsheet rows without counting character positions.
Last updated August 2026
Upload your bank statement
Drop file here or click to upload
PDF, JPG, PNG, BMP, HEIC, TIFF, MT940
Uploading...
A NACHA file is a plain text file where every line is exactly 94 characters and the first digit of each line says what the record is: 1 is the file header, 5 opens a batch, 6 is a single payment, 7 is optional addenda, 8 closes the batch and 9 closes the file. There are no commas, no column headers and no delimiters of any kind. Fields are found by counting character positions. Numeric fields are right justified and padded with leading zeros, text fields are left justified and padded with trailing spaces, and the file is padded with lines of 9s until the record count reaches a multiple of ten.
The specification tells you a field sits at positions 55 to 76. It does not show you what that looks like in a real file, which is the part people actually need.
A CSV has commas. A NACHA file has nothing. The only way to find the amount is to count to character 30 and read ten characters, and one miscount shifts every field after it.
A payment of $2,450.00 is written 0000245000. The last two digits are always cents, so reading the number as written overstates every amount by a factor of one hundred.
Most published layouts are field grids in a PDF. Very few show a full valid file, so you cannot check your own output against a known good sample.
The batch and file control records repeat counts, an entry hash and dollar totals. If any one of them disagrees with the entries above it, the bank rejects the whole file rather than the bad line.
Open a .ach file in Excel and it guesses at delimiters, drops the leading zeros from routing numbers and reformats the dates. The file is corrupt before you have read it.
Files often end with one or more lines of ninety four 9s. That is deliberate padding, not damage, and people delete it and break the block count.
An example teaches you the layout. A converter saves you from applying it by hand to two thousand entries.
Record types 1, 5, 6, 7, 8 and 9 are split at the correct positions, so the routing number, account, amount and receiver name land in separate columns.
The implied two decimal places are restored, so 0000245000 arrives as 2450.00 and the sheet totals to the same figure as the batch control record.
Codes 22, 27, 32 and 37 become readable credit and debit labels against checking or savings, and prenotes are marked as prenotes rather than zero dollar payments.
Routing numbers and account numbers keep every character, which is the single most common thing lost when an ACH file is opened directly in a spreadsheet.
Each entry stays tied to its batch header, so the company name, SEC code, entry description and effective entry date follow the payment into the sheet.
ACH files carry account numbers. Uploads use 256-bit encryption and you can delete files from your account whenever you want.
Nothing to install and no credit card to start.
Your bank portal, payroll system or ERP will have written it with a .ach, .txt, .nacha or no extension at all. It is plain text either way.
Tip: Open it in a text editor first, never in Excel.
Drag it into the box above. Record types are detected from the first character of each line, so no template or field mapping is needed.
Tip: Several files in one batch are fine.
Save as XLSX or CSV, then total the amount column and compare it against the debit and credit totals in the 8 and 9 records. If they match, nothing was dropped.
Tip: That check takes ten seconds and catches every parsing error.
Almost everyone who looks for a sample NACHA file is either building one for the first time or trying to work out why the bank rejected the one they already sent. Both jobs need a known good reference to compare against.
Building ACH origination into an ERP or a payments product and needing a valid file to test the parser against.
Reviewing what the bank will receive before a payroll or vendor run goes out, and confirming the offset entry is right.
Working out which employee or vendor sits behind a rejected entry when the bank quotes a trace number and nothing else.
Tying an ACH batch back to the general ledger when the bank statement shows one lump sum instead of the individual payments.
This is a balanced PPD payroll file: three employees paid by direct deposit, plus a single offset debit that pulls the total from the company operating account. It is ten records long, every line is exactly 94 characters, and the control totals and entry hash below are calculated from the entries above them rather than made up.
101 09100001911234567892608170930A094101WELLS FARGO BANK NORTHWIND TRADING CO 5200NORTHWIND TRADIN 1123456789PPDPAYROLL AUG 17260821 1091000010000001 6221210002481745500219 0000245000EMP00417 MARIA GONZALEZ 0091000010000001 622026009593398210044 0000187550EMP00892 DERRICK OKONKWO 0091000010000002 6220210000210092374115 0000310025EMP01130 SUSAN CHEN 0091000010000003 6270910000194455102388 0000742575OFFSET NORTHWIND TRADING CO 0091000010000004 820000000400259009860000007425750000007425751123456789 091000010000001 9000001000001000000040025900986000000742575000000742575 9999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 9999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999
Copy it into a text editor with a fixed width font and turn off word wrap. Every line should end in the same column. If one does not, a field has been padded to the wrong length, and that alone is enough for a bank to reject the file.
| Line | Record | What it says |
|---|---|---|
| 1 | File Header (1) | Northwind Trading sends a file to Wells Fargo, created 17 August 2026 at 09:30, file ID modifier A, 94 character records blocked in tens. |
| 2 | Batch Header (5) | Service class 200 (mixed debits and credits, because the batch is balanced), SEC code PPD, entry description PAYROLL, effective entry date 21 August 2026, batch number 1. |
| 3 to 5 | Entry Detail (6) | Three checking credits, transaction code 22, for $2,450.00, $1,875.50 and $3,100.25, each with the employee routing number, account, ID and name. |
| 6 | Entry Detail (6), offset | One checking debit, transaction code 27, for $7,425.75 against the company account. This is what makes the file balanced. |
| 7 | Batch Control (8) | 4 entries, entry hash 0025900986, total debits $7,425.75, total credits $7,425.75. Debits equal credits, so the batch nets to zero. |
| 8 | File Control (9) | 1 batch, 1 block, 4 entries, the same hash and the same dollar totals repeated at file level. |
| 9 and 10 | Filler (9) | Two lines of ninety four 9s. Eight real records is not a multiple of ten, so the file is padded to ten. |
Take line 3 of the example and split it at the documented positions. This is the record people most often need to read, because it is where the money and the receiver are.
| Position | Field | Value in the example | Reading |
|---|---|---|---|
| 01 | Record Type Code | 6 | An entry detail record. |
| 02-03 | Transaction Code | 22 | Automated checking credit, so money is going into the receiver account. |
| 04-11 | RDFI Routing Number | 12100024 | The first eight digits of the receiving bank routing number. |
| 12 | Check Digit | 8 | The ninth digit, held separately so transpositions can be caught. Together: 121000248. |
| 13-29 | DFI Account Number | 1745500219 | 17 characters, left justified and blank filled, so the trailing spaces are padding and not part of the account. |
| 30-39 | Amount | 0000245000 | $2,450.00. Ten digits, no decimal point, last two digits are cents. |
| 40-54 | Individual Identification Number | EMP00417 | The originator own reference for the receiver. Optional, and never a Social Security number. |
| 55-76 | Individual Name | MARIA GONZALEZ | 22 characters. This is the INDN fragment that later shows up on the receiver bank statement. |
| 77-78 | Discretionary Data | (blank) | Free for the originator to use. |
| 79 | Addenda Record Indicator | 0 | 0 means no addenda follows. A 1 means the next line is a type 7 record. |
| 80-94 | Trace Number | 091000010000001 | The originating bank routing prefix 09100001 followed by the sequence number 0000001. This is the reference the bank quotes back to you. |
Every other record splits the same way, at its own set of positions. The complete grid for all six record types, including the file header, batch header, addenda, batch control and file control layouts, sits on the NACHA file format reference page.
The entry hash is the one control figure people get wrong, because it is not a checksum in the usual sense. You add together the eight digit routing prefixes of every entry in the batch, excluding the check digit, then keep the ten rightmost digits of the result. In the example that is:
| Entry | Routing prefix | Running total |
|---|---|---|
| Maria Gonzalez | 12100024 | 12100024 |
| Derrick Okonkwo | 02600959 | 14700983 |
| Susan Chen | 02100002 | 16800985 |
| Offset debit | 09100001 | 25900986 |
| Written into the file | 10 digits, zero filled | 0025900986 |
Note that the offset entry counts. That trips people up, because the offset is the company own account rather than a payee, but it is still an entry detail record and it still contributes to the hash, the entry count and the totals. There is a longer walkthrough, including what happens when the sum exceeds ten digits, in the guide to the entry hash in a NACHA file.
The example above is balanced. The distinction decides whether you include that sixth line at all, and banks differ on which one they want.
| Type | What the file contains | Service class code | Who asks for it |
|---|---|---|---|
| Balanced | The payments plus an offset entry against the originator own account, so debits equal credits and the batch nets to zero. | 200 | Banks that want the funding movement stated explicitly inside the file. |
| Unbalanced | Only the individual payments. The bank creates the offset against your account itself. | 220 credits only, or 225 debits only | Banks that fund the batch from a settlement account they already have on file. |
To turn the example into an unbalanced file, delete line 6, change the service class code from 200 to 220 in both the batch header and the batch control record, drop the entry count to 3, recalculate the entry hash without 09100001, and set the total debit amount to zeros. Then repad to a multiple of ten. Sending a balanced file to a bank that expects an unbalanced one usually produces a duplicate debit, which is the sort of error that is noticed on payday.
The record structure does not change between Standard Entry Class codes. What changes is the three characters at positions 51 to 53 of the batch header, and the rules that then apply to the batch.
| SEC code | Used for | Addenda allowed | Typical entry description |
|---|---|---|---|
| PPD | Payments to and from consumer accounts: payroll direct deposit, mortgage autopay, benefit payments. | 1 | PAYROLL |
| CCD | Business to business: vendor payments, tax payments, sweeps between company accounts. | 1 | VENDOR PMT |
| WEB | Consumer debits authorized on a website or in an app, including most subscription billing. | 1 | PURCHASE |
| CTX | Corporate payments carrying structured remittance data for many invoices in one entry. | Up to 9,999 | TRADE PMT |
Two of those entry descriptions became mandatory rather than conventional on 20 March 2026, when Nacha standardized PAYROLL for PPD credits paying wages and PURCHASE for WEB debits covering consumer e-commerce. If you are generating files, those exact words now belong in positions 54 to 63 for those two cases. The wider set of class codes and the authorization rules behind each one are covered in the ACH SEC codes guide.
Set the addenda indicator at position 79 to 1 and follow the entry with a type 7 record. The addenda carries the remittance text a vendor needs in order to apply your payment to the right invoices.
6220260095933982100440 0000450000INV884120 RIVERBEND SUPPLY CO 1091000010000005 705RMR*IV*INV88412*PO4471\ 00010000005
In the addenda record, position 1 is the record type 7, positions 2 to 3 are the addenda type code (05 for the general payment related information used with CCD and PPD), positions 4 to 83 hold the 80 characters of payment related information, positions 84 to 87 are the addenda sequence number and positions 88 to 94 repeat the last seven digits of the entry trace number so the addenda can be matched back to its entry. Note that the entry above now ends in 1 at position 79 rather than 0.
The header declares a blocking factor of 10 at positions 38 to 39, which means the file must contain a whole number of ten record blocks. The example has eight real records, so two filler lines of ninety four 9s bring it to ten, and the block count in the file control record is 1. Nine real records would need one filler line. Twenty one real records would need nine. The filler lines are not payments, they are not counted in the entry count, and deleting them to tidy the file up is a reliable way to get it rejected.
Four checks catch almost every malformed file, and all four can be done before the bank sees it. Confirm that every line is 94 characters with no trailing carriage return oddities. Confirm the record count is a multiple of ten. Confirm the entry count and dollar totals in the 8 and 9 records match the entries you actually wrote. Confirm the entry hash is the sum of the eight digit routing prefixes truncated to ten digits. The NACHA file validator runs those checks against a file you upload, and if you would rather see the data than the diagnostics, the NACHA file to Excel converter turns the entries into rows you can total.
Once an ACH batch has settled, it stops being a file problem and becomes a reconciliation problem, because most banks post the whole batch to your account as one lump sum rather than as individual payments. Matching that single statement line back to the entries means having both sides as data, which is where converting the bank statement converter output alongside the ACH file pays off. The abbreviations the bank uses on those posted lines, including DES, INDN, CO ID and the SEC fragment, are decoded in the bank statement abbreviations reference. If an entry comes back instead of posting, the reason arrives as an R code, and those are listed in the ACH return codes reference.
It looks like a block of unbroken digits and capital letters, every line exactly 94 characters long, with no commas and no headers. The first character of each line identifies the record: 1 for the file header, 5 for a batch header, 6 for a payment, 7 for addenda, 8 for a batch control and 9 for the file control. Files usually end with one or more lines of ninety four 9s as padding.
Yes. A NACHA file is plain ASCII text, so it opens in any text editor regardless of the extension. You will see .ach, .txt, .nacha, .dat or no extension at all depending on the system that produced it. Renaming it does not change the contents. What you should avoid is opening it in Excel, which strips leading zeros from routing numbers.
There is none in practice. ACH is the payment network, and Nacha is the organization that writes the rules and publishes the file specification, so people call the same 94 character fixed width file by either name. NACHA formatted file, ACH file and ACH094 all describe the identical layout shown in the example above.
A balanced file includes an offset entry against the originator own account, so total debits equal total credits and the batch nets to zero. The example above is balanced: three credits of $7,425.75 combined, matched by one debit of $7,425.75. An unbalanced file contains only the payments and lets the bank create the offset. Ask your bank which one it expects, because sending the wrong type can produce a duplicate debit.
Add together the eight digit routing prefixes of every entry detail record in the batch, leaving out the ninth check digit, then keep the ten rightmost digits and pad with leading zeros. In the example the four prefixes sum to 25900986, which is written into the file as 0025900986. Offset entries count toward the hash just like payments do.
Because the blocking factor is 10, so the total record count has to be a multiple of ten. The example has eight real records, so two lines of ninety four 9s pad it out. Those filler lines are not transactions and are excluded from the entry count, but removing them breaks the block count and the bank will reject the file.
Do not open it directly, because Excel guesses at delimiters and drops the leading zeros from routing and account numbers. Either import it as fixed width and set the break positions by hand for each record type, or run it through a converter that already knows the layout. Splitting by record type matters, since a type 5 line and a type 6 line use completely different field positions.
The ten line example on this page is a complete valid file you can copy into a text editor and use as test input. It is balanced, the totals foot and the entry hash is correct, so a parser that reads it properly will read a production file too. Replace the routing numbers, accounts and amounts with your own before sending anything to a bank.
They sit at positions 2 and 3 of an entry detail record and say what kind of account movement it is. 22 is an automated checking credit, money going into a checking account. 27 is an automated checking debit, money coming out. The savings equivalents are 32 and 37, and the prenote versions, which carry a zero amount and only verify the account, are 23, 28, 33 and 38.
Yes. A file can hold many batches, each opened by its own type 5 record and closed by its own type 8 record, with batch numbers assigned in ascending order. That is how a payroll run and a vendor run travel in one file: separate batches, different SEC codes and entry descriptions, then a single type 9 file control record summarizing all of them at the end.
Every record type, field by field, with exact positions.
Check counts, totals and the entry hash before you send.
Turn the entries into spreadsheet rows.
How these fields read once they post to a statement.
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 |
