# NACHA Navigator: every page > The Markdown version of every page on https://nacha-navigator.com/, in one file: the tools, the developer docs, the references, then the site pages. Each page starts with its URL. The index is https://nacha-navigator.com/llms.txt. --- URL: https://nacha-navigator.com/ # Read any NACHA file, field by field. Free NACHA file viewer & ACH validator Drop in an ACH file to see every 94-character record decoded field by field, in the right layout for each SEC code, including IAT, returns and NOCs. It checks totals, entry hashes, routing check digits, dates and codes against the NACHA format, and builds reversal files. Parsing happens entirely in your browser. - Field-level decoding - Control totals & check digits - Reversal files ## 100% in-browser. Your ACH file never leaves this device. ### Parsed on your device JavaScript on this page reads the file. Nothing is uploaded, stored or transmitted. ### No account, no cost Viewing, validating and building reversals are free. No sign-up, ever. ### Open about usage Our [public analytics](https://nacha-navigator.com/analytics) show exactly what we count — never what your files contain. **0 bytes** of your file are uploaded; the only requests are anonymous counters (a page view, a file opened). See for yourself in your browser’s developer tools (Network tab). Anatomy of a record ## Ninety-four characters, fully accounted for. Every line of a NACHA file is a fixed-width record. Navigator names each field, colors it by what it holds and measures exactly where it sits — so you can see at a glance where the routing number ends and the amount begins. **Line 03** Entry detail · PPD checking credit, from the sample file ### What each field holds **1 Record Type Code**: Identifies the type of record in the file. **2–3 Transaction Code**: Identifies the type of account and whether the entry is a credit, a debit, a prenote, a zero-dollar entry or a return/NOC. **4–11 Receiving DFI Identification**: First 8 digits of the routing number of the Receiver's financial institution (the RDFI). **12 Check Digit**: The ninth digit of the RDFI routing number, computed from the first eight. **13–29 DFI Account Number**: The Receiver's account number at the RDFI. **30–39 Amount**: The amount of the entry, in cents. **40–54 Individual Identification Number**: Number the Originator uses to identify the Receiver, such as an employee ID, customer or loan number. **55–76 Individual Name**: Name of the Receiver. **77–78 Discretionary Data**: For the ODFI or Originator to use as they agree; it has no meaning to the ACH Network. **79 Addenda Record Indicator**: Shows whether one or more Addenda Records follow this entry. **80–94 Trace Number**: Uniquely identifies the entry within its batch and lets it be traced through the ACH Network. Every record type, field by field: [the NACHA file format reference](https://nacha-navigator.com/nacha-file-format) What it does ## Catch it here, before your bank does. The same checks your bank runs before it accepts a file — record lengths, control totals, hashes and check digits — explained in plain language, line by line. No. 01 ### Decode Every record type — File Header (1), Batch Header (5), Entry Detail (6), Addenda (7), Batch Control (8) and File Control (9) — split into named, color-coded fields, with the right layout for PPD, CCD, CTX, WEB, TEL, IAT, returns and NOCs. No. 02 ### Validate Record length, control totals, entry hash, routing check digits, effective dates, SEC and transaction codes, and blocking-factor padding. Each problem is pinned to its line and column, with the expected value when there is a single right one. No. 03 ### Reverse Pick the entries to undo — one, a whole batch or the entire file — and download a reversal file: transaction codes flipped, control totals recalculated and the REVERSAL company entry description set. No. 04 ### Audit Reconcile debit and credit totals, entry and addenda counts and entry hashes against your payment register before you send, then export the entries to CSV or JSON. Related tools ## More free tools for payment files. The same private, in-browser approach for the other formats that land on an operations desk. X9.37 · Image cash letter New ### X9 Viewer Open X9.37 check image files in your browser. See every item’s front and back images, its MICR line and the record behind it — inspected the same field-by-field way, with bundle and cash letter totals checked. Opens `.x9` `.x937` `.icl` files [Open X9 Viewer](https://nacha-navigator.com/x9-viewer) BAI2 · Balance reporting ### BAI2 Viewer Turn BAI2 bank reports into readable account summaries and transaction detail, with every type code explained. [Open BAI2 Viewer](https://nacha-navigator.com/bai2-viewer) Build files · Builder and REST API ### NACHA Generator Build a valid NACHA file in the visual builder — or send JSON to the free REST API. Control totals, entry hash and block padding are done for you, and the result opens right here in the viewer. [Open the builder](https://nacha-navigator.com/nacha-generator) [Read the API docs](https://nacha-navigator.com/nacha-generator/api) ACH · Reversals ### ACH Reversal Reverse a whole NACHA file or just the entries you choose: transaction codes flipped, REVERSAL as the company entry description, the control totals recalculated and the five-banking-day window checked. [Reverse an ACH file](https://nacha-navigator.com/ach-reversal) Questions ## Before you open a file. Short answers to what people ask most. The full answers, with real-world use cases for payroll, banking, treasury and compliance teams, are on the [use cases page](https://nacha-navigator.com/use-cases). **Why was my NACHA file rejected by my bank?** Common rejection causes include incorrect record lengths (lines must be exactly 94 characters), unbalanced batch or file control totals, invalid routing number check digits, bad effective entry dates, missing blocking-factor padding (files must contain a multiple of 10 records), and malformed Standard Entry Class (SEC) codes. **How do ACH reversals work?** Under Nacha rules, an originator may reverse an erroneous entry (duplicate, wrong amount, wrong account, or wrong date) by submitting a reversing entry within five banking days of the settlement date of the original entry. **Is my ACH file data secure when I use NACHA Navigator?** Yes. NACHA Navigator parses your file entirely in your browser using client-side JavaScript. **What is a NACHA file?** A NACHA file is a fixed-width text file format defined by Nacha (the National Automated Clearing House Association) for submitting ACH payments in the United States. [Read every answer and the use cases](https://nacha-navigator.com/use-cases) ## Limits - It reads and checks files and builds reversals. It doesn’t send anything to your bank or the ACH Network: you submit files through your bank’s own channel. - Routing numbers are checked by their check digit only, so it can’t tell whether a bank or an account exists, is open or belongs to the receiver. [PayOps Kit](https://payopskit.com/), a sister site, has routing number tools. - It doesn’t know your bank’s (ODFI’s) own requirements, such as cutoff times, file names or a balanced file with offset entries. - It doesn’t edit files. Fix the system that made the file, or build a new one in the [NACHA Generator](https://nacha-navigator.com/nacha-generator). - Its checks are informational, not a compliance review. The Nacha Operating Rules are the authority, and NACHA Navigator is not affiliated with or endorsed by Nacha. ## Reference - [NACHA file format](https://nacha-navigator.com/nacha-file-format) Every record type and field, position by position. - [NACHA file errors](https://nacha-navigator.com/nacha-file-errors) What each check means and how to fix it. - [ACH transaction codes](https://nacha-navigator.com/ach-transaction-codes) What each two-digit transaction code means. - [ACH Reversal](https://nacha-navigator.com/ach-reversal) Reverse chosen entries or a whole ACH file. - [Sample files](https://nacha-navigator.com/sample-files) Example NACHA, BAI2 and X9 files to download and open. Last updated October 30, 2026 ## Need More Than File Analysis? Looking for enterprise-grade NACHA file generation, batch processing, or automated ACH workflows? We’re developing advanced tools for financial institutions and treasury departments. [Discuss Enterprise Solutions](mailto:davidkaylor95+nachanav@gmail.com?subject=Interest%20in%20NACHA%20File%20Generation%20Tools&body=Hi%2C%20I'm%20interested%20in%20learning%20more%20about%20NACHA%20file%20generation%20and%20editing%20capabilities%20for%20our%20organization.) --- URL: https://nacha-navigator.com/ach-reversal # Reverse an ACH file or its entries Free ACH reversal file generator Open the original NACHA file, pick the entries to undo — one, a batch or the whole file — and download a reversal file with the transaction codes flipped, REVERSAL as the company entry description and the totals recalculated. It all happens in your browser. - Transaction codes flipped - Five-banking-day deadline checked - Receiver notices drafted ## 100% in-browser. Your file never leaves this device. ### Parsed on your device JavaScript on this page reads the file. Nothing is uploaded, stored or transmitted. ### No account, no cost Every tool is free to use. No sign-up, no paywall, ever. ### Open about usage Our [public analytics](https://nacha-navigator.com/analytics) show exactly what we count — never what your files contain. **0 bytes** of your file are uploaded; the only requests are anonymous counters (a page view, a file opened). Check it yourself in your browser’s developer tools (Network tab). How it works ## From the original file to its reversal. The reversal is built from the file you sent, so every entry keeps its Receiver, account and amount. Nothing is typed in again. 1. Step 1 ### Open the original file Drop the NACHA file that carried the erroneous entries, or [try the demo](https://nacha-navigator.com/?sample=reversal-demo#reverse). It opens in the NACHA Viewer’s Generate Reversal tab and stays in this browser tab. 2. Step 2 ### Select entries Pick the erroneous entries, a whole batch at once, or the entire file. Entries that can’t be reversed, such as prenotes and returns, are marked with the reason. 3. Step 3 ### Reason and dates Say why the entries are being reversed and choose the effective date. The tool shows the deadline: five banking days after the original entries settled. 4. Step 4 ### Review and generate The tool builds the file, checks it against the rules and the original, and lets you download it only once it passes NACHA validation, with a notice to send each Receiver. The rules ## What a reversal may and may not do The Nacha Operating Rules allow a reversal only to correct an erroneous entry, in a fixed format, within five banking days. These are the rules the tool applies, in plain terms. Last updated October 30, 2026 ### When you can reverse an entry Only an erroneous entry can be reversed. The reason is not written in the file, since a reversing entry has no field for it, but it goes into the notice to the Receiver. | Reason | What happened | Whole file | Afterwards | | --- | --- | --- | --- | | Duplicate entry | The entry (or the whole file) repeats one the Originator already sent. | Yes | — | | Wrong Receiver / account | The entry paid or debited a different Receiver or account than the Originator intended. | Yes | Send the payment to the intended Receiver as a separate, new entry. | | Wrong amount | The entry was for a different dollar amount than the Originator intended. | Yes | Reverse the full amount, then send a new entry for the correct amount. | | Wrong date (debit earlier than intended) | A debit carried an Effective Entry Date earlier than the Originator intended. | Yes | If the payment is still due, send a new debit with the intended date. | | Wrong date (credit later than intended) | A credit carried an Effective Entry Date later than the Originator intended. | Yes | If the payment is still owed, send a new credit with the intended date. | | PPD credit already paid by a check at separation | A PPD credit of employment-related funds that were already paid in full by a check delivered to the Receiver at or before separation from employment, where the credit was sent before the check was delivered. | No, entries only | — | ### When you can’t None of these makes an entry erroneous, so none of them is a reason to reverse it. | Situation | Why it isn’t a reason | What to do instead | | --- | --- | --- | | Insufficient funds | A debit that bounced, or a credit the Originator cannot cover, is not an erroneous entry. | An unpaid debit comes back as a return from the Receiver’s bank (R01 or R09); a credit must be funded. | | The Originator or a Third-Party Sender did not fund the original credit | The Rules name a funding failure as an improper reason for a reversal. | Arrange funding with your ODFI. | | A dispute with the Receiver | A disagreement about goods, services or an invoice is not an error in the entry. | Resolve it with the Receiver; any new debit needs the Receiver’s authorization. | | A change of mind | An entry sent as intended cannot be pulled back because plans changed. | Ask the Receiver to return the funds, or ask your ODFI to request a return (R06), which the Receiver’s bank may decline. | | The Receiver says a debit was unauthorized | Unauthorized debits are handled by the Receiver’s bank through returns (R05, R07, R10 or R11 for a consumer account; R29 for a business account). | Do not reverse; refund the Receiver with a separate credit if you agree. | | More than five banking days after settlement | A reversal made available to the Receiver’s bank after the window is improper; that bank may return it (R11 or R17). | Ask your ODFI to request a return of the erroneous entry (R06). | | Reversing only part of the amount | A reversing entry carries exactly the amount of the erroneous entry. | Reverse the full amount, then send a new entry for the correct amount. | ### What a reversing entry looks like - **Company Entry Description:** `REVERSAL`, in place of the original batch’s description. - **Company Identification and SEC code:** unchanged from the original batch. The Company Name must still identify the same Originator; the tool copies it as it was. - **Amount:** the full amount of the erroneous entry. To correct an amount, reverse the whole entry and send a new one for the right amount. - **Transaction Code:** the same kind of account, the other direction (table below). - **Service Class Code:** worked out again for the reversal batch: 220 when it holds only credits, 225 when it holds only debits, 200 when it holds both. - **Trace numbers:** new ones, starting with the ODFI routing number from the batch header. #### Transaction codes and their reversals | Original | Account | Original moves | Reversal | | --- | --- | --- | --- | | [22](https://nacha-navigator.com/ach-transaction-codes#code-22) | Checking | Credit | [27](https://nacha-navigator.com/ach-transaction-codes#code-27) | | [27](https://nacha-navigator.com/ach-transaction-codes#code-27) | Checking | Debit | [22](https://nacha-navigator.com/ach-transaction-codes#code-22) | | [32](https://nacha-navigator.com/ach-transaction-codes#code-32) | Savings | Credit | [37](https://nacha-navigator.com/ach-transaction-codes#code-37) | | [37](https://nacha-navigator.com/ach-transaction-codes#code-37) | Savings | Debit | [32](https://nacha-navigator.com/ach-transaction-codes#code-32) | | [42](https://nacha-navigator.com/ach-transaction-codes#code-42) | General ledger | Credit | [47](https://nacha-navigator.com/ach-transaction-codes#code-47) | | [47](https://nacha-navigator.com/ach-transaction-codes#code-47) | General ledger | Debit | [42](https://nacha-navigator.com/ach-transaction-codes#code-42) | | [52](https://nacha-navigator.com/ach-transaction-codes#code-52) | Loan | Credit | [55](https://nacha-navigator.com/ach-transaction-codes#code-55) | | [55](https://nacha-navigator.com/ach-transaction-codes#code-55) | Loan | Debit | [52](https://nacha-navigator.com/ach-transaction-codes#code-52) | Transaction Code 55, a loan debit, exists only to reverse a loan credit (52). Prenotes, zero-dollar entries, notifications of change and ADV records move no money, so there is nothing to reverse. A return is the Receiver’s bank sending an entry back, not an entry the Originator can reverse; an ODFI answers a faulty return by [dishonoring it](https://nacha-navigator.com/nacha-file-format#addenda-99-dishonored) (R61, R62, R67–R70). A reversal normally moves money against its SEC code’s usual direction. Under ARC, BOC, POP, RCK, TEL and XCK, which carry only debits, a reversing credit keeps the SEC code, and so does a reversing debit under CIE, which carries only credits (return reasons R36 and R35 make these exceptions). For other one-way SEC codes, such as TRC and TRX, ask your bank how to correct the entry. The tool doesn’t reverse IAT entries yet. ### The five-banking-day window A reversing entry must be made available to the Receiver’s bank within five banking days after the settlement date of the erroneous entry. Banking days are Monday to Friday, except Federal Reserve holidays. A debit reversal may not carry an Effective Entry Date earlier than the credit it reverses. The tool counts the deadline from the original batch’s settlement date: the one an ACH Operator wrote in the batch header, the one you enter from your bank statement, or else the Effective Entry Date. For date math outside the tool, [PayOps Kit’s ACH dates tool (opens in a new tab)](https://payopskit.com/ach-dates) works out return, NOC and reversal deadlines. When the window has closed, a reversal is no longer allowed. Ask your bank (the ODFI) to request a return of the erroneous entry instead, with return reason R06; the Receiver’s bank may decline. ### Telling the Receiver The Originator must make a reasonable attempt to tell each Receiver about the reversal and its reason no later than the reversal’s settlement date. For a PPD credit already paid by a check at separation, the Receiver must be told at the time the check is delivered. Before it generates a file, the tool asks you to confirm the notice, and it drafts one for each Receiver, with the account number masked. ### Reversing a whole file A reversing file undoes every entry of a file sent in error. Unless the erroneous file was a duplicate, it goes with a correcting file that carries the right entries; the [NACHA Generator](https://nacha-navigator.com/nacha-generator) can build one. Send the reversing file, and any correcting file, within 24 hours of discovering the error, as well as within the five-banking-day window. A PPD credit already paid by check at separation can be reversed only as a single entry, not with a whole file. ### If a reversal is improper A reversal sent for a reason the Rules don’t allow, or after the window, is improper. The Receiver’s bank can return it with return reason R11 for a consumer account, within 60 days once the Receiver signs a written statement, or with R17 within two banking days. A reversal also isn’t guaranteed to post: the Receiver’s bank doesn’t have to accept a reversing entry, and a reversing debit can be returned, for example for insufficient funds. ## Sources These rules follow the Nacha Operating Rules on reversing files and reversing entries, as summarized in Nacha’s public page on the 2021 reversals rule, and the return reason codes in Appendix Four. Your bank’s agreement may add requirements of its own. NACHA Navigator is independent and not affiliated with or endorsed by Nacha. This page is for information only; it is not legal or compliance advice. [Nacha on reversals (opens nacha.org in a new tab)](https://www.nacha.org/rules/reversals-and-enforcement) [Try the demo](https://nacha-navigator.com/?sample=reversal-demo#reverse) --- URL: https://nacha-navigator.com/x9-viewer # Open X9 files and see every check, front and back. Free X9.37 check image viewer Drop in an X9.37 image cash letter to see each item’s front and back images, its MICR line and every record behind it, with bundle, cash letter and file totals checked. It reads X9.100-187 files (the 2008 to 2016 editions, Standard Level 30 or 35) and DSTU X9.37-2003 files, in EBCDIC or ASCII. Parsing happens entirely in your browser. - Front & back check images - MICR line decoded - Control totals checked ## 100% in-browser. Your X9 file never leaves this device. ### Secure processing Your data never leaves your browser: the file is read and its check images are decoded on this device. Nothing is uploaded, stored or sent. ### Fast analysis Immediate parsing of your X9.37 files, with no upload limit. Files over 1 MB are parsed in a background thread so the page stays responsive. ### Open about usage Our [public analytics](https://nacha-navigator.com/analytics) count how often the viewer is used — never what your files contain. **0 bytes** of your file are uploaded; the only requests are anonymous counters (a page view, a file opened). Check it yourself in your browser’s developer tools (Network tab). Anatomy of an X9 file ## Every check, as paper and as data. An X9 file carries each check twice: the MICR line in an 80-character Check Detail record (type 25), and the front and back images in Image View records (50 and 52). The viewer lines the two up, field by field. **Record 04** Check 1001 and its Check Detail record, from the sample file 80 characters · 15 fields - **Auxiliary On-Us** check number 3–17 - **Payor bank routing** and check digit 19–27 - **On-Us** account number 28–47 - **Item amount** in cents 48–57 File structure ## Cash letters, bundles, checks and images. X9.37 files nest like the paper they replaced. Each control record states the counts and totals of what it closes; the viewer adds them up again from the items themselves and shows you any that disagree. 1. Type 01 **File Header** Origin, destination, test or production 2. Type 10 **Cash Letter Header** One business day’s deposit 3. Type 20 **Bundle Header** A batch of items 4. Type 25 **Check Detail** The MICR line and amount per check 5. Type 26 **Check Addendum A** Bank of first deposit endorsement 6. Type 50 **Image View Detail** Front, then back per side 7. Type 52 **Image View Data** The TIFF image bytes per side 8. Type 70 **Bundle Control** Items, amount and images in the bundle 9. Type 90 **Cash Letter Control** Bundles, items, amount, images 10. Type 99 **File Control** Cash letters, records, items, amount ### Totals that must add up **Bundle Control (70)**: items, amount, MICR-valid amount and images in its bundle **Cash Letter Control (90)**: bundles, items, amount and images in its cash letter **File Control (99)**: cash letters, records, items and the file total amount **Check Detail (25)**: addendum count, and the routing number’s ABA check digit ### Read as it was written EBCDIC or ASCII, with 4-byte length prefixes, IBM record descriptor words or none at all — the framing is detected from the bytes, not the file name. Image data is never decoded as text. What you get ## Everything in the file, nothing made up. The X9 Viewer replaces X9 Navigator, and every figure on screen now comes from your file: decoded records, real check images and totals recomputed from the items. No. 01 ### Check image viewing Front and back of every item, decoded from the TIFF Group 4 data in the file. Zoom, rotate, invert, compare sides and save any image as a PNG. No. 02 ### Every record, decoded All record types of X9.100-187 and DSTU X9.37-2003, field by field: MICR line, routing check digit, amounts, dates and code meanings, in EBCDIC or ASCII. No. 03 ### Checked to the standard Bundle, cash letter and file controls recomputed from the items — counts, amounts and image counts — with the value expected when one is off. No. 04 ### Exports Items as CSV or JSON, and every image as a PNG in one ZIP with a manifest. Account numbers stay masked unless you turn masking off. Record types ## Twenty-five record types, all decoded. Each one is read with its own layout for the file’s standard level: X9.100-187 (2008 to 2016 editions) or DSTU X9.37-2003. Unknown types are kept and flagged, never dropped. - Type 01 **File Header** Opens the file: standard level, test or production, immediate destination and origin, and creation date and time. - Type 10 **Cash Letter Header** Opens a cash letter: the bundles sent together for one business day, with collection type, routing numbers and cash letter ID. - Type 20 **Bundle Header** Opens a bundle of items within a cash letter, with its business date, ID and sequence number. - Type 25 **Check Detail** One check presented for payment: MICR line data (routing number, On-Us, Auxiliary On-Us), amount and item sequence number. - Type 26 **Check Addendum A** Bank of first deposit (BOFD) endorsement: return location, BOFD business date, deposit account and payee. - Type 27 **Check Addendum B** Image archive reference for the check: microfilm sequence number and a variable-length image reference key. - Type 28 **Check Addendum C** A subsequent endorsement, one record per endorsing bank after the BOFD. - Type 31 **Return** One returned item: payor bank routing number, On-Us, amount, return reason and forward bundle date. - Type 32 **Return Addendum A** BOFD endorsement on the returned item (same layout as type 26). - Type 33 **Return Addendum B** Payor bank details for the return: bank name, item sequence number, business date and payor account name. - Type 34 **Return Addendum C** Image archive reference for the returned item (same layout as type 27). - Type 35 **Return Addendum D** An endorsing bank on the returned item (same layout as type 28). - Type 40 **Account Totals** Item count and amount for a key account or account range. - Type 41 **Non-Hit Totals** Item count and amount for items that matched no key account. - Type 50 **Image View Detail** Describes one image view of the item (front or back): format, compression, creator and digital-signature settings. Its Image View Data record follows. - Type 52 **Image View Data** Carries the image bytes of the preceding Image View Detail, with the image reference key and optional digital signature. - Type 54 **Image View Analysis** Image quality and usability test results for the preceding image view. - Type 61 **Credit Reconciliation** A credit for the deposit, within a cash letter or bundle. - Type 62 **Credit** A credit for the deposit, with a 14-digit amount. - Type 68 **User Record** Data defined by the record owner: the general format, or format 001 for a payee endorsement. - Type 70 **Bundle Control** Closes a bundle with its item count, total amount, MICR-valid amount and image count. - Type 75 **Box Summary** Totals for a box of bundles: destination, bundle count and box total. - Type 85 **Routing Summary** Item count and amount totals for one routing number within the cash letter. - Type 90 **Cash Letter Control** Closes a cash letter with its bundle, item and image counts, total amount, ECE institution name and settlement date. - Type 99 **File Control** Closes the file with its cash letter, record and item counts and the file total amount. Related tools ## More free tools for payment files. The same private, in-browser approach for the other formats that land on an operations desk. - ACH · NACHA files ### NACHA Viewer Decode every record field by field, check control totals, hashes and routing check digits, and build reversal files. .ach · .txt [Open the NACHA Viewer](https://nacha-navigator.com/) - ACH · Reversals ### ACH Reversal Reverse a whole NACHA file or the entries you choose: transaction codes flipped, REVERSAL as the entry description and the control totals recalculated. .ach · .txt [Reverse an ACH file](https://nacha-navigator.com/ach-reversal) - BAI2 · Balance reporting ### BAI2 Viewer Turn BAI2 bank reports into readable account summaries and transaction detail, with every type code explained. .bai · .bai2 · .txt [Open BAI2 Viewer](https://nacha-navigator.com/bai2-viewer) - Build files · REST API ### NACHA Generator Build a valid NACHA file with a visual form, or from JSON with the REST API. Control totals, entry hash and block padding are done for you. [Read the API docs](https://nacha-navigator.com/nacha-generator/api) [Open the generator](https://nacha-navigator.com/nacha-generator) ## Limits - It reads X9 files. It doesn’t create or edit them, or send them to a bank or the Federal Reserve. - MICR data comes from the records, not the images: there is no OCR, so a check image that disagrees with its record isn’t flagged. - Image quality and usability results are shown as the file records them (type 54). The viewer runs no image tests of its own. - Digital signatures in image records are shown, not verified. JPEG 2000 images can’t be displayed in the browser. - It checks the record layouts and totals of the X9 standard, not a bank’s or the Federal Reserve’s companion document. ## Reference - [X9.37 file format](https://nacha-navigator.com/x9-file-format) Every record type and field, by edition. - [Sample files](https://nacha-navigator.com/sample-files) Example NACHA, BAI2 and X9 files to download and open. Last updated October 30, 2026 --- URL: https://nacha-navigator.com/bai2-viewer # Read any BAI2 file, account by account. Free BAI2 file viewer Upload a BAI2 file to analyze its structure and contents: each account’s balances and transactions, every type code explained and every control total checked against the BAI2 specification. It reads BAI version 2 files, and version 3 (BTRS) files with BAI2 code meanings. All processing happens locally in your browser - no data is sent to any server. - Balances & transactions per account - Every type code explained - Control totals checked ## 100% in-browser. Your file never leaves this device. ### Parsed on your device JavaScript on this page reads the file. Nothing is uploaded, stored or transmitted. ### No account, no cost Every tool is free to use. No sign-up, no paywall, ever. ### Open about usage Our [public analytics](https://nacha-navigator.com/analytics) show exactly what we count — never what your files contain. **0 bytes** of your file are uploaded; the only requests are anonymous counters (a page view, a file opened). Check it yourself in your browser’s developer tools (Network tab). Anatomy of a BAI2 file ## Commas, codes and continuations, decoded. BAI2 is comma-delimited: each line starts with a two-digit record code, commas separate the fields and a slash ends the record. Fields have numbers, not positions — the viewer names, decodes and checks every one. Lines 07–09 · one transaction ### Transaction Detail, field by field 1. 1 **Record code** `16` Transaction Detail 2. 2 **Type code** `115` Lockbox Deposit, a credit 3. 3 **Amount** `4512575` 45,125.75 USD — two implied decimals 4. 4 **Funds type** `S` Distributed availability: three amounts follow 5. 5 **Available now** `2500000` 25,000.00 6. 6 **In one day** `1500000` 15,000.00 7. 7 **In two days or more** `512575` 5,125.75 8. 8 **Bank reference** `LBX204417` On the first 88 line 9. 9 **Customer reference** `BATCH 0007` Spaces are part of the value 10. 10 **Text** `LOCKBOX 4417 DEPOSIT, 23 CHECKS …` Runs to the end of the record, commas included, across both 88 lines A short BAI2 primer ## Eight record types, one nested report. BAI2 is how banks report balances and transactions to their corporate customers, typically a final report for the previous day and interim reports during the day. Every file nests the same way. 1. 01 **File Header** Who sent the file and when, the file ID, and version 2. 2. 02 **Group Header** One per originating bank and as-of date: status, as-of date and time, currency. 3. 03 **Account Identifier** Account number, currency, balances (status codes) and summary totals. 4. 16 **Transaction Detail** One per transaction: type code, amount, availability, references, text. 5. 88 **Continuation** Carries the rest of the record above it onto another line. 6. 49 **Account Trailer** Closes the account: control total and number of records. 7. 98 **Group Trailer** Closes the group: control total, accounts and records. 8. 99 **File Trailer** Closes the file: control total, groups and records. - ### Amounts have no decimal point The currency implies the decimals: `150000` is 1,500.00 in USD, 150,000 in JPY and 150.000 in KWD. - ### Type codes say what an amount is `001–099` balances, `100–399` credits, `400–699` debits, `900–999` bank-defined. - ### Funds types add fields `S` adds three availability amounts, `V` a value date and time, `D` a list of days and amounts. - ### Trailers prove the totals Each 49, 98 and 99 carries a control total and record count. The viewer recomputes every one and shows the difference. What it shows ## From raw lines to a readable statement. Every view shares one selection: pick a transaction in the statement and the tree, its raw line and its fields follow. 1. No. 01 ### Statement Balances from every status code, summary totals, and each transaction with its type, credit or debit, amount, references and full text — account by account. 2. No. 02 ### Structure The file as a tree: groups, accounts, transactions, trailers and the 88 lines under each record, with a field-by-field record view. 3. No. 03 ### Raw data Every line color-coded field by field. Hover or select a field for its number, decoded value and what the specification says. 4. No. 04 ### Validation Every account, group and file control total and record count recomputed, plus field formats, type codes and record order — with the line to fix. Related tools ## More free tools for payment files. The same private, in-browser approach for the other formats that land on an operations desk. - ACH · NACHA files ### NACHA Viewer Decode every record field by field, check control totals, hashes and routing check digits, and build reversal files. .ach · .txt [Open the NACHA Viewer](https://nacha-navigator.com/) - ACH · Reversals ### ACH Reversal Reverse a whole NACHA file or the entries you choose: transaction codes flipped, REVERSAL as the entry description and the control totals recalculated. .ach · .txt [Reverse an ACH file](https://nacha-navigator.com/ach-reversal) - New X9.37 · Image cash letter ### X9 Viewer Open X9.37 check image files in your browser: every item’s front and back images, its MICR line and the records behind it. .x9 · .x937 · .icl [Open X9 Viewer](https://nacha-navigator.com/x9-viewer) - Build files · REST API ### NACHA Generator Build a valid NACHA file with a visual form, or from JSON with the REST API. Control totals, entry hash and block padding are done for you. [Read the API docs](https://nacha-navigator.com/nacha-generator/api) [Open the generator](https://nacha-navigator.com/nacha-generator) ## Limits - It reads the BAI2 files your bank sends. It doesn’t connect to your bank or fetch reports for you. - It doesn’t reconcile transactions against your books. - Type codes 900–999 are defined by each bank. The viewer says whether one is a status, credit or debit code, not what your bank means by it. - Version 3 (BTRS) files are read with BAI2 meanings, which BTRS changed for a few codes. BTRS-only records (89 and 90) are shown as raw text. - Exports are CSV and JSON. It doesn’t convert reports to other formats, such as camt.053. ## Reference - [BAI2 type codes](https://nacha-navigator.com/bai2-type-codes) Every code with its level and direction. - [BAI2 file format](https://nacha-navigator.com/bai2-file-format) Records, fields, continuations and control totals. - [Sample files](https://nacha-navigator.com/sample-files) Example NACHA, BAI2 and X9 files to download and open. Last updated October 30, 2026 --- URL: https://nacha-navigator.com/nacha-generator # Build a valid NACHA file in your browser. Free NACHA file generator Fill in batches and entries, and the builder writes a NACHA file for PPD, CCD, CTX, WEB, TEL, ARC, BOC or POP payments: every 94-character record, with the totals, entry hash and block padding worked out and the file checked against the NACHA rules as you type. It all runs in your browser; the REST API is optional. - Control totals & entry hash - Next-banking-day dates - Live record preview ## 100% in-browser. What you type never leaves this device. ### Generated on your device JavaScript on this page writes the file. Nothing you enter is uploaded, stored or transmitted. ### No account, no key The builder and the REST API are free. No sign-up, no API key. ### Open about usage Our [public analytics](https://nacha-navigator.com/analytics) count files generated — never what they contain. **0 bytes** of your entries are uploaded; the only requests are anonymous counters (a page view, a file generated). Check it yourself in your browser’s developer tools (Network tab). Calculated for you ## The control record, worked out. Every batch closes with a control record that counts, totals and hashes the entries above it. One wrong digit and the bank rejects the file. The builder computes it from your entries, and shows its work. **Line 07** Batch control · from the Payroll template 94 characters · 11 fields **Entry/addenda count** 000004 4 entries + 0 addenda records **Entry hash** 0042408482 02100002 + 02600959 + 12100024 + 25607497 **Total credits** 000000819210 $8,192.10 across four credits What it handles ## The fiddly parts of NACHA, handled. NACHA files are unforgiving: fixed positions, exact padding, totals that have to agree to the cent. You enter the payments; the builder does the bookkeeping. - 01 ### Fixed-width field formatting Every value padded, justified and uppercased into its exact positions. - 02 ### Batch and file header/footer generation Headers from your settings, control records from your entries. - 03 ### Control total calculations Debit and credit totals for every batch and for the file. - 04 ### Hash sum calculations Routing prefixes summed into the entry hash, last ten digits kept. - 05 ### Record count tracking Entry/addenda counts, batch count and block count, always in step. - 06 ### Block padding Records of nines fill the last block to a multiple of ten. Why use it ## Right the first time, before your bank looks. Spreadsheets and hand-edited files fail at the bank for small reasons: a stale effective date, a total that’s a cent off, a missing block of nines. The builder catches them while you work. No. 01 ### Validation Comprehensive validation as you type: required fields, formats, routing check digits, effective dates and totals — the same rules the API applies. No. 02 ### Automatic calculations All control totals, hash sums and record counts are calculated automatically, with batch and trace numbers assigned for you. No. 03 ### Downloadable files Download ready-to-use NACHA files (.ach or .txt, LF or CRLF) that can be submitted to financial institutions. No. 04 ### A free REST API The same engine over HTTP. POST the JSON the builder exports to /api/v1/nacha/generate — no API key, no account. NACHA File Generator API ## Generate compliant NACHA files from your own code. Prefer to automate? Send the same JSON the builder exports to the REST API and get the file back. The builder never needs it. - No API key. An `X-API-Key` header from older clients is accepted and ignored. - `/generate` returns the file; `/validate` says what’s wrong. - Requests are processed in memory, never stored or logged. [Read the API docs](https://nacha-navigator.com/nacha-generator/api) Quick start · POST /api/v1/nacha/generate ``` POST /api/v1/nacha/generate HTTP/1.1 Host: nacha-navigator.com Content-Type: application/json { "file_header": { "immediate_destination": "123456780", "immediate_origin": "1234567890" }, "batches": [ { "batch_header": { "service_class_code": "200", "company_name": "COMPANY ABC", "company_id": "1234567890", "standard_entry_class": "PPD", "company_entry_description": "PAYROLL", "originating_dfi_id": "123456780" }, "entries": [ { "transaction_code": "22", "receiving_dfi_id": "021000021", "dfi_account_number": "123456789", "amount": "100000", "individual_name": "JOHN DOE" } ] } ] } ``` The response is the file itself: `text/plain`, saved as `nacha_file.txt`. Related tools ## More free tools for payment files. The same private, in-browser approach for the other formats that land on an operations desk. - ACH · NACHA files ### NACHA Viewer Decode every record field by field, check control totals, hashes and routing check digits, and build reversal files. .ach · .txt [Open the NACHA Viewer](https://nacha-navigator.com/) - ACH · Reversals ### ACH Reversal Reverse a whole NACHA file or the entries you choose: transaction codes flipped, REVERSAL as the entry description and the control totals recalculated. .ach · .txt [Reverse an ACH file](https://nacha-navigator.com/ach-reversal) - New X9.37 · Image cash letter ### X9 Viewer Open X9.37 check image files in your browser: every item’s front and back images, its MICR line and the records behind it. .x9 · .x937 · .icl [Open X9 Viewer](https://nacha-navigator.com/x9-viewer) - BAI2 · Balance reporting ### BAI2 Viewer Turn BAI2 bank reports into readable account summaries and transaction detail, with every type code explained. .bai · .bai2 · .txt [Open BAI2 Viewer](https://nacha-navigator.com/bai2-viewer) ## Limits - It writes the file; it doesn’t send it. You submit the file through your bank’s own channel. - Routing numbers are checked by their check digit only, not whether an account exists or is open. A prenote, which the builder can write, lets the receiver’s bank check an account before money moves. - It writes PPD, CCD, CTX, WEB, TEL, ARC, BOC and POP batches with checking and savings credits, debits and prenotes, and 05 addenda. IAT, loan, general ledger and return entries aren’t supported. - It doesn’t know your bank’s (ODFI’s) own requirements, such as cutoff times, file names or a balanced file with an offset entry. - The REST API takes JSON only, up to 128 KB a request (about 500 entries) and about 30 requests a minute per IP address. It sends no CORS headers, so call it from a server or a script. ## Reference - [API documentation](https://nacha-navigator.com/nacha-generator/api) Generate and validate NACHA files from JSON over HTTP. - [MCP server](https://nacha-navigator.com/mcp-server) The generator and the references, for AI assistants. - [NACHA file format](https://nacha-navigator.com/nacha-file-format) Every record type and field, position by position. - [ACH transaction codes](https://nacha-navigator.com/ach-transaction-codes) What each two-digit transaction code means. Last updated October 30, 2026 --- URL: https://nacha-navigator.com/nacha-generator/api # NACHA File Generator API REST API documentation Generate and validate NACHA ACH files over HTTP. Send JSON describing your batches and entries; get back a file that’s ready for your bank. Free, no API key. Base URL `https://nacha-navigator.com` · JSON in, NACHA file out · Last updated October 30, 2026 ## Overview The NACHA File Generator API generates compliant NACHA formatted files for ACH transactions. Send a JSON description of the file (a file header, batches and their entries) and get back the file, ready for your bank. The API handles the complexity of NACHA file formatting, including: - Fixed-width field formatting - Batch and file header/footer generation - Control total calculations - Hash sum calculations - Record count tracking - Block padding Note NACHA files must adhere to strict formatting rules to be accepted by financial institutions. This API checks your data against those rules before it writes a file, and tells you exactly what to fix when something doesn’t pass. **Endpoints** | Endpoint | What it does | Success response | | --- | --- | --- | | POST /api/v1/nacha/generate | Validates the request and writes the file | The file: text/plain, attachment nacha_file.txt | | POST /api/v1/nacha/validate | Runs the same checks without writing a file | JSON: {"message": …, "valid": true} | Prefer a form? The [NACHA Generator](https://nacha-navigator.com/nacha-generator) builds the same files in your browser and exports this exact JSON, so a file you design there can be produced by your systems later. The builder never calls the API: what you type there stays on your device. **Privacy.** Requests are processed in memory. Request bodies and generated files are never stored or logged; the only records kept are an anonymous count of files generated, shown on the [analytics](https://nacha-navigator.com/analytics) page, and, when a request fails, an error log line with its method and path ([privacy policy](https://nacha-navigator.com/privacy#error-logs)). **Machine-readable.** Both endpoints are described in an [OpenAPI 3.1 document](https://nacha-navigator.com/openapi.json) at `/openapi.json`, for client generators and API tools. AI apps can run the same checks through the [NACHA Navigator MCP server](https://nacha-navigator.com/mcp-server): its `validate_nacha_file_request` and `generate_nacha_file` tools take this same JSON. ## Authentication None. The API used to require an API key; keys have been retired and the API is free to use. Clients that still send a key keep working: it is accepted and ignored. **How an old API key is treated** | Method | Example | Now | | --- | --- | --- | | HTTP header | X-API-Key: your_api_key_here | Accepted and ignored | | Query parameter | /api/v1/nacha/generate?api_key=your_api_key_here | Accepted and ignored. Avoid it: query strings end up in logs. | The key administration endpoints (`GET` and `POST /admin/api-keys`, `POST /admin/api-keys/revoke`) are retired and answer `404`. ## Limits **Request limits** | Limit | Value | When you exceed it | | --- | --- | --- | | Rate | About 30 requests a minute per IP address | 429 with Retry-After: 60 | | Body size | 128 KB of JSON: about 500 entries as the builder exports them. Send a larger payment run as several files. | 413 | | Content type | application/json (charset allowed) | 415 | | Browsers | No CORS headers: call the API from a server or a script, not from a web page on another site | The browser blocks the response | ## Endpoints Both endpoints take the same request body and run the same checks, in this order: 1. The body must be JSON (`415` otherwise) and parse (`400` otherwise). 2. **Structure:** every required key present, no unknown keys, every value a string of the right shape (`400 Invalid input data`). 3. **NACHA rules:** required values filled in, codes from their lists, dates real, numbering and totals that fit their fields (`400 NACHA validation failed`). 4. **Warnings** that don’t block the file, such as a routing number that fails its check digit: reported by `/validate`. A `200` doesn’t mean a bank will accept the file: see [Warnings](https://nacha-navigator.com/nacha-generator/api#warnings). ### Generate a NACHA file POST `/api/v1/nacha/generate` Send the request body (see [Request format](https://nacha-navigator.com/nacha-generator/api#request-format)) with `Content-Type: application/json`. A valid request returns the file itself: - Status `200`, `Content-Type: text/plain; charset=utf-8`, `Content-Disposition: attachment; filename=nacha_file.txt`, `Cache-Control: no-store`. - 94-character records in uppercase ASCII, each ending with a line feed (LF), the last one included. - Padded with records of nines to a multiple of ten records. A request that fails a check returns JSON instead. Structure errors are keyed by field, with list positions as strings: 400 · structure error (formatted) ```json { "details": { "batches": { "0": { "entries": { "0": { "amount": [ "String does not match expected pattern." ] } } } }, "file_header": { "immediate_origin": [ "Missing data for required field." ] } }, "error": "Invalid input data" } ``` Rule errors are a list of messages, each naming its batch, entry and field: 400 · NACHA rule error (formatted) ```json { "details": [ "Batch 1: Missing required field: company_name" ], "error": "NACHA validation failed" } ``` ### Validate NACHA data POST `/api/v1/nacha/validate` Checks a request without generating a file. Use it to test data before a payment run. The answer is JSON with a `valid` flag; errors carry the same `details` as `/generate`, with `"valid": false` and the structure error named `Invalid input data structure`. 200 · valid ```json { "message": "NACHA data validation successful", "valid": true } ``` 200 · valid, with a warning ```json { "message": "NACHA data validation successful", "valid": true, "warnings": [ { "code": "aba-check-digit", "message": "Batch 1: Entry 1: receiving_dfi_id 021000022 fails the ABA routing number check digit test", "path": "batches.0.entries.0.receiving_dfi_id", "severity": "warning" } ] } ``` `warnings` appears only when there is something to report. Each warning has a stable `code` (listed under [Warnings](https://nacha-navigator.com/nacha-generator/api#warnings)), a `severity` (`warning` or `info`), the field’s `path` in the request and a `message`. ## Request format A JSON object with a `file_header` and at least one batch. Each batch has a `batch_header` and at least one entry; an entry may carry `addenda` records. - **Every value is a string**, amounts and codes included: `"amount": "100000"` is $1,000.00 (amounts are in cents). - Required keys must be present. Optional keys can be left out: their defaults apply. - Unknown keys are rejected with `Unknown field.`, so a misspelled optional field never goes unnoticed. - Text is printable ASCII: letters, digits, spaces and punctuation. It is written in uppercase. Request body: the shape ```json { "file_header": { "immediate_destination": "123456780", "immediate_origin": "1234567890" }, "batches": [ { "batch_header": { "service_class_code": "220", "company_name": "COMPANY ABC", "company_id": "1234567890", "standard_entry_class": "PPD", "company_entry_description": "PAYROLL", "originating_dfi_id": "123456780" }, "entries": [ { "transaction_code": "22", "receiving_dfi_id": "021000021", "dfi_account_number": "123456789", "amount": "100000", "individual_name": "JOHN DOE", "addenda": [ { "payment_related_info": "PAY PERIOD 09/01-09/15" } ] } ] } ] } ``` ### File header The file header record contains information about the origin and destination of the file. **File header fields** | Field | Required | Description | Format and default | Positions | | --- | --- | --- | --- | --- | | `immediate_destination` Immediate destination | Yes | Routing number of the ACH Operator or receiving point | 9 digits, can have a leading space | 4–13 | | `immediate_origin` Immediate origin | Yes | Routing number or other identifier of the originating institution | 9 digits, can have a leading space; or a 10-character identifier agreed with your ODFI | 14–23 | | `file_creation_date` File creation date | No | Date the file was created | YYMMDD format (defaults to current date, America/New_York) | 24–29 | | `file_creation_time` File creation time | No | Time the file was created | HHMM format, 24-hour (defaults to current time, America/New_York) | 30–33 | | `file_id_modifier` File ID modifier | No | Distinguishes between multiple files created on same date | A-Z, 0-9 (defaults to 'A') | 34 | | `record_size` Record size | No | Size of each record | 094 (default; no other value is valid) | 35–37 | | `blocking_factor` Blocking factor | No | Number of records in a block | 10 (default; no other value is valid) | 38–39 | | `format_code` Format code | No | Format code | 1 (default) | 40 | | `immediate_destination_name` Immediate destination name | No | Name of the destination institution | Up to 23 characters | 41–63 | | `immediate_origin_name` Immediate origin name | No | Name of the originating institution | Up to 23 characters | 64–86 | | `reference_code` Reference code | No | Reference code for the file | Up to 8 characters | 87–94 | | `priority_code` Priority code | No | Priority of the file | 2 digits (defaults to '01', the only value in use) | 2–3 | ### Batch header The batch header contains information about a group of related entries: who sends them, what they are and when they settle. The batch control record that closes each batch is calculated from it and from the entries. **Batch header fields** | Field | Required | Description | Format and default | Positions | | --- | --- | --- | --- | --- | | `service_class_code` Service class code | Yes | Code indicating the type of entries in the batch | 200 (mixed debits and credits), 220 (credits only) or 225 (debits only) | 2–4 | | `company_name` Company name | Yes | Name of the company/organization | Up to 16 characters | 5–20 | | `company_discretionary_data` Company discretionary data | No | For discretionary use | Up to 20 characters | 21–40 | | `company_id` Company ID | Yes | Company identification number | Up to 10 characters | 41–50 | | `standard_entry_class` Standard entry class (SEC) | Yes | Code identifying the type of entries | PPD, CCD, CTX, WEB, TEL, ARC, BOC or POP | 51–53 | | `company_entry_description` Company entry description | Yes | Description of the entries | Up to 10 characters | 54–63 | | `company_descriptive_date` Company descriptive date | No | Descriptive date for the company | YYMMDD format (defaults to current date) | 64–69 | | `effective_entry_date` Effective entry date | No | Date the entries should be settled | YYMMDD format (defaults to the next banking day: weekdays except Federal Reserve holidays) | 70–75 | | `settlement_date` Settlement date | No | Settlement date filled by ACH Operator | 3 characters (leave it out; defaults to blanks) | 76–78 | | `originator_status_code` Originator status code | No | Code identifying the status of the originator | 1 (default) or 2 | 79 | | `originating_dfi_id` Originating DFI ID | Yes | Routing number of the originating institution | 9 digits (the first 8 are written; the 9th is the check digit) | 80–87 | | `batch_number` Batch number | No | Batch sequence number | Up to 7 digits, ascending through the file (defaults to the previous batch number plus 1, starting at 1) | 88–94 | ### Entry detail Each entry detail record contains information about an individual transaction. **Entry detail fields** | Field | Required | Description | Format and default | Positions | | --- | --- | --- | --- | --- | | `transaction_code` Transaction code | Yes | Code identifying the type of transaction | 22 (checking credit), 23 (checking credit prenote), 27 (checking debit), 28 (checking debit prenote), 32 (savings credit), 33 (savings credit prenote), 37 (savings debit) or 38 (savings debit prenote) | 2–3 | | `receiving_dfi_id` Receiving DFI ID | Yes | Routing number of the receiving institution (including check digit) | 9 digits (complete routing number) | 4–12 | | `dfi_account_number` Account number | Yes | Account number at the receiving institution | Up to 17 characters | 13–29 | | `amount` Amount (cents) | Yes | Amount of the transaction in cents | Up to 10 digits (e.g., 100000 = $1,000.00); 0 for prenotes | 30–39 | | `individual_id` Individual ID | No | Identification number for the individual | Up to 15 characters (ARC/BOC: the check serial number; POP: check serial number in characters 1-9, terminal city 10-13, terminal state 14-15) | 40–54 | | `individual_name` Individual name | Yes | Name of the individual | Up to 22 characters (CTX: up to 16, written at positions 59-74) | 55–76 | | `discretionary_data` Discretionary data | No | For discretionary use | Up to 2 characters (WEB/TEL: the optional payment type code, usually R or S) | 77–78 | | `trace_number` Trace number | No | Unique identifier for the transaction | Up to 15 digits, unique within the file (defaults to the ODFI routing prefix plus a 7-digit sequence number) | 80–94 | `addenda` is an optional array of addenda records (below). Positions are those of the PPD and CCD layouts; CTX, POP and ARC/BOC differences are noted in the formats. ### Addenda records Addenda records contain additional information related to an entry detail record, such as an invoice number. PPD, CCD and WEB entries carry at most one; CTX entries up to 9,999; TEL, ARC, BOC and POP none. **Addenda fields** | Field | Required | Description | Format and default | Positions | | --- | --- | --- | --- | --- | | `addenda_type_code` Addenda type code | No | Type of addenda record | 05 (default) | 2–3 | | `payment_related_info` Payment related information | Yes | Additional information about the payment | Up to 80 characters | 4–83 | | `addenda_sequence_number` Addenda sequence number | No | Sequence number for multiple addenda records | Up to 4 digits (defaults to the record's position: 1, 2, 3 and so on) | 84–87 | ## Errors ### Status codes **Status codes** | Status | When | Body | | --- | --- | --- | | 200 | Success | generate: the file (text/plain). validate: {"message", "valid": true} plus "warnings" when there are any. | | 400 | The body is not valid JSON | {"error": "Bad request", "message": "Failed to decode JSON object"} | | 400 | The JSON has the wrong shape: a missing, unknown or mistyped field | {"details": {…}, "error": "Invalid input data"} (validate: "Invalid input data structure") | | 400 | The fields break a NACHA rule | {"details": \["…"\], "error": "NACHA validation failed"} | | 404 | Unknown path under /api, or a retired /admin/api-keys endpoint | {"error": "Not found", …} | | 405 | Any method other than POST | {"error": "Method not allowed", "message": "The method is not allowed for the requested URL."} with Allow: POST | | 413 | The body is larger than 128 KB (about 500 entries) | {"error": "Payload too large", "message": "The request body must be 128 KB or less: about 500 entries. Send a larger payment run as several files."} | | 415 | Content-Type is not application/json | {"error": "Request must be JSON"} | | 429 | More than about 30 requests a minute from one address | {"error": "Rate limit exceeded"} with Retry-After: 60 | | 500 | An unexpected failure on our side (please report it) | {"error": "Internal server error"} | JSON error bodies have their keys in alphabetical order. On `/validate`, the `400`, `415` and `500` bodies also carry `"valid": false`. ### Structure errors Under `details`, each field with a problem lists its messages. These are the messages, word for word: **Structure error messages** | Message | Cause | | --- | --- | | Missing data for required field. | A required key is absent. | | Unknown field. | A key the API doesn’t know (check the spelling: names are snake_case). | | Field may not be null. | A value is null. Leave optional keys out instead. | | Not a valid string. | A value is a number or boolean. Every value is a string, amounts included ("100000"). | | Not a valid list. | "batches", "entries" or "addenda" is not an array. | | Invalid input type. | Something that should be an object isn’t (reported under "\_schema"). | | String does not match expected pattern. | A value doesn’t have the required digits, e.g. a routing number that isn’t 9 digits or a date that isn’t YYMMDD. | | Longer than maximum length 16. | A value is longer than its field (the number is the limit). | | Length must be 1. | A value must have exactly this many characters. | | Shorter than minimum length 1. | "batches" or "entries" is empty. | | Must be one of: 200, 220, 225. | A code outside its list (service class, SEC code, transaction code…). | | Must contain only printable ASCII characters. | Text with accented letters, emoji, tabs or line breaks. Records carry printable ASCII only. | | Duplicate trace number found: 123456780000001 | Two entries share a trace number (compared as 15 digits, so "1" equals "000000000000001"). | ### NACHA rule errors Each message is prefixed with where it applies: `Batch 1: `, `Batch 1: Entry 2: ` or `Batch 1: Entry 2, Addenda 1: ` (counted from 1). `` stands for the field’s name. **NACHA rule messages** | Message | Meaning | | --- | --- | | Missing required field: \ | A required value is empty. | | \: Value must contain only digits | Digits only. | | \: Date must be in YYMMDD format | Six digits, YYMMDD. | | \: Time must be in HHMM format | Four digits, HHMM. | | \ must be 2 digits | Exactly this many digits (priority_code, record_size, blocking_factor). | | \ must be at most 23 characters | Longer than the field. | | \ must be at most 7 digits | More digits than the field holds. | | \ must be 9 digits (including check digit) | Routing numbers are all nine digits, including the check digit. | | file_id_modifier must be 1 character | One character. | | format_code must be '1' | Always 1. | | service_class_code must be '200', '220', or '225' | 200 mixed, 220 credits only, 225 debits only. | | standard_entry_class must be one of: PPD, CCD, CTX, WEB, TEL, ARC, BOC, POP | The SEC codes the API writes. | | originator_status_code must be '1' or '2' | 1 for almost every originator; 2 for federal government agencies. | | transaction_code must be one of: 22, 23, 27, 28, 32, 33, 37, 38 | Checking 22/23/27/28, savings 32/33/37/38. | | addenda_type_code must be '05' for standard addenda records | Only 05 addenda are written. | Rules added in this version keep the same style. Each closes a gap that let the original API write a file a bank would reject: **Added NACHA rule messages** | Message | Meaning | | --- | --- | | record_size must be '094' | The record size is fixed. | | blocking_factor must be '10' | The blocking factor is fixed. | | file_id_modifier must be a letter A-Z or a digit 0-9 | Lowercase is accepted and written in uppercase. | | \ must be a valid calendar date (YYMMDD) | A date that doesn’t exist, like 260231. | | \ must be a valid time of day (HHMM, 0000-2359) | A time that doesn’t exist, like 2460. | | batch_number must be greater than the previous batch's batch number (0000003) | Batch numbers must ascend through the file. | | \ must not be blank | All spaces where a value is required. | | \ must not be blank for PPD entries | The receiver name is required for PPD, CCD, CTX, WEB and TEL entries. | | individual_name must be at most 16 characters for CTX entries (Receiving Company Name/ID Number, positions 59-74) | CTX entries hold a shorter name. | | individual_id must contain the check serial number for ARC entries | ARC and BOC entries carry the converted check’s serial number. | | individual_id must contain the check serial number (characters 1-9), terminal city (10-13) and terminal state (14-15) for POP entries | POP entries pack three values into individual_id. | | addenda must contain at most 9999 records | The addenda sequence number has four digits. | | batch_number cannot be assigned automatically after batch number 9999999 | No room left to number batches automatically. | | trace_number cannot be assigned automatically: the 7-digit trace sequence is exhausted | No room left to number entries automatically. | | addenda_sequence_number cannot be assigned automatically after 9999 | No room left to number addenda automatically. | | entry/addenda count 1000000 exceeds the 6-digit Batch Control field (999999) | Too many records in one batch for its control record. | | total debit amount exceeds the 12-digit Batch Control field | A batch total beyond $9,999,999,999.99. | | batch count 1000000 exceeds the 6-digit File Control field (999999) | Too many batches for the file control record. | | entry/addenda count 100000000 exceeds the 8-digit File Control field (99999999) | Too many records for the file control record. | | block count 1000000 exceeds the 6-digit File Control field (999999) | Too many blocks for the file control record. | | total credit amount exceeds the 12-digit File Control field | A file total beyond $9,999,999,999.99. | ### Warnings Warnings never block a file: `/generate` writes it anyway, and `/validate` lists them so you can decide. Many describe a file that banks and ACH operators reject (a routing number that fails its check digit, a prenote with an amount, too many addenda…), so fix them before you send it: the [builder](https://nacha-navigator.com/nacha-generator) treats those as errors, and the [NACHA Viewer](https://nacha-navigator.com/) fails such a file. **Warning codes** | Code | Severity | Meaning | | --- | --- | --- | | aba-check-digit | warning | A routing number’s ninth digit doesn’t match the ABA check-digit calculation. | | routing-prefix | warning | A routing number doesn’t start with an assigned routing symbol (00–12, 21–32, 61–72, 80). | | immediate-destination-format | warning | immediate_destination isn’t a 9-digit routing number. | | immediate-origin-format | warning | immediate_origin is neither a routing number nor a 10-character identifier. | | priority-code | warning | priority_code isn’t 01, the only value in use. | | scc-mismatch | warning | service_class_code 220 (credits only) or 225 (debits only) doesn’t match the batch’s entries. | | sec-transaction-code | warning | A credit in a debit-only SEC code (TEL, ARC, BOC, POP). | | prenote-amount | warning | A prenote (23, 28, 33, 38) with an amount other than 0. | | payment-type-code | info | A WEB or TEL debit whose discretionary_data is blank or not R or S. The payment type code has been optional since September 17, 2021. | | trace-prefix | warning | A supplied trace number doesn’t start with the ODFI’s first eight digits. | | trace-order | warning | Trace numbers don’t ascend within a batch. | | addenda-limit | warning | More addenda than the SEC code allows (one for PPD, CCD and WEB; none for TEL, ARC, BOC and POP). | | addenda-sequence | warning | Addenda sequence numbers aren’t 0001, 0002, 0003… in order. | | effective-date-past | warning | effective_entry_date is before today (Eastern Time). | | effective-date-today | info | effective_entry_date is today: it settles today only if your bank gets it before its same-day deadline. | | effective-date-non-banking-day | warning | effective_entry_date is a weekend or a Federal Reserve holiday. | | company-descriptive-date | warning | company_descriptive_date isn’t a real date. | | settlement-date | warning | settlement_date is filled in; the ACH operator sets it. | | lowercase | info | Text contains lowercase letters (written in uppercase). | ## Examples Copy-ready requests. The routing numbers pass the ABA check digit, so these validate without warnings. Replace them, and every name and account number, with your own. ### Basic example A file with one batch containing one entry: a $1,000.00 payroll credit. bash or zsh, curl 7.76 or later ``` curl https://nacha-navigator.com/api/v1/nacha/generate \ -H 'Content-Type: application/json' \ --fail-with-body -o nacha_file.txt \ --data-raw '{ "file_header": { "immediate_destination": "123456780", "immediate_origin": "1234567890", "immediate_destination_name": "DESTINATION BANK", "immediate_origin_name": "ORIGIN COMPANY" }, "batches": [ { "batch_header": { "service_class_code": "220", "company_name": "COMPANY ABC", "company_id": "1234567890", "standard_entry_class": "PPD", "company_entry_description": "PAYROLL", "originating_dfi_id": "123456780" }, "entries": [ { "transaction_code": "22", "receiving_dfi_id": "021000021", "dfi_account_number": "123456789", "amount": "100000", "individual_id": "EMP123", "individual_name": "JOHN DOE" } ] } ] }' ``` Response · nacha_file.txt ``` 101 12345678012345678902603021015A094101DESTINATION BANK ORIGIN COMPANY 5220COMPANY ABC 1234567890PPDPAYROLL 260302260303 1123456780000001 622021000021123456789 0000100000EMP123 JOHN DOE 0123456780000001 822000000100021000020000000000000000001000001234567890 123456780000001 9000001000001000000010002100002000000000000000000100000 9999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 9999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 9999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 9999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 9999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 ``` Generated for a request sent Monday, March 2, 2026 at 10:15 ET: dates default to the time of your request. ### Complex example Multiple batches and entries, including an addenda record: a payroll batch of two credits, and a corporate batch with one debit. bash or zsh, curl 7.76 or later ``` curl https://nacha-navigator.com/api/v1/nacha/generate \ -H 'Content-Type: application/json' \ --fail-with-body -o nacha_file.txt \ --data-raw '{ "file_header": { "immediate_destination": "123456780", "immediate_origin": "1234567890", "file_id_modifier": "A", "immediate_destination_name": "DESTINATION BANK", "immediate_origin_name": "ORIGIN COMPANY", "reference_code": "SEP2026" }, "batches": [ { "batch_header": { "service_class_code": "220", "company_name": "COMPANY ABC", "company_id": "1234567890", "standard_entry_class": "PPD", "company_entry_description": "PAYROLL", "originating_dfi_id": "123456780" }, "entries": [ { "transaction_code": "22", "receiving_dfi_id": "021000021", "dfi_account_number": "123456789", "amount": "100000", "individual_id": "EMP123", "individual_name": "JOHN DOE", "addenda": [ { "payment_related_info": "EMPLOYEE ID 12345, PAY PERIOD 09/01/2026-09/15/2026" } ] }, { "transaction_code": "32", "receiving_dfi_id": "011000138", "dfi_account_number": "987654321", "amount": "150000", "individual_id": "EMP456", "individual_name": "JANE SMITH" } ] }, { "batch_header": { "service_class_code": "225", "company_name": "COMPANY ABC", "company_id": "1234567890", "standard_entry_class": "CCD", "company_entry_description": "INVOICE", "originating_dfi_id": "123456780" }, "entries": [ { "transaction_code": "27", "receiving_dfi_id": "121000248", "dfi_account_number": "543210987", "amount": "250000", "individual_id": "INV-7731", "individual_name": "ACME SUPPLIES" } ] } ] }' ``` Response · nacha_file.txt ``` 101 12345678012345678902603021015A094101DESTINATION BANK ORIGIN COMPANY SEP2026 5220COMPANY ABC 1234567890PPDPAYROLL 260302260303 1123456780000001 622021000021123456789 0000100000EMP123 JOHN DOE 1123456780000001 705EMPLOYEE ID 12345, PAY PERIOD 09/01/2026-09/15/2026 00010000001 632011000138987654321 0000150000EMP456 JANE SMITH 0123456780000002 822000000300032000150000000000000000002500001234567890 123456780000001 5225COMPANY ABC 1234567890CCDINVOICE 260302260303 1123456780000002 627121000248543210987 0000250000INV-7731 ACME SUPPLIES 0123456780000003 822500000100121000240000002500000000000000001234567890 123456780000002 9000002000001000000040015300039000000250000000000250000 ``` Generated for a request sent Monday, March 2, 2026 at 10:15 ET: dates default to the time of your request. ### The raw request HTTP ``` POST /api/v1/nacha/generate HTTP/1.1 Host: nacha-navigator.com Content-Type: application/json { "file_header": { "immediate_destination": "123456780", "immediate_origin": "1234567890", "immediate_destination_name": "DESTINATION BANK", "immediate_origin_name": "ORIGIN COMPANY" }, "batches": [ { "batch_header": { "service_class_code": "220", "company_name": "COMPANY ABC", "company_id": "1234567890", "standard_entry_class": "PPD", "company_entry_description": "PAYROLL", "originating_dfi_id": "123456780" }, "entries": [ { "transaction_code": "22", "receiving_dfi_id": "021000021", "dfi_account_number": "123456789", "amount": "100000", "individual_id": "EMP123", "individual_name": "JOHN DOE" } ] } ] } ``` ### Using Postman 1. Create a request and set the method to `POST`. 2. Enter the URL `https://nacha-navigator.com/api/v1/nacha/generate`. 3. Under **Headers**, add `Content-Type: application/json`. No API key is needed. 4. Under **Body**, choose **raw** and **JSON**, and paste one of the examples. 5. Click **Send**. The response is the file; use **Save response → Save to a file** to keep it. ## How values are written **Defaults and automatic values** | Field | When you leave it out | | --- | --- | | file_creation_date, file_creation_time | The date and time of the request, Eastern Time (America/New_York). | | effective_entry_date | The next banking day after today: weekdays except Federal Reserve holidays. | | company_descriptive_date | Today. | | batch_number | The previous batch’s number plus 1, starting at 1. Numbers you supply must ascend. | | trace_number | The ODFI’s first eight digits plus a seven-digit sequence, unique in the file, skipping numbers you supplied. | | addenda_sequence_number | 1, 2, 3… for each entry’s addenda records. | | priority_code, file_id_modifier, record_size, blocking_factor, format_code | 01, A, 094, 10 and 1. | | originator_status_code, settlement_date, addenda_type_code | 1, three blanks (the ACH operator fills it in) and 05. | - **Uppercase.** Lowercase letters are written in uppercase. Accented letters are rejected rather than guessed at: convert “José” to “JOSE” before you send it. - **Immediate destination and origin.** A 9-digit routing number is written with its leading blank (`" 123456780"`); a 10-character value, such as a company identifier, is written as given. - **Service class code** is required: `200` for mixed debits and credits, `220` credits only, `225` debits only. A mismatch with the entries is a warning. - **Prenotes** (transaction codes 23, 28, 33 and 38) carry an amount of `0`. - **SEC-specific layouts** are written for you: CTX entries get the addenda count and a 16-character name; ARC and BOC take the check serial number in `individual_id`; POP packs the serial number (9), terminal city (4) and state (2) into it; WEB and TEL debits may carry the optional payment type (usually `R` or `S`) in `discretionary_data`. ### Changes from the original API The request format and responses are unchanged. These fixes change the files it writes: - The batch control record’s ODFI and batch number are at positions 80–94, where the specification puts them, and the batch number matches its batch header. - Entry/addenda counts and the block count include addenda records. - Files are padded to an exact multiple of ten records, matching the block count. - A 10-character immediate destination or origin no longer shifts the rest of the file header. - Missing trace numbers are assigned instead of written as zeros; addenda sequence numbers and batch numbers count up. - Default dates come from the time of each request, not from when the server started. - Line breaks and non-ASCII text are rejected, and totals or counts too large for their field are errors instead of being cut off. - Malformed JSON is a `400` (was `500`); unknown paths and wrong methods answer in JSON. ## NACHA format overview A NACHA file is plain text. Each record is exactly 94 characters long, and its first character says what kind of record it is: - **File Header (1)**: the destination, the origin and when the file was created. - **Batch Header (5)**: the company, the SEC code and the effective date of a group of entries. - **Entry Detail (6)**: one payment: routing and account number, amount and receiver. - **Addenda (7)**: optional extra information for an entry; CTX entries can have many. - **Batch Control (8)**: counts, totals and the entry hash of the batch. Generated for you. - **File Control (9)**: the same totals for the whole file. Generated for you. Files are written in blocks of ten records; the last block is filled with records of nines. The [NACHA file format reference](https://nacha-navigator.com/nacha-file-format) describes every field of every record. Important NACHA files are typically validated by the receiving financial institution. Ensure that your data is accurate and follows the NACHA specifications, and test with your bank before you send live payments. [Build a file in your browser](https://nacha-navigator.com/nacha-generator) [Check a file in the NACHA Viewer](https://nacha-navigator.com/) [File format reference](https://nacha-navigator.com/nacha-file-format) --- URL: https://nacha-navigator.com/mcp-server # NACHA Navigator MCP server MCP server Connect Claude, ChatGPT, Cursor or another MCP client to NACHA Navigator: look up NACHA, BAI2 and X9.37 record layouts and codes, decode a line of a NACHA file, and check or build NACHA files from JSON. Free, with no sign-in. Last updated October 30, 2026 MCP server URL ``` https://nacha-navigator.com/mcp ``` - **Transport:** Streamable HTTP. - **Sign-in:** none. No account, no API key. - **Protocol:** MCP 2026-07-28, and the earlier revisions back to 2024-11-05 that start with an initialize handshake. - **Tools:** 9, all read-only. ## What it does The Model Context Protocol (MCP) is an open standard for connecting AI apps to tools. With this server connected, an app such as Claude or ChatGPT can look things up in NACHA Navigator’s reference instead of answering from memory: record layouts, codes and validation rules for NACHA (ACH), BAI2 and X9.37 files. It can also decode a single record of a NACHA file, and check or generate a NACHA file from JSON with the same rules as the [REST API](https://nacha-navigator.com/nacha-generator/api). Every tool is read-only: it computes its answer from what it is sent and the reference data bundled with the server, and changes nothing. Answers link to the pages on this site they come from, so you can check them. ## Connect your AI app Each client below needs only the server URL. Pick yours; the setup follows each client’s own documentation. ### Claude 1. In Claude, open **Customize**, then **Connectors**, and choose **Add custom connector**. 2. Enter the server URL, `https://nacha-navigator.com/mcp`. If you are asked about authentication, choose **No sign-in**. Then choose **Add**. 3. In a chat, open the **+** menu, choose **Connectors** and turn NACHA Navigator on. The Free plan allows one custom connector. On Team and Enterprise plans, an Owner adds it under **Organization settings** › **Connectors** › **Add** › **Custom** › **Web**, and members then connect to it. ### Claude Code Add the server from a terminal: Terminal ``` claude mcp add --transport http nacha-navigator https://nacha-navigator.com/mcp ``` Add `--scope user` to make it available in all your projects: Terminal ``` claude mcp add --transport http --scope user nacha-navigator https://nacha-navigator.com/mcp ``` Or share it with everyone on a project in `.mcp.json` at the project’s root. A remote server needs its `type`: an entry without one is skipped. .mcp.json ```json { "mcpServers": { "nacha-navigator": { "type": "http", "url": "https://nacha-navigator.com/mcp" } } } ``` ### ChatGPT 1. In ChatGPT, open **Plugins** (chatgpt.com/plugins), choose **+**, then **Add custom MCP server**. 2. Enter a name and a description. Under **Connection**, choose **Public endpoint**, enter `https://nacha-navigator.com/mcp` and choose no authentication. 3. Confirm **I understand and want to continue**, then choose **Create as a plugin**. Your workspace’s policies decide whether custom MCP servers are allowed. ### Cursor Add the server to `~/.cursor/mcp.json` for all projects, or to `.cursor/mcp.json` in one project: mcp.json ```json { "mcpServers": { "nacha-navigator": { "url": "https://nacha-navigator.com/mcp" } } } ``` Or, with Cursor installed, use the install link: [Add NACHA Navigator to Cursor](cursor://anysphere.cursor-deeplink/mcp/install?name=nacha-navigator&config=eyJ1cmwiOiJodHRwczovL25hY2hhLW5hdmlnYXRvci5jb20vbWNwIn0=). ### VS Code With GitHub Copilot, run **MCP: Add Server** from the Command Palette, choose **HTTP** and enter `https://nacha-navigator.com/mcp`. To add it by hand, use a workspace `.mcp.json` in the format shown for Claude Code, or VS Code’s own `.vscode/mcp.json`: .vscode/mcp.json ```json { "servers": { "nacha-navigator": { "type": "http", "url": "https://nacha-navigator.com/mcp" } } } ``` ### Devin Desktop (formerly Windsurf) From a terminal: Terminal ``` devin mcp add nacha-navigator https://nacha-navigator.com/mcp ``` Or add it to `~/.config/devin/mcp_config.json` for all projects, or to `.devin/mcp_config.json` in one project: mcp_config.json ```json { "mcpServers": { "nacha-navigator": { "url": "https://nacha-navigator.com/mcp", "transport": "http" } } } ``` ### Gemini CLI Terminal ``` gemini mcp add --transport http nacha-navigator https://nacha-navigator.com/mcp ``` This adds it to the current project; add `-s user` to add it to `~/.gemini/settings.json` for all projects. In a settings file the entry looks like this, where `httpUrl` means Streamable HTTP: settings.json ```json { "mcpServers": { "nacha-navigator": { "httpUrl": "https://nacha-navigator.com/mcp" } } } ``` ### Antigravity Antigravity’s CLI and editor read `~/.gemini/config/mcp_config.json` for all workspaces, or `.agents/mcp_config.json` in one workspace: mcp_config.json ```json { "mcpServers": { "nacha-navigator": { "serverUrl": "https://nacha-navigator.com/mcp" } } } ``` ### MCP Inspector To try the server without an AI app, use the MCP Inspector’s command-line mode. List the tools: Terminal ``` npx @modelcontextprotocol/inspector --cli --transport http --server-url https://nacha-navigator.com/mcp --method tools/list ``` Call one: Terminal ``` npx @modelcontextprotocol/inspector --cli --transport http --server-url https://nacha-navigator.com/mcp \ --method tools/call --tool-name lookup_nacha_code --tool-args-json '{"code":"R01"}' --format json ``` Add `--protocol-era modern` to use the 2026-07-28 revision instead of the initialize handshake: Terminal ``` npx @modelcontextprotocol/inspector --cli --transport http --server-url https://nacha-navigator.com/mcp --protocol-era modern --method tools/list ``` ## Tools Your AI app picks the tool that fits your question. Each one is read-only and returns structured data, a text copy of it, and links to the matching pages on this site. | Tool | What it does | | --- | --- | | `get_nacha_record_layout` | Lists the fields of a NACHA record type, such as the batch header or the entry detail for a given SEC code, with their positions, lengths, formats and meanings. | | `explain_nacha_record` | Decodes one 94-character line of a NACHA file field by field and reports the problems the validator finds in that line on its own. | | `lookup_nacha_code` | Looks up NACHA codes, such as transaction, SEC, service class, return reason and NOC codes, by code or by words in their meanings. | | `explain_nacha_validation_rule` | Explains one of the NACHA validator’s checks by its code, such as ROUTING_CHECK_DIGIT: its severity, what it checks and the part of the Nacha Operating Rules it comes from. | | `validate_nacha_file_request` | Checks a NACHA Generator request, the same JSON the REST API takes, and returns its errors and warnings without building the file. | | `generate_nacha_file` | Builds a NACHA file from that JSON, with the control totals, entry hashes and block fill calculated, and returns it as text. | | `lookup_bai2_type_code` | Looks up BAI2 type codes by code, by words in their descriptions, or by level and direction. | | `get_bai2_record_layout` | Lists the fields of a BAI2 record type, from the 01 file header to the 99 file trailer, in order, with their meanings. | | `get_x9_record_layout` | Lists the fields of an X9.37 record type with their positions, lengths, usage and code values, for X9.100-187 and DSTU X9.37-2003 files. | ## Privacy and limits - **Processed in memory.** The arguments of a tool call, such as a record or a file request, are used to compute the answer and are never stored or logged. Our server keeps only anonymous counts of connections and tool calls, and an error log line with the method and path when a request fails, as the [privacy policy](https://nacha-navigator.com/privacy#mcp-server) describes. - **Nothing goes to a bank.** `generate_nacha_file` returns the file to your AI app. It moves no money. - **Use test data.** Prefer test or redacted values to real account numbers and names. - **Whole files stay in your browser.** No tool reads a whole file. To check a real file privately, open it in the [NACHA Viewer](https://nacha-navigator.com/), which reads it on your device. - **Limits.** A file request can be up to 128 KB of JSON (about 500 entries). The rate limit, counted per network address, is generous, because hosted AI apps share addresses. When it is reached, the server asks the app to wait a minute. - **Informational.** NACHA Navigator is independent and not affiliated with or endorsed by Nacha. Answers are informational, not legal or compliance advice: the Nacha Operating Rules, and for BAI2 and X9.37 files their specifications, are authoritative. The [terms](https://nacha-navigator.com/terms) apply. ## Other files for AI agents - [/llms.txt](https://nacha-navigator.com/llms.txt) is a short guide to the site for language models, and [/llms-full.txt](https://nacha-navigator.com/llms-full.txt) holds the Markdown versions of the pages in one file. - The site’s pages have Markdown versions: add `.md` to a page’s address, as in [/nacha-file-format.md](https://nacha-navigator.com/nacha-file-format.md), or request the page with an `Accept: text/markdown` header. - [/openapi.json](https://nacha-navigator.com/openapi.json) is the OpenAPI 3.1 description of the REST API’s generate and validate endpoints, which the [API documentation](https://nacha-navigator.com/nacha-generator/api) explains. - [/.well-known/api-catalog](https://nacha-navigator.com/.well-known/api-catalog) is the site’s API catalog (RFC 9727). It links that description and the documentation. - [/mcp/server-card](https://nacha-navigator.com/mcp/server-card) is this server’s MCP Server Card, listed in [/.well-known/ai-catalog.json](https://nacha-navigator.com/.well-known/ai-catalog.json), for directories and clients that find servers on their own. - [Sample NACHA, BAI2 and X9.37 files](https://nacha-navigator.com/sample-files) to test with. ## Routing numbers and ACH dates For bank lookups by routing number, ACH dates and payment codes, the sister site PayOps Kit runs its own MCP server. Add it the same way, with its URL: PayOps Kit MCP server URL ``` https://payopskit.com/mcp ``` --- URL: https://nacha-navigator.com/reference # Payment file reference Reference Record layouts, code lists and validation rules for the files NACHA Navigator reads: NACHA (ACH) files, BAI2 balance reports and X9.37 image cash letters. Last updated October 30, 2026 The layouts and code lists on these pages come from the same tables the viewers use to read and check a file, so the pages and the tools agree. When you have a file in hand, open it in a viewer to see the same fields labeled with your own data. ## NACHA (ACH) files The fixed-width files banks exchange to move ACH payments: payroll, vendor and bill payments, and the returns that come back. Open a file in the [NACHA Viewer](https://nacha-navigator.com/), or build one with the [NACHA Generator](https://nacha-navigator.com/nacha-generator). ### [NACHA file format](https://nacha-navigator.com/nacha-file-format) What every field of every record holds: its position, length and format, whether it is mandatory, and the codes that go in it. ### [NACHA file errors](https://nacha-navigator.com/nacha-file-errors) Why a file gets rejected: each error and warning the NACHA Viewer reports, what it means and how to fix it. ### [ACH transaction codes](https://nacha-navigator.com/ach-transaction-codes) What the two digits in positions 2–3 of an entry mean: the account, credit or debit, and whether it is a live entry, a prenote, a zero-dollar entry or a return. ### [ACH reversal](https://nacha-navigator.com/ach-reversal) When an entry or a whole file may be reversed, and how the reversing file is built from the original. Build one in your browser. ## BAI2 balance reports The balance and transaction reports banks send their business customers, account by account. Open a file in the [BAI2 Viewer](https://nacha-navigator.com/bai2-viewer). ### [BAI2 type codes](https://nacha-navigator.com/bai2-type-codes) What a three-digit type code means: its description, whether it reports a balance, a total or a single transaction, and whether it is a credit or a debit. ### [BAI2 file format](https://nacha-navigator.com/bai2-file-format) Every record from the 01 file header to the 99 file trailer, field by field, with funds types, continuation records and control totals. ## X9.37 image cash letters The files of check images and MICR data that banks exchange to clear checks electronically. Open a file in the [X9 Viewer](https://nacha-navigator.com/x9-viewer). ### [X9.37 file format](https://nacha-navigator.com/x9-file-format) Every record type of an image cash letter, from the file header to the check images, with its fields. ## Sample files Made-up data in real formats, for learning a format or testing your own software. ### [Sample files](https://nacha-navigator.com/sample-files) Sample NACHA, BAI2 and X9.37 files to download or open in the viewers, with what each one shows. ## Related free tools Code lookups and ISO 20022 files have their own free sites, from the same maker as NACHA Navigator. ### [Payment code lookup](https://payopskit.com/codes) Look up ACH return reason, notification of change and SEC codes on PayOps Kit. ### [ISO 20022 Navigator](https://iso20022-navigator.com/) Viewers for ISO 20022 camt.053 statements and pain.001 payment files, and for MT940. Missing a reference you need, or found a mistake? [Email us](mailto:davidkaylor95+nachanav@gmail.com). --- URL: https://nacha-navigator.com/nacha-file-format # NACHA file format: ACH record layouts Reference Every field of every NACHA record type, with its position, length, format and rules, plus the transaction, SEC, return and change codes that go in them. Last updated October 30, 2026. Generated from the field definitions the NACHA Viewer validates against: 46 record layouts, 485 fields. ## How a NACHA file is organized A NACHA file, also called an ACH file, is plain text made of fixed-width records. Every record is exactly 94 characters long and sits on its own line, and its first character, the record type code, says what it is. Records always come in this order: 1. [File Header (record type 1): Once, on the first line. Who sent the file, to whom, and when.](https://nacha-navigator.com/nacha-file-format#file-header) 2. [Company/Batch Header (record type 5): Starts each batch. The company, the SEC code and the effective date of the entries that follow.](https://nacha-navigator.com/nacha-file-format#batch-header) 3. [Entry Detail (record type 6): One per payment. Transaction code, routing and account number, amount, receiver and trace number.](https://nacha-navigator.com/nacha-file-format#entry-ppd) 4. [Addenda (record type 7): Optional, after its entry. Remittance details, or the reason for a return or a notification of change.](https://nacha-navigator.com/nacha-file-format#addenda-05) 5. [Company/Batch Control (record type 8): Closes each batch. Entry and addenda count, entry hash, and debit and credit totals.](https://nacha-navigator.com/nacha-file-format#batch-control) 6. [File Control (record type 9): Once, after the last batch. Batch, block and entry counts, entry hash and totals for the file.](https://nacha-navigator.com/nacha-file-format#file-control) 7. [Block fill (all nines): Only if needed. Lines of 94 nines that pad the file to a multiple of 10 records.](https://nacha-navigator.com/nacha-file-format#block-fill) Records 5 to 8 repeat for every batch; a file can hold any number of batches. ## Field rules Each field has a fixed position. Here is line 3 of the sample file, an Entry Detail record, coloured by what each field holds: An Entry Detail record: transaction code 22 (checking credit), routing number 065503348, account 1111111, amount $0.10, receiver JOHN M SMITH, trace number 065503680000001. - **Positions** count from 1 and include both ends: positions 4–11 are the 4th through the 11th characters, 8 in all. - **Numeric fields** are right-justified and zero-filled. Amounts are in cents with no decimal point, so $1,250.00 is `0000125000`. - **Alphanumeric fields** are left-justified and space-filled, in uppercase by convention. - **Dates** are `YYMMDD` and times `HHMM`; the settlement date is a three-digit day of the year that the ACH Operator fills in. - **M/R/O** says whether a field is **Mandatory** (missing or invalid data gets the file or batch rejected), **Required** (missing data can get the entry returned) or **Optional**. N/A marks reserved positions and data the ACH Operator adds. The NACHA Viewer checks every field against these rules. [NACHA file errors](https://nacha-navigator.com/nacha-file-errors) explains each error and warning it can report, and how to fix it. ## Totals and check digits - **Entry hash:** add up the 8-digit Receiving DFI Identification (positions 4–11) of every entry in the batch and keep the rightmost 10 digits. The File Control does the same across all batches. - **Control totals:** each Company/Batch Control counts the batch’s entries and addenda and totals its debits and credits in cents; the File Control totals the whole file and adds the batch and block counts. The transaction code says which total an entry counts in (see [ACH transaction codes](https://nacha-navigator.com/ach-transaction-codes)). - **Check digit:** the ninth routing digit satisfies the ABA 3-7-1 rule: 3×(d1+d4+d7) + 7×(d2+d5+d8) + (d3+d6+d9) is a multiple of 10. To check one routing number, use the [routing number tool on PayOps Kit](https://payopskit.com/routing-number). - **Blocking:** records are grouped in blocks of 10. If the last block is short, it is filled with block-fill records of 94 nines, and the File Control’s block count includes them. The NACHA Viewer recomputes each of these and reports any that don’t match, such as an [entry hash mismatch](https://nacha-navigator.com/nacha-file-errors#bc-entry-hash), a [routing number that fails its check digit](https://nacha-navigator.com/nacha-file-errors#routing-check-digit) or a [file that isn’t padded to a multiple of 10 records](https://nacha-navigator.com/nacha-file-errors#block-fill-missing). ## File Header Record Contains routing and other information to identify the origin and destination of the file. **File Header Record: positions, fields and rules** | Position | Field | Length | Type | M/R/O | Description | | --- | --- | --- | --- | --- | --- | | 1 | **Record Type Code** | 1 char | Code Always 1 | Mandatory | Identifies the type of record in the file. • Always "1" for the File Header Record | | 2–3 | **Priority Code** | 2 chars | Code Always 01 | Required | Identifies the priority of the file. • Only "01" is used | | 4–13 | **Immediate Destination** | 10 chars | Routing bTTTTAAAAC | Mandatory | Routing number of the ACH Operator or receiving point (usually your bank) to which the file is being sent. • Format bTTTTAAAAC: a blank followed by the 9-digit routing number, including its check digit • TTTT = Federal Reserve Routing Symbol, AAAA = ABA Institution Identifier, C = check digit • Right-justified with one leading blank • Must pass the ABA check-digit test | | 14–23 | **Immediate Origin** | 10 chars | Routing bTTTTAAAAC | Mandatory | Routing number of the sending point (usually the ODFI), or another 10-character identifier agreed with the receiving point. • Usually bTTTTAAAAC: a blank followed by the 9-digit routing number • Some banks assign a 10-character company identifier instead (often "1" followed by the Federal Tax ID); use the value your bank specifies • When it is a routing number it must pass the ABA check-digit test | | 24–29 | **File Creation Date** | 6 chars | Date YYMMDD | Mandatory | The date on which the file was created. • Format YYMMDD • Must be a valid calendar date | | 30–33 | **File Creation Time** | 4 chars | Time HHMM | Optional | The time at which the file was created. • Format HHMM, 24-hour clock • Optional; may be left blank | | 34 | **File ID Modifier** | 1 char | Alphanumeric | Mandatory | Distinguishes between multiple files created on the same date for the same destination and origin. • Uppercase A–Z or a digit 0–9 • Use "A" for the first file of the day and the next value for each additional file • Lets the receiving point detect duplicate files | | 35–37 | **Record Size** | 3 chars | Code Always 094 | Mandatory | The number of characters in each record. • Always "094" | | 38–39 | **Blocking Factor** | 2 chars | Code Always 10 | Mandatory | The number of records in each physical block. • Must be "10" • The file is padded with block-fill records (94 nines) to a multiple of 10 records | | 40 | **Format Code** | 1 char | Code Always 1 | Mandatory | Identifies the format of the file. • Always "1" | | 41–63 | **Immediate Destination Name** | 23 chars | Alphanumeric | Optional | Name of the ACH Operator or receiving point to which the file is sent. • Optional • Left-justified and space-filled | | 64–86 | **Immediate Origin Name** | 23 chars | Alphanumeric | Optional | Name of the sending point or originating company that created the file. • Optional • Left-justified and space-filled | | 87–94 | **Reference Code** | 8 chars | Alphanumeric | Optional | For the originator's own use to describe or identify the file. • Optional; often blank • Left-justified and space-filled | ## Company/Batch Header Record Identifies the originator and purpose of the entries contained in the batch. **Company/Batch Header Record: positions, fields and rules** | Position | Field | Length | Type | M/R/O | Description | | --- | --- | --- | --- | --- | --- | | 1 | **Record Type Code** | 1 char | Code Always 5 | Mandatory | Identifies the type of record in the file. • Always "5" for the Company/Batch Header Record | | 2–4 | **Service Class Code** | 3 chars | Code [See codes](https://nacha-navigator.com/nacha-file-format#service-class-codes) | Mandatory | Identifies whether the batch contains debits, credits or both. • 200 = mixed debits and credits • 220 = credits only • 225 = debits only • 280 = automated accounting advices (ADV) • Must match the Service Class Code in the Batch Control Record | | 5–20 | **Company Name** | 16 chars | Alphanumeric | Mandatory | Name of the Originator, as known to and readily recognized by the Receiver. • Usually appears on the Receiver's bank statement • Left-justified and space-filled | | 21–40 | **Company Discretionary Data** | 20 chars | Alphanumeric | Optional | For the Originator or ODFI to use as they agree, e.g. internal reference data. • Optional • Left-justified and space-filled | | 41–50 | **Company Identification** | 10 chars | Alphanumeric | Mandatory | Identifies the Originator to the ODFI and the RDFI. • Usually "1" followed by the 9-digit IRS Employer Identification Number (EIN) • Other prefixes: "3" = DUNS number, "9" = number assigned by the user • Must match the Company Identification in the Batch Control Record • Use the value your ODFI assigned or agreed | | 51–53 | **Standard Entry Class Code** | 3 chars | Code [See codes](https://nacha-navigator.com/nacha-file-format#sec-codes) | Mandatory | Three-letter code identifying the kind of entries in the batch and how they were authorized. • PPD = consumer prearranged payments and deposits · CCD = corporate credits or debits • CTX = corporate trade exchange with EDI remittance · WEB = internet or mobile · TEL = telephone • IAT = international · ARC, BOC, POP, RCK = converted checks · COR = notifications of change • Must be uppercase | | 54–63 | **Company Entry Description** | 10 chars | Alphanumeric | Mandatory | Tells the Receiver what the entries are for, e.g. PAYROLL or GAS BILL. • Usually printed on the Receiver's bank statement • Required by the Rules for some batches: REVERSAL (reversing entries), RECLAIM (reclamations), RETURN FEE, RETRY PYMT (reinitiated entries), NONSETTLED (entries that could not settle), ACCTVERIFY (micro-entries) • By SEC code: REDEPCHECK (RCK), AUTOENROLL (ENR), NO CHECK (XCK), HCCLAIMPMT (CCD health care payments); TRX carries the keeper’s routing number, and WEB person-to-person credits need a description the Receiver will recognize • Since March 20, 2026: PAYROLL on PPD credits for wages, salaries and similar pay; PURCHASE on consumer debits for online purchases of goods (WEB, or PPD or TEL under a Standing Authorization) • Left-justified and space-filled | | 64–69 | **Company Descriptive Date** | 6 chars | Alphanumeric | Optional | A date the Originator wants shown to the Receiver, such as a pay period, in any format. • Optional and free-form, e.g. YYMMDD or "MAR 15" • Optional same-day indicator: "SDHHMM" (e.g. SD1300) shows the Originator intends settlement in that same-day window; it does not by itself make entries settle the same day • Left-justified and space-filled | | 70–75 | **Effective Entry Date** | 6 chars | Date YYMMDD | Required | The banking day on which the Originator intends the entries to settle. • Format YYMMDD • Should be a banking day: not a weekend or Federal Reserve holiday • A past or non-banking date settles at the ACH Operator's next settlement opportunity • For Same Day ACH, use the current day's date and submit before the same-day deadline | | 76–78 | **Settlement Date (Julian)** | 3 chars | Julian day DDD | Not applicable: reserved, or filled in by the ACH Operator | Day of the year on which the batch settles. Inserted by the receiving ACH Operator. • Leave blank when creating a file; the ACH Operator fills it in • Format DDD: 001–366 | | 79 | **Originator Status Code** | 1 char | Code [See codes](https://nacha-navigator.com/nacha-file-format#other-codes) | Mandatory | Identifies the status of the Originator under the Nacha Rules. • 1 = depository financial institution bound by the Nacha Rules (used on virtually all files) • 2 = Federal Government entity or agency not subject to the Rules • 0 = ADV file prepared by an ACH Operator | | 80–87 | **Originating DFI Identification** | 8 chars | Routing TTTTAAAA | Mandatory | First 8 digits of the routing number of the ODFI (no check digit). • Must match the ODFI in the Batch Control Record • Trace numbers in the batch start with this value • In return and NOC batches this is the RDFI that is sending them back | | 88–94 | **Batch Number** | 7 chars | Numeric | Mandatory | Number assigned in ascending sequence to each batch in the file. • Usually starts at 0000001 • Must match the Batch Number in the Batch Control Record • Right-justified and zero-filled | ### International (IAT) batches IAT batches use their own header layout, with foreign-exchange and currency fields. #### IAT: International ACH Transaction 17 fields Batch header for international entries: replaces company fields with foreign-exchange and country data. **Company/Batch Header Record — IAT: positions, fields and rules** | Position | Field | Length | Type | M/R/O | Description | | --- | --- | --- | --- | --- | --- | | 1 | **Record Type Code** | 1 char | Code Always 5 | Mandatory | Identifies the type of record in the file. • Always "5" for the Company/Batch Header Record | | 2–4 | **Service Class Code** | 3 chars | Code [See codes](https://nacha-navigator.com/nacha-file-format#service-class-codes) | Mandatory | Identifies whether the batch contains debits, credits or both. • 200 = mixed debits and credits • 220 = credits only • 225 = debits only • 280 = automated accounting advices (ADV) • Must match the Service Class Code in the Batch Control Record | | 5–20 | **IAT Indicator** | 16 chars | Alphanumeric | Optional | Blank in IAT batches. Contains "IATCOR" in a batch of IAT Notifications of Change. • Left-justified and space-filled | | 21–22 | **Foreign Exchange Indicator** | 2 chars | Code [See codes](https://nacha-navigator.com/nacha-file-format#other-codes) | Mandatory | How the amount is converted between currencies. • FV = fixed-to-variable: sent as a fixed amount, received after conversion • VF = variable-to-fixed: converted so that a fixed amount is received • FF = fixed-to-fixed: same currency at both ends, no conversion | | 23 | **Foreign Exchange Reference Indicator** | 1 char | Code [See codes](https://nacha-navigator.com/nacha-file-format#other-codes) | Mandatory | Identifies what the Foreign Exchange Reference field contains. • 1 = foreign exchange rate • 2 = foreign exchange reference number • 3 = space-filled | | 24–38 | **Foreign Exchange Reference** | 15 chars | Alphanumeric | Required | The exchange rate or reference number named by the indicator; blank when the indicator is 3. • Left-justified and space-filled | | 39–40 | **ISO Destination Country Code** | 2 chars | Alphanumeric | Mandatory | Two-letter ISO 3166 code of the country in which the entry is to be received. • Uppercase letters, e.g. US, CA, MX | | 41–50 | **Originator Identification** | 10 chars | Alphanumeric | Mandatory | Identifies the Originator (the IAT equivalent of Company Identification). • Must match the Company Identification in the Batch Control Record | | 51–53 | **Standard Entry Class Code** | 3 chars | Code [See codes](https://nacha-navigator.com/nacha-file-format#sec-codes) | Mandatory | Three-letter code identifying the kind of entries in the batch and how they were authorized. • PPD = consumer prearranged payments and deposits · CCD = corporate credits or debits • CTX = corporate trade exchange with EDI remittance · WEB = internet or mobile · TEL = telephone • IAT = international · ARC, BOC, POP, RCK = converted checks · COR = notifications of change • Must be uppercase | | 54–63 | **Company Entry Description** | 10 chars | Alphanumeric | Mandatory | Tells the Receiver what the entries are for, e.g. PAYROLL or GAS BILL. • Usually printed on the Receiver's bank statement • Required by the Rules for some batches: REVERSAL (reversing entries), RECLAIM (reclamations), RETURN FEE, RETRY PYMT (reinitiated entries), NONSETTLED (entries that could not settle), ACCTVERIFY (micro-entries) • By SEC code: REDEPCHECK (RCK), AUTOENROLL (ENR), NO CHECK (XCK), HCCLAIMPMT (CCD health care payments); TRX carries the keeper’s routing number, and WEB person-to-person credits need a description the Receiver will recognize • Since March 20, 2026: PAYROLL on PPD credits for wages, salaries and similar pay; PURCHASE on consumer debits for online purchases of goods (WEB, or PPD or TEL under a Standing Authorization) • Left-justified and space-filled | | 64–66 | **ISO Originating Currency Code** | 3 chars | Alphanumeric | Mandatory | Three-letter ISO 4217 code of the currency in which the entry was originated. • Uppercase letters, e.g. USD | | 67–69 | **ISO Destination Currency Code** | 3 chars | Alphanumeric | Mandatory | Three-letter ISO 4217 code of the currency in which the entry is to be received. • Uppercase letters, e.g. CAD | | 70–75 | **Effective Entry Date** | 6 chars | Date YYMMDD | Required | The banking day on which the Originator intends the entries to settle. • Format YYMMDD • Should be a banking day: not a weekend or Federal Reserve holiday • A past or non-banking date settles at the ACH Operator's next settlement opportunity • For Same Day ACH, use the current day's date and submit before the same-day deadline | | 76–78 | **Settlement Date (Julian)** | 3 chars | Julian day DDD | Not applicable: reserved, or filled in by the ACH Operator | Day of the year on which the batch settles. Inserted by the receiving ACH Operator. • Leave blank when creating a file; the ACH Operator fills it in • Format DDD: 001–366 | | 79 | **Originator Status Code** | 1 char | Code [See codes](https://nacha-navigator.com/nacha-file-format#other-codes) | Mandatory | Identifies the status of the Originator under the Nacha Rules. • 1 = depository financial institution bound by the Nacha Rules (used on virtually all files) • 2 = Federal Government entity or agency not subject to the Rules • 0 = ADV file prepared by an ACH Operator | | 80–87 | **Go Identification/Originating DFI Identification** | 8 chars | Routing TTTTAAAA | Mandatory | For outbound IAT, the ODFI routing number (first 8 digits); for inbound IAT, the U.S. Gateway Operator identification. • Must match the ODFI in the Batch Control Record • Trace numbers in the batch start with this value | | 88–94 | **Batch Number** | 7 chars | Numeric | Mandatory | Number assigned in ascending sequence to each batch in the file. • Usually starts at 0000001 • Must match the Batch Number in the Batch Control Record • Right-justified and zero-filled | ## Entry Detail Record Contains the data for the individual entry, including the transaction code, account information, and amount. The table shows the PPD layout, the most common; the other SEC codes follow it. **Entry Detail Record — PPD: positions, fields and rules** | Position | Field | Length | Type | M/R/O | Description | | --- | --- | --- | --- | --- | --- | | 1 | **Record Type Code** | 1 char | Code Always 6 | Mandatory | Identifies the type of record in the file. • Always "6" for the Entry Detail Record | | 2–3 | **Transaction Code** | 2 chars | Code [See codes](https://nacha-navigator.com/nacha-file-format#transaction-codes) | Mandatory | Identifies the type of account and whether the entry is a credit, a debit, a prenote, a zero-dollar entry or a return/NOC. • First digit: 2 = checking, 3 = savings, 4 = general ledger, 5 = loan • Last digit: 2 = credit, 3 = credit prenote, 4 = zero-dollar credit, 1 = return or NOC of a credit • Last digit: 7 = debit, 8 = debit prenote, 9 = zero-dollar debit, 6 = return or NOC of a debit • 22 = checking credit · 27 = checking debit · 32 = savings credit · 37 = savings debit | | 4–11 | **Receiving DFI Identification** | 8 chars | Routing TTTTAAAA | Mandatory | First 8 digits of the routing number of the Receiver's financial institution (the RDFI). • TTTT = Federal Reserve Routing Symbol, AAAA = ABA Institution Identifier • The check digit (the 9th digit) follows in position 12 • Added up across the batch to produce the Entry Hash | | 12 | **Check Digit** | 1 char | Numeric | Mandatory | The ninth digit of the RDFI routing number, computed from the first eight. • ABA 3-7-1 rule: 3×(d1+d4+d7) + 7×(d2+d5+d8) + (d3+d6+d9) must be a multiple of 10 • A wrong check digit means the routing number was mistyped | | 13–29 | **DFI Account Number** | 17 chars | Alphanumeric | Required | The Receiver's account number at the RDFI. • Left-justified and space-filled • Enter the significant characters only; omit embedded spaces • For a prenote, the account that will receive future live entries | | 30–39 | **Amount** | 10 chars | Amount Cents, no decimal point | Mandatory | The amount of the entry, in cents. • In cents, with no decimal point: $100.00 is "0000010000" • Right-justified and zero-filled; the largest amount is $99,999,999.99 • Must be zero for prenotes and zero-dollar entries | | 40–54 | **Individual Identification Number** | 15 chars | Alphanumeric | Optional | Number the Originator uses to identify the Receiver, such as an employee ID, customer or loan number. • Optional • Left-justified and space-filled | | 55–76 | **Individual Name** | 22 chars | Alphanumeric | Required | Name of the Receiver. • Required • Left-justified and space-filled • May appear on the Receiver's bank statement | | 77–78 | **Discretionary Data** | 2 chars | Alphanumeric | Optional | For the ODFI or Originator to use as they agree; it has no meaning to the ACH Network. • Optional • Left-justified and space-filled | | 79 | **Addenda Record Indicator** | 1 char | Code [See codes](https://nacha-navigator.com/nacha-file-format#other-codes) | Mandatory | Shows whether one or more Addenda Records follow this entry. • 0 = no Addenda Record follows • 1 = one or more Addenda Records follow | | 80–94 | **Trace Number** | 15 chars | Numeric | Mandatory | Uniquely identifies the entry within its batch and lets it be traced through the ACH Network. • First 8 digits: the ODFI routing number from the Company/Batch Header (no check digit) • Last 7 digits: a sequence number assigned by the ODFI • Unique within the batch and in ascending order within it • With the Batch Number, File Creation Date and File ID Modifier it identifies the entry in the file; many ODFIs also want it unique in the file | ### Entry Detail by SEC code Positions 1–39 and 79–94 are the same for almost every Standard Entry Class code; the middle of the record changes. Each layout below lists only the fields that differ from PPD, with the full layout one click away. #### CCD: Corporate Credit or Debit Differs from PPD in positions 40–76 Credit or debit between business accounts; may carry one addenda record of remittance data. **Entry Detail Record — CCD: fields that differ from PPD** | Position | Field | Length | Type | M/R/O | Description | | --- | --- | --- | --- | --- | --- | | 40–54 | **Identification Number** | 15 chars | Alphanumeric | Optional | Number the Originator uses to identify the Receiver, such as a vendor, customer or invoice number. • Optional • Left-justified and space-filled | | 55–76 | **Receiving Company Name** | 22 chars | Alphanumeric | Required | Name of the Receiver (a business). • Required • Left-justified and space-filled | Positions not listed match the PPD layout. #### CTX: Corporate Trade Exchange Differs from PPD in positions 30–76 Business-to-business payment carrying up to 9,999 addenda records of EDI remittance data. **Entry Detail Record — CTX: fields that differ from PPD** | Position | Field | Length | Type | M/R/O | Description | | --- | --- | --- | --- | --- | --- | | 30–39 | **Total Amount** | 10 chars | Amount Cents, no decimal point | Mandatory | Total amount of the entry, in cents. • In cents, with no decimal point: $100.00 is "0000010000" • Right-justified and zero-filled; the largest amount is $99,999,999.99 • Zero for acknowledgment entries | | 40–54 | **Identification Number** | 15 chars | Alphanumeric | Optional | Number the Originator uses to identify the Receiver, such as a vendor, customer or invoice number. • Optional • Left-justified and space-filled | | 55–58 | **Number of Addenda Records** | 4 chars | Numeric | Mandatory | Number of Addenda Records that follow this entry (type 05 remittance addenda, 0000–9999). • Must equal the number of Addenda Records actually following the entry • Right-justified and zero-filled | | 59–74 | **Receiving Company Name/ID Number** | 16 chars | Alphanumeric | Required | Name or identification number of the Receiver (a business). • Required • Left-justified and space-filled | | 75–76 | **Reserved** | 2 chars | Alphanumeric | Not applicable: reserved, or filled in by the ACH Operator | Reserved for future use. Leave blank. • Space-filled | Positions not listed match the PPD layout. #### WEB: Internet-Initiated/Mobile Entry Differs from PPD in positions 77–78 Consumer debit authorized over the internet or a mobile device, or a person-to-person credit. **Entry Detail Record — WEB: fields that differ from PPD** | Position | Field | Length | Type | M/R/O | Description | | --- | --- | --- | --- | --- | --- | | 77–78 | **Payment Type Code** | 2 chars | Code [See codes](https://nacha-navigator.com/nacha-file-format#other-codes) | Optional | Optional code the Originator may use to show whether a debit is recurring or a single entry. • Optional since September 17, 2021; ask your ODFI whether it wants one • "R " = recurring and "S " = single entry are the usual values • Other values have no standard meaning, and RDFIs cannot rely on the field • Left-justified and space-filled | Positions not listed match the PPD layout. #### TEL: Telephone-Initiated Entry Differs from PPD in positions 77–78 Consumer debit authorized orally over the telephone. **Entry Detail Record — TEL: fields that differ from PPD** | Position | Field | Length | Type | M/R/O | Description | | --- | --- | --- | --- | --- | --- | | 77–78 | **Payment Type Code** | 2 chars | Code [See codes](https://nacha-navigator.com/nacha-file-format#other-codes) | Optional | Optional code the Originator may use to show whether a debit is recurring or a single entry. • Optional since September 17, 2021; ask your ODFI whether it wants one • "R " = recurring and "S " = single entry are the usual values • Other values have no standard meaning, and RDFIs cannot rely on the field • Left-justified and space-filled | Positions not listed match the PPD layout. #### IAT: International ACH Transaction Differs from PPD in positions 4–78 International entry. Followed by seven mandatory addenda (types 10–16) and up to seven optional ones. **Entry Detail Record — IAT: fields that differ from PPD** | Position | Field | Length | Type | M/R/O | Description | | --- | --- | --- | --- | --- | --- | | 4–11 | **Gateway Operator Identification/Receiving DFI Identification** | 8 chars | Routing TTTTAAAA | Mandatory | For outbound IAT, the routing number (first 8 digits) of the U.S. Gateway Operator; for inbound IAT, of the RDFI. • The check digit follows in position 12 • Added up across the batch to produce the Entry Hash | | 13–16 | **Number of Addenda Records** | 4 chars | Numeric | Mandatory | Number of Addenda Records that follow this entry (all IAT addenda: seven mandatory plus up to two type 17 and five type 18). • Must equal the number of Addenda Records actually following the entry • Right-justified and zero-filled | | 17–29 | **Reserved** | 13 chars | Alphanumeric | Not applicable: reserved, or filled in by the ACH Operator | Reserved for future use. Leave blank. • Space-filled | | 40–74 | **Foreign Receiver's Account Number/DFI Account Number** | 35 chars | Alphanumeric | Mandatory | The Receiver's account number at the foreign or domestic receiving institution. • Left-justified and space-filled | | 75–76 | **Reserved** | 2 chars | Alphanumeric | Not applicable: reserved, or filled in by the ACH Operator | Reserved for future use. Leave blank. • Space-filled | | 77 | **Gateway Operator OFAC Screening Indicator** | 1 char | Code [See codes](https://nacha-navigator.com/nacha-file-format#other-codes) | Optional | Set by the Gateway Operator when its OFAC screening flagged the entry. • "1" = flagged as a possible OFAC match • Blank or "0" = not flagged | | 78 | **Secondary OFAC Screening Indicator** | 1 char | Code [See codes](https://nacha-navigator.com/nacha-file-format#other-codes) | Optional | Set by a secondary screener (such as the ODFI or RDFI) when its OFAC screening flagged the entry. • "1" = flagged as a possible OFAC match • Blank or "0" = not flagged | Positions not listed match the PPD layout. #### ARC: Accounts Receivable Entry Differs from PPD in positions 40–76 Eligible check received by mail or delivery service, at a dropbox, or in person to pay a bill at a staffed location, converted to a one-time ACH debit. **Entry Detail Record — ARC: fields that differ from PPD** | Position | Field | Length | Type | M/R/O | Description | | --- | --- | --- | --- | --- | --- | | 40–54 | **Check Serial Number** | 15 chars | Alphanumeric | Mandatory | Serial number of the source check, from its MICR line. • Mandatory • Left-justified and space-filled | | 55–76 | **Individual Name** | 22 chars | Alphanumeric | Optional | Name of the Receiver. • Optional • Left-justified and space-filled • May appear on the Receiver's bank statement | Positions not listed match the PPD layout. #### BOC: Back Office Conversion Differs from PPD in positions 40–76 Eligible check presented at a point of purchase or a staffed bill-payment location and converted to a one-time ACH debit in the back office. **Entry Detail Record — BOC: fields that differ from PPD** | Position | Field | Length | Type | M/R/O | Description | | --- | --- | --- | --- | --- | --- | | 40–54 | **Check Serial Number** | 15 chars | Alphanumeric | Mandatory | Serial number of the source check, from its MICR line. • Mandatory • Left-justified and space-filled | | 55–76 | **Individual Name** | 22 chars | Alphanumeric | Optional | Name of the Receiver. • Optional • Left-justified and space-filled • May appear on the Receiver's bank statement | Positions not listed match the PPD layout. #### POP: Point-of-Purchase Entry Differs from PPD in positions 40–76 Eligible check converted to a one-time ACH debit on the spot, at a point of purchase or a staffed bill-payment location; the voided check is handed back. **Entry Detail Record — POP: fields that differ from PPD** | Position | Field | Length | Type | M/R/O | Description | | --- | --- | --- | --- | --- | --- | | 40–48 | **Check Serial Number** | 9 chars | Alphanumeric | Mandatory | Serial number of the source check, from its MICR line. • Mandatory • Left-justified and space-filled | | 49–52 | **Terminal City** | 4 chars | Alphanumeric | Mandatory | Abbreviated name of the city where the point-of-purchase terminal is located. • First four characters of the city name • Left-justified and space-filled | | 53–54 | **Terminal State** | 2 chars | Alphanumeric | Mandatory | Two-letter state abbreviation of the terminal location. • Uppercase postal abbreviation | | 55–76 | **Individual Name** | 22 chars | Alphanumeric | Optional | Name of the Receiver. • Optional • Left-justified and space-filled • May appear on the Receiver's bank statement | Positions not listed match the PPD layout. #### RCK: Re-presented Check Entry Differs from PPD in positions 40–76 A check returned for insufficient or uncollected funds, re-presented as an ACH debit. **Entry Detail Record — RCK: fields that differ from PPD** | Position | Field | Length | Type | M/R/O | Description | | --- | --- | --- | --- | --- | --- | | 40–54 | **Check Serial Number** | 15 chars | Alphanumeric | Mandatory | Serial number of the source check, from its MICR line. • Mandatory • Left-justified and space-filled | | 55–76 | **Individual Name** | 22 chars | Alphanumeric | Optional | Name of the Receiver. • Optional • Left-justified and space-filled • May appear on the Receiver's bank statement | Positions not listed match the PPD layout. #### CIE: Customer Initiated Entry Differs from PPD in positions 40–76 Credit initiated by a consumer, e.g. a bill payment through online banking. Name comes before the ID number. **Entry Detail Record — CIE: fields that differ from PPD** | Position | Field | Length | Type | M/R/O | Description | | --- | --- | --- | --- | --- | --- | | 40–54 | **Individual Name** | 15 chars | Alphanumeric | Required | Name of the Receiver. • Required • Left-justified and space-filled • May appear on the Receiver's bank statement | | 55–76 | **Individual Identification Number** | 22 chars | Alphanumeric | Required | Number the Originator uses to identify the Receiver, such as an employee ID, customer or loan number. • Required • Left-justified and space-filled | Positions not listed match the PPD layout. #### MTE: Machine Transfer Entry Differs from PPD in positions 40–76 Entry initiated at an ATM or other electronic terminal. Followed by one type 02 addenda. **Entry Detail Record — MTE: fields that differ from PPD** | Position | Field | Length | Type | M/R/O | Description | | --- | --- | --- | --- | --- | --- | | 40–54 | **Individual Name** | 15 chars | Alphanumeric | Required | Name of the Receiver. • Required • Left-justified and space-filled • May appear on the Receiver's bank statement | | 55–76 | **Individual Identification Number** | 22 chars | Alphanumeric | Required | Number the Originator uses to identify the Receiver, such as an employee ID, customer or loan number. • Required • Left-justified and space-filled | Positions not listed match the PPD layout. #### POS: Point-of-Sale Entry Differs from PPD in positions 55–78 Consumer debit at an electronic terminal to pay for a purchase or withdraw cash, or a credit that adjusts one. Followed by one type 02 addenda. **Entry Detail Record — POS: fields that differ from PPD** | Position | Field | Length | Type | M/R/O | Description | | --- | --- | --- | --- | --- | --- | | 55–76 | **Individual Name** | 22 chars | Alphanumeric | Optional | Name of the Receiver. • Optional • Left-justified and space-filled • May appear on the Receiver's bank statement | | 77–78 | **Card Transaction Type Code** | 2 chars | Code [See codes](https://nacha-navigator.com/nacha-file-format#other-codes) | Mandatory | Identifies the kind of card transaction. • 01 = purchase of goods or services · 02 = cash · 03 = return reversal • 11 = purchase reversal · 12 = cash reversal · 13 = return · 21 = adjustment · 99 = miscellaneous | Positions not listed match the PPD layout. #### SHR: Shared Network Transaction Differs from PPD in positions 40–78 Point-of-sale debit, or a credit that adjusts one, in a shared network where the ODFI and RDFI have an agreement beyond the Rules. Followed by one type 02 addenda. **Entry Detail Record — SHR: fields that differ from PPD** | Position | Field | Length | Type | M/R/O | Description | | --- | --- | --- | --- | --- | --- | | 40–43 | **Card Expiration Date** | 4 chars | Date MMYY | Mandatory | Expiration date of the card used. • Format MMYY | | 44–54 | **Document Reference Number** | 11 chars | Numeric | Mandatory | Number identifying the transaction document. • Right-justified and zero-filled | | 55–76 | **Individual Card Account Number** | 22 chars | Alphanumeric | Mandatory | The card account number used for the transaction. • Left-justified and space-filled | | 77–78 | **Card Transaction Type Code** | 2 chars | Code [See codes](https://nacha-navigator.com/nacha-file-format#other-codes) | Mandatory | Identifies the kind of card transaction. • 01 = purchase of goods or services · 02 = cash · 03 = return reversal • 11 = purchase reversal · 12 = cash reversal · 13 = return · 21 = adjustment · 99 = miscellaneous | Positions not listed match the PPD layout. #### ACK: ACH Payment Acknowledgment Differs from PPD in positions 30–76 Zero-dollar entry an RDFI sends to acknowledge receipt of a CCD credit. **Entry Detail Record — ACK: fields that differ from PPD** | Position | Field | Length | Type | M/R/O | Description | | --- | --- | --- | --- | --- | --- | | 30–39 | **Total Amount** | 10 chars | Amount Cents, no decimal point | Mandatory | Total amount of the entry, in cents. • In cents, with no decimal point: $100.00 is "0000010000" • Right-justified and zero-filled; the largest amount is $99,999,999.99 • Zero for acknowledgment entries | | 40–54 | **Original Entry Trace Number** | 15 chars | Numeric | Mandatory | Trace Number of the entry being acknowledged. • 15 digits, copied from the original entry | | 55–76 | **Receiving Company Name** | 22 chars | Alphanumeric | Required | Name of the Receiver (a business). • Required • Left-justified and space-filled | Positions not listed match the PPD layout. #### ATX: Financial EDI Acknowledgment Differs from PPD in positions 30–76 Zero-dollar entry an RDFI sends to acknowledge receipt of a CTX credit. **Entry Detail Record — ATX: fields that differ from PPD** | Position | Field | Length | Type | M/R/O | Description | | --- | --- | --- | --- | --- | --- | | 30–39 | **Total Amount** | 10 chars | Amount Cents, no decimal point | Mandatory | Total amount of the entry, in cents. • In cents, with no decimal point: $100.00 is "0000010000" • Right-justified and zero-filled; the largest amount is $99,999,999.99 • Zero for acknowledgment entries | | 40–54 | **Original Entry Trace Number** | 15 chars | Numeric | Mandatory | Trace Number of the entry being acknowledged. • 15 digits, copied from the original entry | | 55–58 | **Number of Addenda Records** | 4 chars | Numeric | Mandatory | Number of Addenda Records that follow this entry (type 05 addenda, 0000–9999). • Must equal the number of Addenda Records actually following the entry • Right-justified and zero-filled | | 59–74 | **Receiving Company Name/ID Number** | 16 chars | Alphanumeric | Required | Name or identification number of the Receiver (a business). • Required • Left-justified and space-filled | | 75–76 | **Reserved** | 2 chars | Alphanumeric | Not applicable: reserved, or filled in by the ACH Operator | Reserved for future use. Leave blank. • Space-filled | Positions not listed match the PPD layout. #### DNE: Death Notification Entry Same positions as PPD Zero-dollar entry from a Federal Government agency reporting the death of a benefit recipient; carries one addenda. Every position matches the PPD layout above; only the Standard Entry Class code in the batch header differs. #### ENR: Automated Enrollment Entry Differs from PPD in positions 13–76 Zero-dollar entry a DFI sends to a Federal Government agency to enroll a beneficiary in direct deposit. The enrollee’s account details travel in the addenda, so positions 13–29 are left blank. **Entry Detail Record — ENR: fields that differ from PPD** | Position | Field | Length | Type | M/R/O | Description | | --- | --- | --- | --- | --- | --- | | 13–29 | **DFI Account Number** | 17 chars | Alphanumeric | Optional | Left blank on an enrollment: the enrollee’s account number is in the type 05 addenda. • Left blank for Federal Government enrollments • The RDFI fields (positions 4–12) hold the routing number of the agency program | | 40–54 | **Identification Number** | 15 chars | Alphanumeric | Optional | Number the Originator uses to identify the Receiver, such as a vendor, customer or invoice number. • Optional • Left-justified and space-filled | | 55–58 | **Number of Addenda Records** | 4 chars | Numeric | Mandatory | Number of Addenda Records that follow this entry (type 05 addenda carrying the enrollment data). • Must equal the number of Addenda Records actually following the entry • Right-justified and zero-filled | | 59–74 | **Receiving Company Name/ID Number** | 16 chars | Alphanumeric | Required | Identifies the Federal Government benefit program the enrollment is for, such as SOCIAL SECURITY. • The program code the Treasury Green Book lists for the agency • Left-justified and space-filled | | 75–76 | **Reserved** | 2 chars | Alphanumeric | Not applicable: reserved, or filled in by the ACH Operator | Reserved for future use. Leave blank. • Space-filled | Positions not listed match the PPD layout. #### TRC: Check Truncation Entry Differs from PPD in positions 40–78 Debit for a single check that was truncated (kept by the collecting institution) under a check truncation program. **Entry Detail Record — TRC: fields that differ from PPD** | Position | Field | Length | Type | M/R/O | Description | | --- | --- | --- | --- | --- | --- | | 40–54 | **Check Serial Number** | 15 chars | Alphanumeric | Mandatory | Serial number of the source check, from its MICR line. • Mandatory • Left-justified and space-filled | | 55–60 | **Process Control Field** | 6 chars | Alphanumeric | Mandatory | The process control (transaction code) field from the MICR line of the check. • Left-justified and space-filled | | 61–76 | **Item Research Number** | 16 chars | Alphanumeric | Mandatory | Number that identifies the check for research, such as its item sequence number. • Left-justified and space-filled | | 77–78 | **Item Type Indicator** | 2 chars | Alphanumeric | Optional | Identifies the type of truncated item, as agreed between the participating DFIs. • Optional • Left-justified and space-filled | Positions not listed match the PPD layout. #### TRX: Check Truncation Entries Exchange Differs from PPD in positions 30–78 One debit for several truncated checks drawn on the same paying bank; the checks are listed in up to 9,999 addenda records. **Entry Detail Record — TRX: fields that differ from PPD** | Position | Field | Length | Type | M/R/O | Description | | --- | --- | --- | --- | --- | --- | | 30–39 | **Total Amount** | 10 chars | Amount Cents, no decimal point | Mandatory | Total amount of the entry, in cents. • In cents, with no decimal point: $100.00 is "0000010000" • Right-justified and zero-filled; the largest amount is $99,999,999.99 • Zero for acknowledgment entries | | 40–54 | **Identification Number** | 15 chars | Alphanumeric | Optional | Number the Originator uses to identify the Receiver, such as a vendor, customer or invoice number. • Optional • Left-justified and space-filled | | 55–58 | **Number of Addenda Records** | 4 chars | Numeric | Mandatory | Number of Addenda Records that follow this entry (type 05 addenda, 0000–9999). • Must equal the number of Addenda Records actually following the entry • Right-justified and zero-filled | | 59–74 | **Receiving Company Name/ID Number** | 16 chars | Alphanumeric | Required | Name or identification number of the Receiver (a business). • Required • Left-justified and space-filled | | 75–76 | **Reserved** | 2 chars | Alphanumeric | Not applicable: reserved, or filled in by the ACH Operator | Reserved for future use. Leave blank. • Space-filled | | 77–78 | **Item Type Indicator** | 2 chars | Alphanumeric | Optional | Identifies the type of truncated item, as agreed between the participating DFIs. • Optional • Left-justified and space-filled | Positions not listed match the PPD layout. #### XCK: Destroyed Check Entry Differs from PPD in positions 40–76 Debit used to collect an eligible check that was lost or destroyed, or damaged so it cannot be processed. The batch description is NO CHECK. **Entry Detail Record — XCK: fields that differ from PPD** | Position | Field | Length | Type | M/R/O | Description | | --- | --- | --- | --- | --- | --- | | 40–54 | **Check Serial Number** | 15 chars | Alphanumeric | Mandatory | Serial number of the source check, from its MICR line. • Mandatory • Left-justified and space-filled | | 55–60 | **Process Control Field** | 6 chars | Alphanumeric | Mandatory | The process control (transaction code) field from the MICR line of the check. • Left-justified and space-filled | | 61–76 | **Item Research Number** | 16 chars | Alphanumeric | Mandatory | Number that identifies the check for research, such as its item sequence number. • Left-justified and space-filled | Positions not listed match the PPD layout. #### COR: Notification of Change / Refused NOC Differs from PPD in positions 40–76 Zero-dollar entry an RDFI sends to tell the Originator that information in an entry was wrong. Carries one type 98 addenda. **Entry Detail Record — COR: fields that differ from PPD** | Position | Field | Length | Type | M/R/O | Description | | --- | --- | --- | --- | --- | --- | | 40–54 | **Identification Number** | 15 chars | Alphanumeric | Optional | Copied from the original entry (Individual Identification Number or Identification Number). • Left-justified and space-filled | | 55–76 | **Individual Name/Receiving Company Name** | 22 chars | Alphanumeric | Required | Copied from the original entry. • Left-justified and space-filled | Positions not listed match the PPD layout. #### ADV: Automated Accounting Advice Differs from PPD in positions 13–94 Non-monetary accounting advice an ACH Operator sends to a DFI about its ACH activity: the amounts are information, not money moved. **Entry Detail Record — ADV: fields that differ from PPD** | Position | Field | Length | Type | M/R/O | Description | | --- | --- | --- | --- | --- | --- | | 13–27 | **DFI Account Number** | 15 chars | Alphanumeric | Mandatory | The account at the DFI the advice applies to. • Left-justified and space-filled | | 28–39 | **Amount** | 12 chars | Amount Cents, no decimal point | Mandatory | The amount of the advice, in cents. • 12 digits, in cents, zero-filled | | 40–48 | **Advice Routing Number** | 9 chars | Routing TTTTAAAAC | Mandatory | Routing number of the institution the advice is for. • 9 digits, including the check digit | | 49–53 | **File Identification** | 5 chars | Alphanumeric | Optional | Identifies the file the advice relates to. • Left-justified and space-filled | | 54 | **ACH Operator Data** | 1 char | Alphanumeric | Optional | For use by the ACH Operator. | | 55–76 | **Individual Name** | 22 chars | Alphanumeric | Mandatory | Name of the Receiver. • Mandatory • Left-justified and space-filled • May appear on the Receiver's bank statement | | 80–87 | **Routing Number of ACH Operator** | 8 chars | Routing TTTTAAAA | Mandatory | First 8 digits of the routing number of the ACH Operator that created the advice. | | 88–90 | **Julian Date on Which This Advice Is Created** | 3 chars | Julian day DDD | Mandatory | Day of the year on which the advice was created. • 001–366 | | 91–94 | **Sequence Number Within Batch** | 4 chars | Numeric | Mandatory | Sequence number of the advice within its batch. • Right-justified and zero-filled | Positions not listed match the PPD layout. ## Addenda Record Provides additional information about the preceding Entry Detail Record. The table shows type 05, payment related information; the other types follow it. **Addenda Record — type 05: positions, fields and rules** | Position | Field | Length | Type | M/R/O | Description | | --- | --- | --- | --- | --- | --- | | 1 | **Record Type Code** | 1 char | Code Always 7 | Mandatory | Identifies the type of record in the file. • Always "7" for the Addenda Record | | 2–3 | **Addenda Type Code** | 2 chars | Code Always 05 | Mandatory | Identifies the layout of the Addenda Record. • Always "05" in this layout • 02 = terminal information (POS, SHR, MTE) · 05 = payment related information • 10–18 = IAT addenda · 98 = Notification of Change · 99 = return | | 4–83 | **Payment Related Information** | 80 chars | Alphanumeric | Optional | Remittance information for the Receiver: free-form text, ANSI ASC X12 data segments, or Nacha-endorsed banking conventions. • ACK, CCD, CIE, PPD and WEB entries may carry one; a DNE entry carries exactly one • ENR entries carry 1 to 9,999; ATX, CTX and TRX entries up to 9,999 • X12 segments end with a terminator, usually a backslash (\\) or a tilde (\~) • Left-justified and space-filled | | 84–87 | **Addenda Sequence Number** | 4 chars | Numeric | Mandatory | Position of this addenda among the type 05 addenda that belong to the same entry, starting at 0001. • Starts at 0001 and increases by one for each addenda of the entry • Right-justified and zero-filled | | 88–94 | **Entry Detail Sequence Number** | 7 chars | Numeric | Mandatory | The last 7 digits of the Trace Number of the Entry Detail Record this addenda belongs to. • Links the addenda to its entry • Right-justified and zero-filled | ### Other addenda types The Addenda Type Code in positions 2–3 decides the layout: 02 for terminal data, 98 for notifications of change, 99 for returns, and 10–18 for international (IAT) entries. #### 02: Point-of-sale terminal information (POS, SHR, MTE) 12 fields Where and when a card or ATM transaction happened. Exactly one follows each POS, SHR and MTE entry. **Addenda Record — type 02: positions, fields and rules** | Position | Field | Length | Type | M/R/O | Description | | --- | --- | --- | --- | --- | --- | | 1 | **Record Type Code** | 1 char | Code Always 7 | Mandatory | Identifies the type of record in the file. • Always "7" for the Addenda Record | | 2–3 | **Addenda Type Code** | 2 chars | Code Always 02 | Mandatory | Identifies the layout of the Addenda Record. • Always "02" in this layout • 02 = terminal information (POS, SHR, MTE) · 05 = payment related information • 10–18 = IAT addenda · 98 = Notification of Change · 99 = return | | 4–10 | **Reference Information #1** | 7 chars | Alphanumeric | Optional | Additional reference data identifying the transaction. • Optional • Left-justified and space-filled | | 11–13 | **Reference Information #2** | 3 chars | Alphanumeric | Optional | Additional reference data identifying the transaction. • Optional • Left-justified and space-filled | | 14–19 | **Terminal Identification Code** | 6 chars | Alphanumeric | Required | Identifies the electronic terminal where the transaction took place. • Left-justified and space-filled | | 20–25 | **Transaction Serial Number** | 6 chars | Alphanumeric | Required | Serial number the terminal assigned to the transaction. • Left-justified and space-filled | | 26–29 | **Transaction Date** | 4 chars | Date MMDD | Required | Month and day of the transaction. • Format MMDD | | 30–35 | **Authorization Code or Card Expiration Date** | 6 chars | Alphanumeric | Optional | Authorization code from the card issuer, or the card expiration date. • Optional • Left-justified and space-filled | | 36–62 | **Terminal Location** | 27 chars | Alphanumeric | Required | Street address or description of where the terminal is. • Left-justified and space-filled | | 63–77 | **Terminal City** | 15 chars | Alphanumeric | Required | City where the terminal is located. • Left-justified and space-filled | | 78–79 | **Terminal State** | 2 chars | Alphanumeric | Required | Two-letter state abbreviation of the terminal location. • Uppercase postal abbreviation | | 80–94 | **Trace Number** | 15 chars | Numeric | Mandatory | The Trace Number of the entry this addenda belongs to (the same value as in its Entry Detail Record). • Identical to positions 80–94 of the Entry Detail Record it follows | #### 98: Notification of Change 9 fields Sent by the RDFI on a COR entry to tell the Originator which information in an earlier entry was wrong. **Addenda Record — type 98: positions, fields and rules** | Position | Field | Length | Type | M/R/O | Description | | --- | --- | --- | --- | --- | --- | | 1 | **Record Type Code** | 1 char | Code Always 7 | Mandatory | Identifies the type of record in the file. • Always "7" for the Addenda Record | | 2–3 | **Addenda Type Code** | 2 chars | Code Always 98 | Mandatory | Identifies the layout of the Addenda Record. • Always "98" in this layout • 02 = terminal information (POS, SHR, MTE) · 05 = payment related information • 10–18 = IAT addenda · 98 = Notification of Change · 99 = return | | 4–6 | **Change Code** | 3 chars | Code [See codes](https://nacha-navigator.com/nacha-file-format#change-codes) | Mandatory | Identifies the information the RDFI is correcting (C01–C03, C05–C09, C13 or C14). • "C" followed by two digits • Determines how Corrected Data is laid out • C04 and C10–C12 are retired: the Rules no longer define them | | 7–21 | **Original Entry Trace Number** | 15 chars | Numeric | Mandatory | Trace Number of the entry the NOC corrects. • 15 digits, copied unchanged | | 22–27 | **Reserved** | 6 chars | Alphanumeric | Not applicable: reserved, or filled in by the ACH Operator | Reserved for future use. Leave blank. • Space-filled | | 28–35 | **Original Receiving DFI Identification** | 8 chars | Routing TTTTAAAA | Mandatory | The Receiving DFI Identification (positions 4–11) from the original entry. • 8 digits, without the check digit | | 36–64 | **Corrected Data** | 29 chars | Alphanumeric | Mandatory | The correct information, laid out as the change code requires. • C01: correct account number in positions 1–17 · C02: correct routing number (9 digits) in 1–9 • C03: routing number in 1–9, blanks in 10–12, account number in 13–29 · C05: correct transaction code in 1–2 • C06: account number in 1–17, blanks in 18–20, transaction code in 21–22 · C07: routing (9), account (17), transaction code (2) • C08 (IAT): correct Receiving DFI Identification · C09: correct individual or receiver ID number in 1–22 • C13: no fixed layout · C14: "IAT" in 1–3 | | 65–79 | **Reserved** | 15 chars | Alphanumeric | Not applicable: reserved, or filled in by the ACH Operator | Reserved for future use. Leave blank. • Space-filled | | 80–94 | **Trace Number** | 15 chars | Numeric | Mandatory | The Trace Number of the NOC entry this addenda belongs to (the same value as in its Entry Detail Record). • Identical to positions 80–94 of the Entry Detail Record it follows | #### 98: Refused Notification of Change (C61–C69) 11 fields Sent by the ODFI to refuse a Notification of Change that was misrouted or incorrectly formatted. **Addenda Record — type 98: positions, fields and rules** | Position | Field | Length | Type | M/R/O | Description | | --- | --- | --- | --- | --- | --- | | 1 | **Record Type Code** | 1 char | Code Always 7 | Mandatory | Identifies the type of record in the file. • Always "7" for the Addenda Record | | 2–3 | **Addenda Type Code** | 2 chars | Code Always 98 | Mandatory | Identifies the layout of the Addenda Record. • Always "98" in this layout • 02 = terminal information (POS, SHR, MTE) · 05 = payment related information • 10–18 = IAT addenda · 98 = Notification of Change · 99 = return | | 4–6 | **Refused COR Code** | 3 chars | Code [See codes](https://nacha-navigator.com/nacha-file-format#change-codes) | Mandatory | Why the ODFI is refusing the NOC (C61–C69). • "C" followed by two digits | | 7–21 | **Original Entry Trace Number** | 15 chars | Numeric | Mandatory | Trace Number of the entry the refused NOC related to. • 15 digits, copied unchanged | | 22–27 | **Reserved** | 6 chars | Alphanumeric | Not applicable: reserved, or filled in by the ACH Operator | Reserved for future use. Leave blank. • Space-filled | | 28–35 | **Original Receiving DFI Identification** | 8 chars | Routing TTTTAAAA | Mandatory | The Receiving DFI Identification (positions 4–11) from the original entry. • 8 digits, without the check digit | | 36–64 | **Corrected Data** | 29 chars | Alphanumeric | Mandatory | The Corrected Data from the NOC being refused. • Copied from the NOC | | 65–67 | **Change Code** | 3 chars | Code [See codes](https://nacha-navigator.com/nacha-file-format#change-codes) | Mandatory | The change code of the NOC being refused. • Copied from the NOC | | 68–74 | **Trace Sequence Number** | 7 chars | Numeric | Mandatory | The last 7 digits of the Trace Number of the NOC being refused. • Right-justified and zero-filled | | 75–79 | **Reserved** | 5 chars | Alphanumeric | Not applicable: reserved, or filled in by the ACH Operator | Reserved for future use. Leave blank. • Space-filled | | 80–94 | **Trace Number** | 15 chars | Numeric | Mandatory | The Trace Number of the refused NOC entry this addenda belongs to (the same value as in its Entry Detail Record). • Identical to positions 80–94 of the Entry Detail Record it follows | #### 99: Return 8 fields Sent by the RDFI with a return entry to identify the original entry and the reason it was returned. **Addenda Record — type 99: positions, fields and rules** | Position | Field | Length | Type | M/R/O | Description | | --- | --- | --- | --- | --- | --- | | 1 | **Record Type Code** | 1 char | Code Always 7 | Mandatory | Identifies the type of record in the file. • Always "7" for the Addenda Record | | 2–3 | **Addenda Type Code** | 2 chars | Code Always 99 | Mandatory | Identifies the layout of the Addenda Record. • Always "99" in this layout • 02 = terminal information (POS, SHR, MTE) · 05 = payment related information • 10–18 = IAT addenda · 98 = Notification of Change · 99 = return | | 4–6 | **Return Reason Code** | 3 chars | Code [See codes](https://nacha-navigator.com/nacha-file-format#return-reason-codes) | Mandatory | Why the RDFI returned the entry (R01–R85; R90 from March 17, 2028). • "R" followed by two digits | | 7–21 | **Original Entry Trace Number** | 15 chars | Numeric | Mandatory | Trace Number of the entry being returned. • 15 digits, copied unchanged | | 22–27 | **Date of Death** | 6 chars | Date YYMMDD | Optional | Date of death of the account holder or beneficiary; used with return reasons R14 and R15. • Format YYMMDD • Blank for other return reasons | | 28–35 | **Original Receiving DFI Identification** | 8 chars | Routing TTTTAAAA | Mandatory | The Receiving DFI Identification (positions 4–11) from the original entry. • 8 digits, without the check digit | | 36–79 | **Addenda Information** | 44 chars | Alphanumeric | Optional | Additional information from the RDFI about the return. • Optional • Left-justified and space-filled | | 80–94 | **Trace Number** | 15 chars | Numeric | Mandatory | The Trace Number of the return entry this addenda belongs to (the same value as in its Entry Detail Record). • Identical to positions 80–94 of the Entry Detail Record it follows | #### 99: Dishonored return (R61, R62, R67–R70) 12 fields Sent by the ODFI to dishonor a return that was misrouted, untimely, duplicated or contained errors. **Addenda Record — type 99: positions, fields and rules** | Position | Field | Length | Type | M/R/O | Description | | --- | --- | --- | --- | --- | --- | | 1 | **Record Type Code** | 1 char | Code Always 7 | Mandatory | Identifies the type of record in the file. • Always "7" for the Addenda Record | | 2–3 | **Addenda Type Code** | 2 chars | Code Always 99 | Mandatory | Identifies the layout of the Addenda Record. • Always "99" in this layout • 02 = terminal information (POS, SHR, MTE) · 05 = payment related information • 10–18 = IAT addenda · 98 = Notification of Change · 99 = return | | 4–6 | **Dishonored Return Reason Code** | 3 chars | Code [See codes](https://nacha-navigator.com/nacha-file-format#return-reason-codes) | Mandatory | Why the ODFI is dishonoring the return. • R61, R62, R67, R68, R69 or R70 | | 7–21 | **Original Entry Trace Number** | 15 chars | Numeric | Mandatory | Trace Number of the original forward entry. • 15 digits, copied unchanged | | 22–27 | **Reserved** | 6 chars | Alphanumeric | Not applicable: reserved, or filled in by the ACH Operator | Reserved for future use. Leave blank. • Space-filled | | 28–35 | **Original Receiving DFI Identification** | 8 chars | Routing TTTTAAAA | Mandatory | The Receiving DFI Identification (positions 4–11) from the original entry. • 8 digits, without the check digit | | 36–38 | **Reserved** | 3 chars | Alphanumeric | Not applicable: reserved, or filled in by the ACH Operator | Reserved for future use. Leave blank. • Space-filled | | 39–53 | **Return Trace Number** | 15 chars | Numeric | Mandatory | Trace Number of the return entry. • 15 digits, copied from the return | | 54–56 | **Return Settlement Date** | 3 chars | Julian day DDD | Mandatory | Day of the year on which the return settled. • Day of the year, 001–366 | | 57–58 | **Return Reason Code** | 2 chars | Code [See codes](https://nacha-navigator.com/nacha-file-format#return-reason-codes) | Mandatory | Reason code of the return being dishonored. • The two digits of the return reason code, without the "R" (e.g. "01" for R01) | | 59–79 | **Addenda Information** | 21 chars | Alphanumeric | Optional | Additional information from the ODFI. • Optional • Left-justified and space-filled | | 80–94 | **Trace Number** | 15 chars | Numeric | Mandatory | The Trace Number of the dishonored return entry this addenda belongs to (the same value as in its Entry Detail Record). • Identical to positions 80–94 of the Entry Detail Record it follows | #### 99: Contested dishonored return (R71–R77) 15 fields Sent by the RDFI to contest an ODFI’s dishonor of its return. **Addenda Record — type 99: positions, fields and rules** | Position | Field | Length | Type | M/R/O | Description | | --- | --- | --- | --- | --- | --- | | 1 | **Record Type Code** | 1 char | Code Always 7 | Mandatory | Identifies the type of record in the file. • Always "7" for the Addenda Record | | 2–3 | **Addenda Type Code** | 2 chars | Code Always 99 | Mandatory | Identifies the layout of the Addenda Record. • Always "99" in this layout • 02 = terminal information (POS, SHR, MTE) · 05 = payment related information • 10–18 = IAT addenda · 98 = Notification of Change · 99 = return | | 4–6 | **Contested Dishonored Return Reason Code** | 3 chars | Code [See codes](https://nacha-navigator.com/nacha-file-format#return-reason-codes) | Mandatory | Why the RDFI is contesting the dishonored return. • R71–R77 | | 7–21 | **Original Entry Trace Number** | 15 chars | Numeric | Mandatory | Trace Number of the original forward entry. • 15 digits, copied unchanged | | 22–27 | **Date Original Entry Returned** | 6 chars | Date YYMMDD | Mandatory | The date on which the original entry was returned. • Format YYMMDD | | 28–35 | **Original Receiving DFI Identification** | 8 chars | Routing TTTTAAAA | Mandatory | The Receiving DFI Identification (positions 4–11) from the original entry. • 8 digits, without the check digit | | 36–38 | **Original Settlement Date** | 3 chars | Julian day DDD | Mandatory | Day of the year on which the original entry settled. • Day of the year, 001–366 | | 39–53 | **Return Trace Number** | 15 chars | Numeric | Mandatory | Trace Number of the return entry. • 15 digits, copied from the return | | 54–56 | **Return Settlement Date** | 3 chars | Julian day DDD | Mandatory | Day of the year on which the return settled. • Day of the year, 001–366 | | 57–58 | **Return Reason Code** | 2 chars | Code [See codes](https://nacha-navigator.com/nacha-file-format#return-reason-codes) | Mandatory | Reason code of the original return. • The two digits of the return reason code, without the "R" (e.g. "01" for R01) | | 59–73 | **Dishonored Return Trace Number** | 15 chars | Numeric | Mandatory | Trace Number of the dishonored return entry. • 15 digits | | 74–76 | **Dishonored Return Settlement Date** | 3 chars | Julian day DDD | Mandatory | Day of the year on which the dishonored return settled. • Day of the year, 001–366 | | 77–78 | **Dishonored Return Reason Code** | 2 chars | Code [See codes](https://nacha-navigator.com/nacha-file-format#return-reason-codes) | Mandatory | Reason code of the dishonored return. • The two digits of the code, without the "R" (e.g. "69" for R69) | | 79 | **Reserved** | 1 char | Alphanumeric | Not applicable: reserved, or filled in by the ACH Operator | Reserved for future use. Leave blank. • Space-filled | | 80–94 | **Trace Number** | 15 chars | Numeric | Mandatory | The Trace Number of the contested dishonored return entry this addenda belongs to (the same value as in its Entry Detail Record). • Identical to positions 80–94 of the Entry Detail Record it follows | #### 10: IAT transaction and receiver 8 fields First mandatory IAT addenda. **Addenda Record — type 10: positions, fields and rules** | Position | Field | Length | Type | M/R/O | Description | | --- | --- | --- | --- | --- | --- | | 1 | **Record Type Code** | 1 char | Code Always 7 | Mandatory | Identifies the type of record in the file. • Always "7" for the Addenda Record | | 2–3 | **Addenda Type Code** | 2 chars | Code Always 10 | Mandatory | Identifies the layout of the Addenda Record. • Always "10" in this layout • 02 = terminal information (POS, SHR, MTE) · 05 = payment related information • 10–18 = IAT addenda · 98 = Notification of Change · 99 = return | | 4–6 | **Transaction Type Code** | 3 chars | Code [See codes](https://nacha-navigator.com/nacha-file-format#other-codes) | Mandatory | Identifies the reason for the international payment. • e.g. SAL = salary/payroll, BUS = business, PEN = pension, ANN = annuity, MIS = miscellaneous | | 7–24 | **Foreign Payment Amount** | 18 chars | Amount Cents, no decimal point | Required | For inbound IAT, the amount of the payment in the originating currency, in its smallest unit. • Right-justified and zero-filled | | 25–46 | **Foreign Trace Number** | 22 chars | Alphanumeric | Optional | Trace number assigned to the entry in the originating national payment system. • Optional • Left-justified and space-filled | | 47–81 | **Receiving Company Name/Individual Name** | 35 chars | Alphanumeric | Mandatory | Name of the Receiver. • Mandatory • Left-justified and space-filled | | 82–87 | **Reserved** | 6 chars | Alphanumeric | Not applicable: reserved, or filled in by the ACH Operator | Reserved for future use. Leave blank. • Space-filled | | 88–94 | **Entry Detail Sequence Number** | 7 chars | Numeric | Mandatory | The last 7 digits of the Trace Number of the Entry Detail Record this addenda belongs to. • Links the addenda to its entry • Right-justified and zero-filled | #### 11: IAT originator name and address 6 fields Second mandatory IAT addenda. **Addenda Record — type 11: positions, fields and rules** | Position | Field | Length | Type | M/R/O | Description | | --- | --- | --- | --- | --- | --- | | 1 | **Record Type Code** | 1 char | Code Always 7 | Mandatory | Identifies the type of record in the file. • Always "7" for the Addenda Record | | 2–3 | **Addenda Type Code** | 2 chars | Code Always 11 | Mandatory | Identifies the layout of the Addenda Record. • Always "11" in this layout • 02 = terminal information (POS, SHR, MTE) · 05 = payment related information • 10–18 = IAT addenda · 98 = Notification of Change · 99 = return | | 4–38 | **Originator Name** | 35 chars | Alphanumeric | Mandatory | Name of the Originator. • Mandatory • Left-justified and space-filled | | 39–73 | **Originator Street Address** | 35 chars | Alphanumeric | Mandatory | Street address of the Originator. • Mandatory • Left-justified and space-filled | | 74–87 | **Reserved** | 14 chars | Alphanumeric | Not applicable: reserved, or filled in by the ACH Operator | Reserved for future use. Leave blank. • Space-filled | | 88–94 | **Entry Detail Sequence Number** | 7 chars | Numeric | Mandatory | The last 7 digits of the Trace Number of the Entry Detail Record this addenda belongs to. • Links the addenda to its entry • Right-justified and zero-filled | #### 12: IAT originator city and country 6 fields Third mandatory IAT addenda. **Addenda Record — type 12: positions, fields and rules** | Position | Field | Length | Type | M/R/O | Description | | --- | --- | --- | --- | --- | --- | | 1 | **Record Type Code** | 1 char | Code Always 7 | Mandatory | Identifies the type of record in the file. • Always "7" for the Addenda Record | | 2–3 | **Addenda Type Code** | 2 chars | Code Always 12 | Mandatory | Identifies the layout of the Addenda Record. • Always "12" in this layout • 02 = terminal information (POS, SHR, MTE) · 05 = payment related information • 10–18 = IAT addenda · 98 = Notification of Change · 99 = return | | 4–38 | **Originator City & State/Province** | 35 chars | Alphanumeric | Mandatory | City and state or province of the Originator, separated by an asterisk and ending with a backslash. • Mandatory • Left-justified and space-filled | | 39–73 | **Originator Country & Postal Code** | 35 chars | Alphanumeric | Mandatory | Country and postal code of the Originator, separated by an asterisk and ending with a backslash. • Mandatory • Left-justified and space-filled | | 74–87 | **Reserved** | 14 chars | Alphanumeric | Not applicable: reserved, or filled in by the ACH Operator | Reserved for future use. Leave blank. • Space-filled • From March 19, 2027, positions 74–83 may carry the Originator’s date of birth (optional) | | 88–94 | **Entry Detail Sequence Number** | 7 chars | Numeric | Mandatory | The last 7 digits of the Trace Number of the Entry Detail Record this addenda belongs to. • Links the addenda to its entry • Right-justified and zero-filled | #### 13: IAT originating DFI 8 fields Fourth mandatory IAT addenda. **Addenda Record — type 13: positions, fields and rules** | Position | Field | Length | Type | M/R/O | Description | | --- | --- | --- | --- | --- | --- | | 1 | **Record Type Code** | 1 char | Code Always 7 | Mandatory | Identifies the type of record in the file. • Always "7" for the Addenda Record | | 2–3 | **Addenda Type Code** | 2 chars | Code Always 13 | Mandatory | Identifies the layout of the Addenda Record. • Always "13" in this layout • 02 = terminal information (POS, SHR, MTE) · 05 = payment related information • 10–18 = IAT addenda · 98 = Notification of Change · 99 = return | | 4–38 | **Originating DFI Name** | 35 chars | Alphanumeric | Mandatory | Name of the ODFI (for inbound IAT, the foreign correspondent that sent it). • Mandatory • Left-justified and space-filled | | 39–40 | **Originating DFI Identification Number Qualifier** | 2 chars | Code [See codes](https://nacha-navigator.com/nacha-file-format#other-codes) | Mandatory | Identifies the kind of identification number that follows. • 01 = national clearing system number • 02 = BIC code • 03 = IBAN code • From March 19, 2027, 03 is deleted and a qualifier for non-bank foreign financial agencies is added | | 41–74 | **Originating DFI Identification** | 34 chars | Alphanumeric | Mandatory | Identification number of the ODFI, of the kind named by the qualifier. • Mandatory • Left-justified and space-filled | | 75–77 | **Originating DFI Branch Country Code** | 3 chars | Alphanumeric | Mandatory | ISO 3166 country code of the ODFI branch. • ISO 3166 country code, left-justified | | 78–87 | **Reserved** | 10 chars | Alphanumeric | Not applicable: reserved, or filled in by the ACH Operator | Reserved for future use. Leave blank. • Space-filled | | 88–94 | **Entry Detail Sequence Number** | 7 chars | Numeric | Mandatory | The last 7 digits of the Trace Number of the Entry Detail Record this addenda belongs to. • Links the addenda to its entry • Right-justified and zero-filled | #### 14: IAT receiving DFI 8 fields Fifth mandatory IAT addenda. **Addenda Record — type 14: positions, fields and rules** | Position | Field | Length | Type | M/R/O | Description | | --- | --- | --- | --- | --- | --- | | 1 | **Record Type Code** | 1 char | Code Always 7 | Mandatory | Identifies the type of record in the file. • Always "7" for the Addenda Record | | 2–3 | **Addenda Type Code** | 2 chars | Code Always 14 | Mandatory | Identifies the layout of the Addenda Record. • Always "14" in this layout • 02 = terminal information (POS, SHR, MTE) · 05 = payment related information • 10–18 = IAT addenda · 98 = Notification of Change · 99 = return | | 4–38 | **Receiving DFI Name** | 35 chars | Alphanumeric | Mandatory | Name of the RDFI. • Mandatory • Left-justified and space-filled | | 39–40 | **Receiving DFI Identification Number Qualifier** | 2 chars | Code [See codes](https://nacha-navigator.com/nacha-file-format#other-codes) | Mandatory | Identifies the kind of identification number that follows. • 01 = national clearing system number • 02 = BIC code • 03 = IBAN code • From March 19, 2027, 03 is deleted and a qualifier for non-bank foreign financial agencies is added | | 41–74 | **Receiving DFI Identification** | 34 chars | Alphanumeric | Mandatory | Identification number of the RDFI, of the kind named by the qualifier. • Mandatory • Left-justified and space-filled | | 75–77 | **Receiving DFI Branch Country Code** | 3 chars | Alphanumeric | Mandatory | ISO 3166 country code of the RDFI branch. • ISO 3166 country code, left-justified | | 78–87 | **Reserved** | 10 chars | Alphanumeric | Not applicable: reserved, or filled in by the ACH Operator | Reserved for future use. Leave blank. • Space-filled | | 88–94 | **Entry Detail Sequence Number** | 7 chars | Numeric | Mandatory | The last 7 digits of the Trace Number of the Entry Detail Record this addenda belongs to. • Links the addenda to its entry • Right-justified and zero-filled | #### 15: IAT receiver identification and address 6 fields Sixth mandatory IAT addenda. **Addenda Record — type 15: positions, fields and rules** | Position | Field | Length | Type | M/R/O | Description | | --- | --- | --- | --- | --- | --- | | 1 | **Record Type Code** | 1 char | Code Always 7 | Mandatory | Identifies the type of record in the file. • Always "7" for the Addenda Record | | 2–3 | **Addenda Type Code** | 2 chars | Code Always 15 | Mandatory | Identifies the layout of the Addenda Record. • Always "15" in this layout • 02 = terminal information (POS, SHR, MTE) · 05 = payment related information • 10–18 = IAT addenda · 98 = Notification of Change · 99 = return | | 4–18 | **Receiver Identification Number** | 15 chars | Alphanumeric | Optional | Number the Originator uses to identify the Receiver. • Optional • Left-justified and space-filled | | 19–53 | **Receiver Street Address** | 35 chars | Alphanumeric | Mandatory | Street address of the Receiver. • Mandatory • Left-justified and space-filled | | 54–87 | **Reserved** | 34 chars | Alphanumeric | Not applicable: reserved, or filled in by the ACH Operator | Reserved for future use. Leave blank. • Space-filled | | 88–94 | **Entry Detail Sequence Number** | 7 chars | Numeric | Mandatory | The last 7 digits of the Trace Number of the Entry Detail Record this addenda belongs to. • Links the addenda to its entry • Right-justified and zero-filled | #### 16: IAT receiver city and country 6 fields Seventh mandatory IAT addenda. **Addenda Record — type 16: positions, fields and rules** | Position | Field | Length | Type | M/R/O | Description | | --- | --- | --- | --- | --- | --- | | 1 | **Record Type Code** | 1 char | Code Always 7 | Mandatory | Identifies the type of record in the file. • Always "7" for the Addenda Record | | 2–3 | **Addenda Type Code** | 2 chars | Code Always 16 | Mandatory | Identifies the layout of the Addenda Record. • Always "16" in this layout • 02 = terminal information (POS, SHR, MTE) · 05 = payment related information • 10–18 = IAT addenda · 98 = Notification of Change · 99 = return | | 4–38 | **Receiver City & State/Province** | 35 chars | Alphanumeric | Mandatory | City and state or province of the Receiver, separated by an asterisk and ending with a backslash. • Mandatory • Left-justified and space-filled | | 39–73 | **Receiver Country & Postal Code** | 35 chars | Alphanumeric | Mandatory | Country and postal code of the Receiver, separated by an asterisk and ending with a backslash. • Mandatory • Left-justified and space-filled | | 74–87 | **Reserved** | 14 chars | Alphanumeric | Not applicable: reserved, or filled in by the ACH Operator | Reserved for future use. Leave blank. • Space-filled • From March 19, 2027, positions 74–83 may carry the Receiver’s date of birth (optional) | | 88–94 | **Entry Detail Sequence Number** | 7 chars | Numeric | Mandatory | The last 7 digits of the Trace Number of the Entry Detail Record this addenda belongs to. • Links the addenda to its entry • Right-justified and zero-filled | #### 17: IAT remittance information (optional, up to 2) 5 fields Optional IAT payment related information. **Addenda Record — type 17: positions, fields and rules** | Position | Field | Length | Type | M/R/O | Description | | --- | --- | --- | --- | --- | --- | | 1 | **Record Type Code** | 1 char | Code Always 7 | Mandatory | Identifies the type of record in the file. • Always "7" for the Addenda Record | | 2–3 | **Addenda Type Code** | 2 chars | Code Always 17 | Mandatory | Identifies the layout of the Addenda Record. • Always "17" in this layout • 02 = terminal information (POS, SHR, MTE) · 05 = payment related information • 10–18 = IAT addenda · 98 = Notification of Change · 99 = return | | 4–83 | **Payment Related Information** | 80 chars | Alphanumeric | Optional | Remittance information for the Receiver. • Up to two type 17 addenda per IAT entry • Left-justified and space-filled | | 84–87 | **Addenda Sequence Number** | 4 chars | Numeric | Mandatory | Position of this addenda among the type 17 addenda that belong to the same entry, starting at 0001. • Starts at 0001 and increases by one for each addenda of the entry • Right-justified and zero-filled | | 88–94 | **Entry Detail Sequence Number** | 7 chars | Numeric | Mandatory | The last 7 digits of the Trace Number of the Entry Detail Record this addenda belongs to. • Links the addenda to its entry • Right-justified and zero-filled | #### 18: IAT foreign correspondent bank (optional, up to 5) 9 fields Identifies a foreign correspondent bank involved in the payment. **Addenda Record — type 18: positions, fields and rules** | Position | Field | Length | Type | M/R/O | Description | | --- | --- | --- | --- | --- | --- | | 1 | **Record Type Code** | 1 char | Code Always 7 | Mandatory | Identifies the type of record in the file. • Always "7" for the Addenda Record | | 2–3 | **Addenda Type Code** | 2 chars | Code Always 18 | Mandatory | Identifies the layout of the Addenda Record. • Always "18" in this layout • 02 = terminal information (POS, SHR, MTE) · 05 = payment related information • 10–18 = IAT addenda · 98 = Notification of Change · 99 = return | | 4–38 | **Foreign Correspondent Bank Name** | 35 chars | Alphanumeric | Mandatory | Name of the foreign correspondent bank. • Mandatory • Left-justified and space-filled | | 39–40 | **Foreign Correspondent Bank Identification Number Qualifier** | 2 chars | Code [See codes](https://nacha-navigator.com/nacha-file-format#other-codes) | Mandatory | Identifies the kind of identification number that follows. • 01 = national clearing system number • 02 = BIC code • 03 = IBAN code • From March 19, 2027, 03 is deleted and a qualifier for non-bank foreign financial agencies is added | | 41–74 | **Foreign Correspondent Bank Identification Number** | 34 chars | Alphanumeric | Mandatory | Identification number of the correspondent bank, of the kind named by the qualifier. • Mandatory • Left-justified and space-filled | | 75–77 | **Foreign Correspondent Bank Branch Country Code** | 3 chars | Alphanumeric | Mandatory | ISO 3166 country code of the correspondent bank branch. • ISO 3166 country code, left-justified | | 78–83 | **Reserved** | 6 chars | Alphanumeric | Not applicable: reserved, or filled in by the ACH Operator | Reserved for future use. Leave blank. • Space-filled | | 84–87 | **Addenda Sequence Number** | 4 chars | Numeric | Mandatory | Position of this addenda among the type 18 addenda that belong to the same entry, starting at 0001. • Starts at 0001 and increases by one for each addenda of the entry • Right-justified and zero-filled | | 88–94 | **Entry Detail Sequence Number** | 7 chars | Numeric | Mandatory | The last 7 digits of the Trace Number of the Entry Detail Record this addenda belongs to. • Links the addenda to its entry • Right-justified and zero-filled | ## Company/Batch Control Record Contains the counts, hash totals, and total dollar amounts for the preceding batch. **Company/Batch Control Record: positions, fields and rules** | Position | Field | Length | Type | M/R/O | Description | | --- | --- | --- | --- | --- | --- | | 1 | **Record Type Code** | 1 char | Code Always 8 | Mandatory | Identifies the type of record in the file. • Always "8" for the Company/Batch Control Record | | 2–4 | **Service Class Code** | 3 chars | Code [See codes](https://nacha-navigator.com/nacha-file-format#service-class-codes) | Mandatory | Identifies whether the batch contains debits, credits or both. • Must match the Service Class Code in the Company/Batch Header Record | | 5–10 | **Entry/Addenda Count** | 6 chars | Numeric | Mandatory | The number of Entry Detail and Addenda Records in the batch. • Counts every type 6 and type 7 record in the batch • Right-justified and zero-filled | | 11–20 | **Entry Hash** | 10 chars | Numeric | Mandatory | Sum of the 8-digit Receiving DFI Identifications (positions 4–11) of every entry in the batch. • If the sum has more than 10 digits, only the rightmost 10 are kept • Right-justified and zero-filled | | 21–32 | **Total Debit Entry Dollar Amount** | 12 chars | Amount Cents, no decimal point | Mandatory | Total of all debit entries in the batch, in cents. • In cents, with no decimal point; zero when the batch has no debits • Right-justified and zero-filled | | 33–44 | **Total Credit Entry Dollar Amount** | 12 chars | Amount Cents, no decimal point | Mandatory | Total of all credit entries in the batch, in cents. • In cents, with no decimal point; zero when the batch has no credits • Right-justified and zero-filled | | 45–54 | **Company Identification** | 10 chars | Alphanumeric | Required | Identifies the Originator. • Must match the Company Identification (IAT: Originator Identification) in the Company/Batch Header Record | | 55–73 | **Message Authentication Code** | 19 chars | Alphanumeric | Optional | Code used to authenticate the batch when the ODFI and RDFI use message authentication. • Optional; normally blank • Left-justified and space-filled | | 74–79 | **Reserved** | 6 chars | Alphanumeric | Not applicable: reserved, or filled in by the ACH Operator | Reserved for future use. Leave blank. • Space-filled | | 80–87 | **Originating DFI Identification** | 8 chars | Routing TTTTAAAA | Mandatory | First 8 digits of the routing number of the ODFI. • Must match the ODFI in the Company/Batch Header Record | | 88–94 | **Batch Number** | 7 chars | Numeric | Mandatory | The number of the batch this record closes. • Must match the Batch Number in the Company/Batch Header Record • Right-justified and zero-filled | ### Accounting advice (ADV) batches #### ADV: Automated Accounting Advices 9 fields Batch control for ADV batches (Service Class Code 280); dollar totals are 20 digits long. **Company/Batch Control Record — ADV: positions, fields and rules** | Position | Field | Length | Type | M/R/O | Description | | --- | --- | --- | --- | --- | --- | | 1 | **Record Type Code** | 1 char | Code Always 8 | Mandatory | Identifies the type of record in the file. • Always "8" for the Company/Batch Control Record | | 2–4 | **Service Class Code** | 3 chars | Code [See codes](https://nacha-navigator.com/nacha-file-format#service-class-codes) | Mandatory | Identifies whether the batch contains debits, credits or both. • Must match the Service Class Code in the Company/Batch Header Record | | 5–10 | **Entry/Addenda Count** | 6 chars | Numeric | Mandatory | The number of Entry Detail and Addenda Records in the batch. • Counts every type 6 and type 7 record in the batch • Right-justified and zero-filled | | 11–20 | **Entry Hash** | 10 chars | Numeric | Mandatory | Sum of the 8-digit Receiving DFI Identifications (positions 4–11) of every entry in the batch. • If the sum has more than 10 digits, only the rightmost 10 are kept • Right-justified and zero-filled | | 21–40 | **Total Debit Entry Dollar Amount** | 20 chars | Amount Cents, no decimal point | Mandatory | Total of all debit advices in the batch, in cents. • 20 digits, in cents, zero-filled | | 41–60 | **Total Credit Entry Dollar Amount** | 20 chars | Amount Cents, no decimal point | Mandatory | Total of all credit advices in the batch, in cents. • 20 digits, in cents, zero-filled | | 61–79 | **ACH Operator Data** | 19 chars | Alphanumeric | Optional | For use by the ACH Operator that prepared the advice file. • Left-justified and space-filled | | 80–87 | **Originating DFI Identification** | 8 chars | Routing TTTTAAAA | Mandatory | First 8 digits of the routing number of the ODFI. • Must match the ODFI in the Company/Batch Header Record | | 88–94 | **Batch Number** | 7 chars | Numeric | Mandatory | The number of the batch this record closes. • Must match the Batch Number in the Company/Batch Header Record • Right-justified and zero-filled | ## File Control Record Contains the counts, hash totals, and total dollar amounts for all batches in the file. **File Control Record: positions, fields and rules** | Position | Field | Length | Type | M/R/O | Description | | --- | --- | --- | --- | --- | --- | | 1 | **Record Type Code** | 1 char | Code Always 9 | Mandatory | Identifies the type of record in the file. • Always "9" for the File Control Record | | 2–7 | **Batch Count** | 6 chars | Numeric | Mandatory | The number of batches (Company/Batch Header Records) in the file. • Right-justified and zero-filled | | 8–13 | **Block Count** | 6 chars | Numeric | Mandatory | The number of 10-record blocks in the file, counting the File Header, File Control and block-fill records. • Equals the total number of records divided by 10 • Right-justified and zero-filled | | 14–21 | **Entry/Addenda Count** | 8 chars | Numeric | Mandatory | The total number of Entry Detail and Addenda Records in the file. • Equals the sum of the Entry/Addenda Count fields of all Batch Control Records • Right-justified and zero-filled | | 22–31 | **Entry Hash** | 10 chars | Numeric | Mandatory | Sum of the Entry Hash fields of all Company/Batch Control Records in the file. • If the sum has more than 10 digits, only the rightmost 10 are kept • Right-justified and zero-filled | | 32–43 | **Total Debit Entry Dollar Amount in File** | 12 chars | Amount Cents, no decimal point | Mandatory | Total of all debit entries in the file, in cents. • Sum of the Total Debit Entry Dollar Amount fields of all Batch Control Records • In cents, with no decimal point; zero-filled | | 44–55 | **Total Credit Entry Dollar Amount in File** | 12 chars | Amount Cents, no decimal point | Mandatory | Total of all credit entries in the file, in cents. • Sum of the Total Credit Entry Dollar Amount fields of all Batch Control Records • In cents, with no decimal point; zero-filled | | 56–94 | **Reserved** | 39 chars | Alphanumeric | Not applicable: reserved, or filled in by the ACH Operator | Reserved for future use. Leave blank. • Space-filled | ### Accounting advice (ADV) files #### ADV: Automated Accounting Advices 8 fields File Control Record of an ADV file prepared by an ACH Operator; dollar totals are 20 digits long. **File Control Record — ADV: positions, fields and rules** | Position | Field | Length | Type | M/R/O | Description | | --- | --- | --- | --- | --- | --- | | 1 | **Record Type Code** | 1 char | Code Always 9 | Mandatory | Identifies the type of record in the file. • Always "9" for the File Control Record | | 2–7 | **Batch Count** | 6 chars | Numeric | Mandatory | The number of batches (Company/Batch Header Records) in the file. • Right-justified and zero-filled | | 8–13 | **Block Count** | 6 chars | Numeric | Mandatory | The number of 10-record blocks in the file, counting the File Header, File Control and block-fill records. • Equals the total number of records divided by 10 • Right-justified and zero-filled | | 14–21 | **Entry/Addenda Count** | 8 chars | Numeric | Mandatory | The total number of Entry Detail and Addenda Records in the file. • Equals the sum of the Entry/Addenda Count fields of all Batch Control Records • Right-justified and zero-filled | | 22–31 | **Entry Hash** | 10 chars | Numeric | Mandatory | Sum of the Entry Hash fields of all Company/Batch Control Records in the file. • If the sum has more than 10 digits, only the rightmost 10 are kept • Right-justified and zero-filled | | 32–51 | **Total Debit Entry Dollar Amount in File** | 20 chars | Amount Cents, no decimal point | Mandatory | Total of all debit advices in the file, in cents. • 20 digits, in cents, zero-filled | | 52–71 | **Total Credit Entry Dollar Amount in File** | 20 chars | Amount Cents, no decimal point | Mandatory | Total of all credit advices in the file, in cents. • 20 digits, in cents, zero-filled | | 72–94 | **Reserved** | 23 chars | Alphanumeric | Not applicable: reserved, or filled in by the ACH Operator | Reserved for future use. Leave blank. • Space-filled | ## Block-fill records A file’s record count must be a multiple of 10 (the blocking factor in the File Header). When it isn’t, records of 94 nines follow the File Control to fill the last block. They carry no data, and the File Control’s block count includes them. `9999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999` Code tables ## The codes, decoded The values that go in the code fields above, from the same tables the viewer uses to explain a file. Every code row can be linked to directly: [#return-r01](https://nacha-navigator.com/nacha-file-format#return-r01) goes to R01. ### Transaction codes Entry Detail: positions 2–3. The first digit is the account type; the second says whether it is a credit (1–4) or a debit (5–9), and whether it is live, a prenote, zero-dollar or a return. [ACH transaction codes](https://nacha-navigator.com/ach-transaction-codes) explains how the digits combine, with prenotes, returns and the codes a reversal flips. | Code | Meaning | Account | Direction | | --- | --- | --- | --- | | 21 | Return or NOC of a checking credit (original code 22, 23 or 24) | Checking | Credit | | 22 | Checking credit (deposit) | Checking | Credit | | 23 | Prenote: checking credit (also DNE and ENR non-dollar entries) | Checking | Credit | | 24 | Zero-dollar checking credit with remittance data (CCD, CTX, IAT); ACK and ATX acknowledgments | Checking | Credit | | 26 | Return or NOC of a checking debit (original code 27, 28 or 29) | Checking | Debit | | 27 | Checking debit (payment) | Checking | Debit | | 28 | Prenote: checking debit | Checking | Debit | | 29 | Zero-dollar checking debit with remittance data (CCD, CTX, IAT) | Checking | Debit | | 31 | Return or NOC of a savings credit (original code 32, 33 or 34) | Savings | Credit | | 32 | Savings credit (deposit) | Savings | Credit | | 33 | Prenote: savings credit (also DNE and ENR non-dollar entries) | Savings | Credit | | 34 | Zero-dollar savings credit with remittance data (CCD, CTX, IAT); ACK and ATX acknowledgments | Savings | Credit | | 36 | Return or NOC of a savings debit (original code 37, 38 or 39) | Savings | Debit | | 37 | Savings debit (payment) | Savings | Debit | | 38 | Prenote: savings debit | Savings | Debit | | 39 | Zero-dollar savings debit with remittance data (CCD, CTX, IAT) | Savings | Debit | | 41 | Return or NOC of a general ledger credit (original code 42, 43 or 44) | General ledger | Credit | | 42 | General ledger credit (deposit) | General ledger | Credit | | 43 | Prenote: general ledger credit | General ledger | Credit | | 44 | Zero-dollar general ledger credit with remittance data (CCD, CTX) | General ledger | Credit | | 46 | Return or NOC of a general ledger debit (original code 47, 48 or 49) | General ledger | Debit | | 47 | General ledger debit (payment) | General ledger | Debit | | 48 | Prenote: general ledger debit | General ledger | Debit | | 49 | Zero-dollar general ledger debit with remittance data (CCD, CTX) | General ledger | Debit | | 51 | Return or NOC of a loan credit (original code 52, 53 or 54) | Loan | Credit | | 52 | Loan account credit (deposit to a loan) | Loan | Credit | | 53 | Prenote: loan credit | Loan | Credit | | 54 | Zero-dollar loan credit with remittance data (CCD, CTX) | Loan | Credit | | 55 | Loan account debit (reversals only) | Loan | Debit | | 56 | Return or NOC of a loan debit (original code 55) | Loan | Debit | | 81 | ADV: credit for ACH debits originated | Accounting (ADV) | Credit | | 82 | ADV: debit for ACH credits originated | Accounting (ADV) | Debit | | 83 | ADV: credit for ACH credits received | Accounting (ADV) | Credit | | 84 | ADV: debit for ACH debits received | Accounting (ADV) | Debit | | 85 | ADV: credit for ACH credits in rejected batches | Accounting (ADV) | Credit | | 86 | ADV: debit for ACH debits in rejected batches | Accounting (ADV) | Debit | | 87 | ADV: summary credit for respondent ACH activity | Accounting (ADV) | Credit | | 88 | ADV: summary debit for respondent ACH activity | Accounting (ADV) | Debit | ### Standard Entry Class (SEC) codes Company/Batch Header: positions 51–53. The SEC code decides the Entry Detail layout and which addenda an entry may carry. | SEC | Name | Used for | Moves | Addenda | | --- | --- | --- | --- | --- | | [ACK on PayOps Kit](https://payopskit.com/sec-codes/ack) | ACH Payment Acknowledgment | Zero-dollar acknowledgment of a CCD credit, sent by the RDFI. | Zero-dollar | Up to 1 (type 05) | | [ADV on PayOps Kit](https://payopskit.com/sec-codes/adv) | Automated Accounting Advice | Non-monetary accounting information an ACH Operator sends to a DFI that asked for it (Service Class Code 280). | Accounting advice (non-monetary) | None | | [ARC on PayOps Kit](https://payopskit.com/sec-codes/arc) | Accounts Receivable Entry | One-time debit converted from an eligible check received by mail or delivery service, at a dropbox, or in person to pay a bill at a staffed location. | Debits | None | | [ATX on PayOps Kit](https://payopskit.com/sec-codes/atx) | Financial EDI Acknowledgment | Zero-dollar acknowledgment of a CTX credit, sent by the RDFI. | Zero-dollar | Up to 9,999 (type 05) | | [BOC on PayOps Kit](https://payopskit.com/sec-codes/boc) | Back Office Conversion Entry | One-time debit converted in the back office from an eligible check presented at a point of purchase or a staffed bill-payment location. | Debits | None | | [CCD on PayOps Kit](https://payopskit.com/sec-codes/ccd) | Corporate Credit or Debit Entry | Credit or debit between business accounts. | Credits and debits | Up to 1 (type 05) | | [CIE on PayOps Kit](https://payopskit.com/sec-codes/cie) | Customer Initiated Entry | Credit initiated by a consumer, such as an online bill payment. | Credits | Up to 1 (type 05) | | [COR on PayOps Kit](https://payopskit.com/sec-codes/cor) | Notification of Change or Refused Notification of Change | Zero-dollar entry correcting information in an earlier entry. | Zero-dollar | 1 required (type 98) | | [CTX on PayOps Kit](https://payopskit.com/sec-codes/ctx) | Corporate Trade Exchange | Business-to-business payment with up to 9,999 addenda of EDI remittance data. | Credits and debits | Up to 9,999 (type 05) | | [DNE on PayOps Kit](https://payopskit.com/sec-codes/dne) | Death Notification Entry | Zero-dollar notice from a Federal Government agency that a benefit recipient has died. | Zero-dollar | 1 required (type 05) | | [ENR on PayOps Kit](https://payopskit.com/sec-codes/enr) | Automated Enrollment Entry | Zero-dollar entry enrolling a beneficiary in Federal Government direct deposit. | Zero-dollar | 1 to 9,999 (type 05) | | [IAT on PayOps Kit](https://payopskit.com/sec-codes/iat) | International ACH Transaction | Entry involving a financial agency outside the United States. | Credits and debits | 7 to 14 (type 10–18) | | [MTE on PayOps Kit](https://payopskit.com/sec-codes/mte) | Machine Transfer Entry | Entry initiated at an ATM or other electronic terminal. | Credits and debits | 1 required (type 02) | | [POP on PayOps Kit](https://payopskit.com/sec-codes/pop) | Point-of-Purchase Entry | One-time debit converted on the spot from an eligible check presented at a point of purchase or a staffed bill-payment location. | Debits | None | | [POS on PayOps Kit](https://payopskit.com/sec-codes/pos) | Point-of-Sale Entry | Consumer debit at an electronic terminal to pay for a purchase or withdraw cash, and related adjusting or other credits. | Credits and debits | 1 required (type 02) | | [PPD on PayOps Kit](https://payopskit.com/sec-codes/ppd) | Prearranged Payment and Deposit Entry | Consumer credit or debit authorized in advance, once or recurring, e.g. payroll direct deposit or a recurring bill. | Credits and debits | Up to 1 (type 05) | | [RCK on PayOps Kit](https://payopskit.com/sec-codes/rck) | Re-presented Check Entry | Returned check re-presented as a debit. | Debits | None | | [SHR on PayOps Kit](https://payopskit.com/sec-codes/shr) | Shared Network Transaction | Consumer debit at a point-of-sale terminal in a shared network where the ODFI and RDFI have an agreement beyond the Rules, and related credits. | Credits and debits | 1 required (type 02) | | [TEL on PayOps Kit](https://payopskit.com/sec-codes/tel) | Telephone-Initiated Entry | Consumer debit authorized orally over the telephone. | Debits | None | | [TRC on PayOps Kit](https://payopskit.com/sec-codes/trc) | Check Truncation Entry | Debit for one check truncated (kept by the collecting bank) under a check truncation program. | Debits | None | | [TRX on PayOps Kit](https://payopskit.com/sec-codes/trx) | Check Truncation Entries Exchange | Debit for several truncated checks drawn on the same paying bank, listed in addenda records. | Debits | Up to 9,999 (type 05) | | [WEB on PayOps Kit](https://payopskit.com/sec-codes/web) | Internet-Initiated/Mobile Entry | Consumer debit authorized online or on a mobile device, or a person-to-person credit. | Credits and debits | Up to 1 (type 05) | | [XCK on PayOps Kit](https://payopskit.com/sec-codes/xck) | Destroyed Check Entry | Debit collecting an eligible check that was lost or destroyed, or damaged so it cannot be processed; the batch description is NO CHECK. | Debits | None | ### Service class codes Company/Batch Header: positions 2–4; Company/Batch Control: positions 2–4. Whether a batch holds credits, debits or both. | Code | Meaning | | --- | --- | | 200 | ACH entries mixed debits and credits | | 220 | ACH credits only | | 225 | ACH debits only | | 280 | ACH automated accounting advices (ADV) | ### Return reason codes Addenda (type 99): positions 4–6, 57–58 and 77–78. Why an RDFI returned an entry, plus the dishonored and contested return codes. R90 can be used from March 17, 2028; until then, a return made on an OFAC instruction uses R16. | Code | Reason | Note | | --- | --- | --- | | [R01 on PayOps Kit](https://payopskit.com/ach-return-codes/r01) | Insufficient Funds | | | [R02 on PayOps Kit](https://payopskit.com/ach-return-codes/r02) | Account Closed | | | [R03 on PayOps Kit](https://payopskit.com/ach-return-codes/r03) | No Account/Unable to Locate Account | | | [R04 on PayOps Kit](https://payopskit.com/ach-return-codes/r04) | Invalid Account Number Structure | | | [R05 on PayOps Kit](https://payopskit.com/ach-return-codes/r05) | Unauthorized Debit to Consumer Account Using Corporate SEC Code | | | [R06 on PayOps Kit](https://payopskit.com/ach-return-codes/r06) | Returned per ODFI's Request | | | [R07 on PayOps Kit](https://payopskit.com/ach-return-codes/r07) | Authorization Revoked by Customer | | | [R08 on PayOps Kit](https://payopskit.com/ach-return-codes/r08) | Payment Stopped | | | [R09 on PayOps Kit](https://payopskit.com/ach-return-codes/r09) | Uncollected Funds | | | [R10 on PayOps Kit](https://payopskit.com/ach-return-codes/r10) | Customer Advises Originator is Not Known to Receiver and/or Originator is Not Authorized by Receiver to Debit Receiver's Account | | | [R11 on PayOps Kit](https://payopskit.com/ach-return-codes/r11) | Customer Advises Entry Not in Accordance with the Terms of the Authorization | | | [R12 on PayOps Kit](https://payopskit.com/ach-return-codes/r12) | Account Sold to Another DFI | | | [R13 on PayOps Kit](https://payopskit.com/ach-return-codes/r13) | Invalid ACH Routing Number | | | [R14 on PayOps Kit](https://payopskit.com/ach-return-codes/r14) | Representative Payee Deceased or Unable to Continue in That Capacity | | | [R15 on PayOps Kit](https://payopskit.com/ach-return-codes/r15) | Beneficiary or Account Holder (Other Than a Representative Payee) Deceased | | | [R16 on PayOps Kit](https://payopskit.com/ach-return-codes/r16) | Account Frozen/Entry Returned per OFAC Instruction | Becomes "Account Frozen" on March 17, 2028; sanctions returns move to R90 | | [R17 on PayOps Kit](https://payopskit.com/ach-return-codes/r17) | File Record Edit Criteria/Entry Initiated Under Questionable Circumstances/Return of Improperly-Initiated Reversal | Since October 1, 2024 also for an entry the RDFI believes fraudulent, with QUESTIONABLE in the first 12 positions of the addenda information | | [R18 on PayOps Kit](https://payopskit.com/ach-return-codes/r18) | Improper Effective Entry Date | | | [R19 on PayOps Kit](https://payopskit.com/ach-return-codes/r19) | Amount Field Error | | | [R20 on PayOps Kit](https://payopskit.com/ach-return-codes/r20) | Non-Transaction Account | | | [R21 on PayOps Kit](https://payopskit.com/ach-return-codes/r21) | Invalid Company Identification | | | [R22 on PayOps Kit](https://payopskit.com/ach-return-codes/r22) | Invalid Individual ID Number | | | [R23 on PayOps Kit](https://payopskit.com/ach-return-codes/r23) | Credit Entry Refused by Receiver | | | [R24 on PayOps Kit](https://payopskit.com/ach-return-codes/r24) | Duplicate Entry | | | [R25 on PayOps Kit](https://payopskit.com/ach-return-codes/r25) | Addenda Error | | | [R26 on PayOps Kit](https://payopskit.com/ach-return-codes/r26) | Mandatory Field Error | | | [R27 on PayOps Kit](https://payopskit.com/ach-return-codes/r27) | Trace Number Error | | | [R28 on PayOps Kit](https://payopskit.com/ach-return-codes/r28) | Routing Number Check Digit Error | | | [R29 on PayOps Kit](https://payopskit.com/ach-return-codes/r29) | Corporate Customer Advises Not Authorized | | | [R30 on PayOps Kit](https://payopskit.com/ach-return-codes/r30) | RDFI Not Participant in Check Truncation Program | | | [R31 on PayOps Kit](https://payopskit.com/ach-return-codes/r31) | Permissible Return Entry | CCD and CTX only | | [R32 on PayOps Kit](https://payopskit.com/ach-return-codes/r32) | RDFI Non-Settlement | | | [R33 on PayOps Kit](https://payopskit.com/ach-return-codes/r33) | Return of XCK Entry | | | [R34 on PayOps Kit](https://payopskit.com/ach-return-codes/r34) | Limited Participation DFI | | | [R35 on PayOps Kit](https://payopskit.com/ach-return-codes/r35) | Return of Improper Debit Entry | | | [R36 on PayOps Kit](https://payopskit.com/ach-return-codes/r36) | Return of Improper Credit Entry | | | [R37 on PayOps Kit](https://payopskit.com/ach-return-codes/r37) | Source Document Presented for Payment | | | [R38 on PayOps Kit](https://payopskit.com/ach-return-codes/r38) | Stop Payment on Source Document | | | [R39 on PayOps Kit](https://payopskit.com/ach-return-codes/r39) | Improper Source Document/Source Document Presented for Payment | | | [R40 on PayOps Kit](https://payopskit.com/ach-return-codes/r40) | Return of ENR Entry by Federal Government Agency | ENR only | | [R41 on PayOps Kit](https://payopskit.com/ach-return-codes/r41) | Invalid Transaction Code | ENR only | | [R42 on PayOps Kit](https://payopskit.com/ach-return-codes/r42) | Routing Number/Check Digit Error | ENR only | | [R43 on PayOps Kit](https://payopskit.com/ach-return-codes/r43) | Invalid DFI Account Number | ENR only | | [R44 on PayOps Kit](https://payopskit.com/ach-return-codes/r44) | Invalid Individual ID Number/Identification Number | ENR only | | [R45 on PayOps Kit](https://payopskit.com/ach-return-codes/r45) | Invalid Individual Name/Company Name | ENR only | | [R46 on PayOps Kit](https://payopskit.com/ach-return-codes/r46) | Invalid Representative Payee Indicator | ENR only | | [R47 on PayOps Kit](https://payopskit.com/ach-return-codes/r47) | Duplicate Enrollment | ENR only | | [R50 on PayOps Kit](https://payopskit.com/ach-return-codes/r50) | State Law Affecting RCK Acceptance | | | [R51 on PayOps Kit](https://payopskit.com/ach-return-codes/r51) | Item Related to RCK Entry is Ineligible or RCK Entry is Improper | | | [R52 on PayOps Kit](https://payopskit.com/ach-return-codes/r52) | Stop Payment on Item Related to RCK Entry | | | [R53 on PayOps Kit](https://payopskit.com/ach-return-codes/r53) | Item and RCK Entry Presented for Payment | | | [R61 on PayOps Kit](https://payopskit.com/ach-return-codes/r61) | Misrouted Return | Dishonored return (sent by the ODFI) | | [R62 on PayOps Kit](https://payopskit.com/ach-return-codes/r62) | Return of Erroneous or Reversing Debit | Dishonored return (sent by the ODFI) | | [R67 on PayOps Kit](https://payopskit.com/ach-return-codes/r67) | Duplicate Return | Dishonored return (sent by the ODFI) | | [R68 on PayOps Kit](https://payopskit.com/ach-return-codes/r68) | Untimely Return | Dishonored return (sent by the ODFI) | | [R69 on PayOps Kit](https://payopskit.com/ach-return-codes/r69) | Field Error(s) | Dishonored return (sent by the ODFI) | | [R70 on PayOps Kit](https://payopskit.com/ach-return-codes/r70) | Permissible Return Entry Not Accepted/Return Not Requested by ODFI | Dishonored return (sent by the ODFI) | | [R71 on PayOps Kit](https://payopskit.com/ach-return-codes/r71) | Misrouted Dishonored Return | Contested dishonored return (sent by the RDFI) | | [R72 on PayOps Kit](https://payopskit.com/ach-return-codes/r72) | Untimely Dishonored Return | Contested dishonored return (sent by the RDFI) | | [R73 on PayOps Kit](https://payopskit.com/ach-return-codes/r73) | Timely Original Return | Contested dishonored return (sent by the RDFI) | | [R74 on PayOps Kit](https://payopskit.com/ach-return-codes/r74) | Corrected Return | Contested dishonored return (sent by the RDFI) | | [R75 on PayOps Kit](https://payopskit.com/ach-return-codes/r75) | Return Not a Duplicate | Contested dishonored return (sent by the RDFI) | | [R76 on PayOps Kit](https://payopskit.com/ach-return-codes/r76) | No Errors Found | Contested dishonored return (sent by the RDFI) | | [R77 on PayOps Kit](https://payopskit.com/ach-return-codes/r77) | Non-Acceptance of R62 Dishonored Return | Contested dishonored return (sent by the RDFI) | | [R80 on PayOps Kit](https://payopskit.com/ach-return-codes/r80) | IAT Entry Coding Error | IAT only | | [R81 on PayOps Kit](https://payopskit.com/ach-return-codes/r81) | Non-Participant in IAT Program | IAT only | | [R82 on PayOps Kit](https://payopskit.com/ach-return-codes/r82) | Invalid Foreign Receiving DFI Identification | IAT only | | [R83 on PayOps Kit](https://payopskit.com/ach-return-codes/r83) | Foreign Receiving DFI Unable to Settle | IAT only | | [R84 on PayOps Kit](https://payopskit.com/ach-return-codes/r84) | Entry Not Processed by Gateway | IAT only | | [R85 on PayOps Kit](https://payopskit.com/ach-return-codes/r85) | Incorrectly Coded Outbound International Payment | Gateway; a non-IAT entry that should have been IAT | | [R90 on PayOps Kit](https://payopskit.com/ach-return-codes/r90) | Entry Returned Due to RDFI's Sanctions Compliance Obligations | Effective March 17, 2028 | ### Change codes (notifications of change) Addenda (type 98): positions 4–6 and 65–67. What an RDFI is correcting, and how the corrected data is laid out. | Code | Change | Corrected data | | --- | --- | --- | | [C01 on PayOps Kit](https://payopskit.com/noc-codes/c01) | Incorrect DFI Account Number | Correct DFI Account Number in the first 17 positions | | [C02 on PayOps Kit](https://payopskit.com/noc-codes/c02) | Incorrect Routing Number | Correct routing number (9 digits, with check digit) in the first 9 positions | | [C03 on PayOps Kit](https://payopskit.com/noc-codes/c03) | Incorrect Routing Number and Incorrect DFI Account Number | Correct routing number (9), three blanks, then the correct DFI Account Number (17) | | [C05 on PayOps Kit](https://payopskit.com/noc-codes/c05) | Incorrect Transaction Code | Correct Transaction Code in the first 2 positions | | [C06 on PayOps Kit](https://payopskit.com/noc-codes/c06) | Incorrect DFI Account Number and Incorrect Transaction Code | Correct DFI Account Number in positions 1–17, three blanks (18–20), then the correct Transaction Code in 21–22 | | [C07 on PayOps Kit](https://payopskit.com/noc-codes/c07) | Incorrect Routing Number, Incorrect DFI Account Number, and Incorrect Transaction Code | Correct routing number (9), DFI Account Number (17) and Transaction Code (2) | | [C08 on PayOps Kit](https://payopskit.com/noc-codes/c08) | Incorrect Receiving DFI Identification (IAT only) | Correct Receiving DFI Identification. Published tables say it fills the first 34 positions, more than this 29-character field holds | | [C09 on PayOps Kit](https://payopskit.com/noc-codes/c09) | Incorrect Individual Identification Number/Incorrect Receiver Identification Number | Correct Individual Identification Number or Receiver Identification Number in the first 22 positions | | [C13 on PayOps Kit](https://payopskit.com/noc-codes/c13) | Addenda Format Error | No fixed layout: the code reports addenda information that was unclear or badly formatted | | [C14 on PayOps Kit](https://payopskit.com/noc-codes/c14) | Incorrect SEC Code for Outbound International Payment | "IAT" in the first 3 positions | | [C61 on PayOps Kit](https://payopskit.com/noc-codes/c61) | Misrouted Notification of Change | Refused NOC: sent back by the ODFI | | [C62 on PayOps Kit](https://payopskit.com/noc-codes/c62) | Incorrect Trace Number | Refused NOC: sent back by the ODFI | | [C63 on PayOps Kit](https://payopskit.com/noc-codes/c63) | Incorrect Company Identification Number | Refused NOC: sent back by the ODFI | | [C64 on PayOps Kit](https://payopskit.com/noc-codes/c64) | Incorrect Individual Identification Number/Identification Number | Refused NOC: sent back by the ODFI | | [C65 on PayOps Kit](https://payopskit.com/noc-codes/c65) | Incorrectly Formatted Corrected Data | Refused NOC: sent back by the ODFI | | [C66 on PayOps Kit](https://payopskit.com/noc-codes/c66) | Incorrect Discretionary Data | Refused NOC: sent back by the ODFI | | [C67 on PayOps Kit](https://payopskit.com/noc-codes/c67) | Routing Number Not From Original Entry Detail Record | Refused NOC: sent back by the ODFI | | [C68 on PayOps Kit](https://payopskit.com/noc-codes/c68) | DFI Account Number Not From Original Entry Detail Record | Refused NOC: sent back by the ODFI | | [C69 on PayOps Kit](https://payopskit.com/noc-codes/c69) | Incorrect Transaction Code | Refused NOC: sent back by the ODFI | #### Retired change codes No longer in the Nacha Rules, so a new NOC may not use them. An old file can still carry one: the NACHA Viewer decodes it and [reports it as retired](https://nacha-navigator.com/nacha-file-errors#ad-change-code). | Code | Former title | Status | | --- | --- | --- | | C04 | Incorrect Individual Name/Receiving Company Name | Removed from the Nacha Rules | | C10 | Incorrect Company Name | Removed from the Nacha Rules in 2003 | | C11 | Incorrect Company Identification | Removed from the Nacha Rules in 2003 | | C12 | Incorrect Company Name and Company Identification | Removed from the Nacha Rules in 2003 | ### Addenda type codes Addenda: positions 2–3. Each type has its own layout, listed under Addenda Record above. | Code | Meaning | | --- | --- | | 02 | Point-of-sale terminal information (POS, SHR, MTE) | | 05 | Payment related information | | 10 | IAT: transaction type, foreign amount and receiver name | | 11 | IAT: originator name and street address | | 12 | IAT: originator city, state, country and postal code | | 13 | IAT: originating DFI name, identification and branch country | | 14 | IAT: receiving DFI name, identification and branch country | | 15 | IAT: receiver identification number and street address | | 16 | IAT: receiver city, state, country and postal code | | 17 | IAT: payment related information (optional) | | 18 | IAT: foreign correspondent bank (optional) | | 98 | Notification of Change or refused Notification of Change | | 99 | Return, dishonored return or contested dishonored return | ### Other codes Smaller code lists used by specific fields and entry types. #### Originator status codes Company/Batch Header: position 79 | Code | Meaning | | --- | --- | | 0 | ADV file prepared by an ACH Operator | | 1 | Depository financial institution bound by the Nacha Rules | | 2 | Federal Government entity or agency not subject to the Nacha Rules | #### Addenda record indicator Entry Detail: position 79 | Code | Meaning | | --- | --- | | 0 | No addenda record follows | | 1 | One or more addenda records follow | #### Payment type codes (optional) Entry Detail (WEB, TEL): positions 77–78 | Code | Meaning | | --- | --- | | R | Recurring | | S | Single entry | #### Card transaction type codes Entry Detail (POS, SHR): positions 77–78 | Code | Meaning | | --- | --- | | 01 | Purchase of goods or services | | 02 | Cash | | 03 | Return reversal | | 11 | Purchase reversal | | 12 | Cash reversal | | 13 | Return | | 21 | Adjustment | | 99 | Miscellaneous transaction | #### IAT transaction type codes Addenda (type 10): positions 4–6 | Code | Meaning | | --- | --- | | ANN | Annuity | | BUS | Business/Commercial | | DEP | Deposit | | LOA | Loan | | MIS | Miscellaneous | | MOR | Mortgage | | PEN | Pension | | REM | Remittance | | RLS | Rent/Lease | | SAL | Salary/Payroll | | TAX | Tax | | ARC | Accounts Receivable Check | | BOC | Back Office Conversion | | MTE | Machine Transfer Entry | | POP | Point-of-Purchase | | POS | Point-of-Sale | | RCK | Re-presented Check | | SHR | Shared Network Transaction | | TEL | Telephone-Initiated | | WEB | Internet-Initiated/Mobile | #### Foreign exchange indicators Company/Batch Header (IAT): positions 21–22 | Code | Meaning | | --- | --- | | FV | Fixed-to-variable: originated as a fixed amount, received after currency conversion | | VF | Variable-to-fixed: converted at a rate so that a fixed amount is received | | FF | Fixed-to-fixed: same currency at both ends, no conversion | #### Foreign exchange reference indicators Company/Batch Header (IAT): position 23 | Code | Meaning | | --- | --- | | 1 | Foreign exchange rate | | 2 | Foreign exchange reference number | | 3 | Space-filled (no reference) | #### ID number qualifiers Addenda (type 13, type 14, type 18): positions 39–40 | Code | Meaning | | --- | --- | | 01 | National clearing system number | | 02 | BIC code | | 03 | IBAN code (deleted from March 19, 2027) | #### OFAC screening indicators Entry Detail (IAT): positions 77 and 78 | Code | Meaning | | --- | --- | | 0 | Not flagged by OFAC screening | | 1 | Flagged as a possible OFAC match | ## The official rules This reference follows the record formats in the Nacha Operating Rules. Nacha publishes the rules and updates them every year; check the current edition before you build or certify a file. NACHA Navigator is independent and not affiliated with or endorsed by Nacha, and this page is general information, not legal or compliance advice. [Nacha Operating Rules](https://www.nacha.org/rules) [Open the NACHA Viewer](https://nacha-navigator.com/) --- URL: https://nacha-navigator.com/nacha-file-errors # Why NACHA files get rejected Reference The 94 checks the NACHA Viewer runs on an ACH file, grouped by record: what each one looks for and how to fix what it finds, with worked examples for five common problems. Last updated October 30, 2026 [Check a file in the NACHA Viewer](https://nacha-navigator.com/) [NACHA file format](https://nacha-navigator.com/nacha-file-format) The viewer reads the file in your browser. It is never uploaded. ## Errors, warnings and notes The viewer sorts what it finds by severity. Only errors make a file invalid: a file with warnings or notes but no errors passes. Every finding names its rule, such as `BC_ENTRY_HASH`, and most also give the line and positions where it was found. | Severity | What it means | Checks | | --- | --- | --- | | Error | The file breaks a rule of the NACHA format. The ACH Operator or your bank can reject the file, a batch or an entry for it, so fix every error before you send the file. | 70 | | Warning | Not always fatal, but worth fixing: some banks refuse it, the Receiver’s bank may return the entry, or it points to a likely mistake. Review each one. | 19 | | Note (info) | Worth knowing and usually fine, such as an Immediate Origin that is a company identifier rather than a routing number. Change it only if it isn’t what you meant. | 5 | Worked examples ## Five common rejections, worked through These are the problems behind many rejected files: totals and counts that don’t add up, records of the wrong length, and a File Header that doesn’t name the bank the way the format expects. ### Entry hash mismatch Every Company/Batch Control carries an Entry Hash in positions 11–20, and the File Control carries one for the whole file in positions 22–31. It is not a cryptographic hash, just a sum: the receiving system recomputes it to make sure no entry was lost or changed on the way. To compute it, take the Receiving DFI Identification of each Entry Detail record: positions 4–11, the first 8 digits of the routing number, without the check digit in position 12. Add them up and keep the rightmost 10 digits of the total, padded with zeros. Every entry counts, prenotes and zero-dollar entries included; addenda records don’t. Here is batch 1 of the sample file [sample-ppd.ach](https://nacha-navigator.com/samples/nacha/sample-ppd.ach): | Line | Transaction code | RDFI identification (4–11) | Check digit (12) | | --- | --- | --- | --- | | 3 | 22 | 06550334 | 8 | | 4 | 33 | 26557758 | 5 | | 5 | 23 | 06550334 | 8 | | 6 | 23 | 06550368 | 1 | | Sum | | 46,208,794 | | The sum has fewer than 10 digits, so the Entry Hash is `0046208794`, which is what the Batch Control on line 7 says in positions 11–20: ``` 820000000400462087940000000000000000000000109123456789 065503680000001 ``` The File Control adds up every entry in the file, which is the same as adding the batch hashes: 0046208794 + 0090954322 = `0137163116`. When a sum runs past 10 digits, the digits on the left are dropped: a sum of 12,345,678,901 gives an Entry Hash of `2345678901`. Common mistakes - Adding whole 9-digit routing numbers, check digits included. - Leaving entries out: credits, debits, prenotes and zero-dollar entries all count. - Copying the File Control’s hash into a Batch Control, or adding up batch hashes that are themselves wrong. - Keeping the leftmost 10 digits, or rounding, when the sum is longer than 10 digits. The NACHA Viewer shows the hash it expects next to the one in the file. Reported as [BC_ENTRY_HASH](https://nacha-navigator.com/nacha-file-errors#bc-entry-hash) [FC_ENTRY_HASH](https://nacha-navigator.com/nacha-file-errors#fc-entry-hash) ### Record count and block fill NACHA files are written in blocks of 10 records, and the File Header’s Blocking Factor (positions 38–39) is always 10. When the records from the File Header through the File Control don’t fill the last block, the file ends with block-fill records, each one 94 nines, to complete it. The File Control’s Block Count (positions 8–13) is the number of blocks, block fill included. | Records, File Header to File Control | Block-fill records | Lines in the file | Block Count | | --- | --- | --- | --- | | 8 | 2 | 10 | 000001 | | 14 | 6 | 20 | 000002 | | 30 | 0 | 30 | 000003 | | 41 | 9 | 50 | 000005 | The sample file [sample-ppd.ach](https://nacha-navigator.com/samples/nacha/sample-ppd.ach) is the second row: 14 records (a File Header, two batches of four entries with their header and control, and a File Control), then six lines of nines. Don’t confuse the Block Count with the Entry/Addenda Count in positions 14–21, which counts only Entry Detail and Addenda records. ``` 9999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 ``` Common mistakes - Padding with blank lines or spaces instead of lines of nines. - Putting block fill before the File Control instead of after it. - Adding a whole block of nines to a file whose record count is already a multiple of 10. - A Block Count that leaves out the block fill, or counts lines instead of blocks of 10. The viewer reports missing or extra block fill as a warning, and a wrong Block Count as an error. Reported as [FC_BLOCK_COUNT](https://nacha-navigator.com/nacha-file-errors#fc-block-count) [BLOCK_FILL_MISSING](https://nacha-navigator.com/nacha-file-errors#block-fill-missing) [BLOCK_FILL_EXCESS](https://nacha-navigator.com/nacha-file-errors#block-fill-excess) [FILLER_BEFORE_FILE_CONTROL](https://nacha-navigator.com/nacha-file-errors#filler-before-file-control) [FH_BLOCKING_FACTOR](https://nacha-navigator.com/nacha-file-errors#fh-blocking-factor) ### Records that aren’t 94 characters Every record is exactly 94 characters long, not counting the line break, and the File Header says so in its Record Size field (094, positions 35–37). Fields are found by their position, so in a record of any other length every field after the difference is read wrong. The usual cause is software that trims spaces. Many records end in blank fields (the File Control’s last 39 positions are reserved and always blank), and an editor, spreadsheet or email program that drops trailing spaces leaves those records short. Line 12 of the sample file [sample-with-errors.ach](https://nacha-navigator.com/samples/nacha/sample-with-errors.ach) is a File Control cut to 55 characters: ``` 9000001000002000000060104054990000000007500000000484000 ``` Positions 56–94 are missing, and all of them are blank in a File Control, so padding the line with 39 spaces restores it. When the missing positions are all blank fields, the viewer says that trailing spaces were probably stripped. Common causes - Opening and saving the file in a spreadsheet, which drops trailing spaces (and leading zeros). - Copying records through email or chat, which can trim or wrap long lines. - A value longer than its field, such as a 23-character name in the 22-character Individual Name field, which pushes the record to 95 characters. - Spaces after position 94, which the viewer reports separately, as a warning. Reported as [RECORD_LENGTH](https://nacha-navigator.com/nacha-file-errors#record-length) [TRAILING_WHITESPACE](https://nacha-navigator.com/nacha-file-errors#trailing-whitespace) [FH_RECORD_SIZE](https://nacha-navigator.com/nacha-file-errors#fh-record-size) ### Immediate Destination and Immediate Origin Positions 4–13 and 14–23 of the File Header say where the file goes and where it comes from. Each field is 10 characters. A routing number is written as a blank followed by its 9 digits, a layout often shown as `bTTTTAAAAC`: b for the blank, TTTT for the Federal Reserve routing symbol, AAAA for the institution and C for the check digit. The Immediate Destination is the routing number of the bank or ACH Operator that receives the file, usually your bank; its file specifications give the exact value. The Immediate Origin identifies the sender: a routing number written the same way, or a 10-character identifier your bank assigned. | Immediate Destination | What the viewer reports | | --- | --- | | `·065503681` | Valid: a blank, then a routing number that passes the check-digit test. | | `0065503681` | [FH_ROUTING_LAYOUT](https://nacha-navigator.com/nacha-file-errors#fh-routing-layout) A zero where the blank goes. The routing number is fine, so this is a warning. | | `065503681·` | [FH_ROUTING_LAYOUT](https://nacha-navigator.com/nacha-file-errors#fh-routing-layout) Left-justified, with the blank at the end. Also a warning. | | `·065503682` | [FH_IMMEDIATE_DESTINATION](https://nacha-navigator.com/nacha-file-errors#fh-immediate-destination) The first eight digits imply check digit 1, not 2, so one of the nine digits is wrong. An error. | A dot (·) stands for the blank. The ninth digit is a check digit. Multiply the nine digits by 3, 7 and 1 in turn and add the results: the total must be a multiple of 10. For 065503681 that is 0×3 + 6×7 + 5×1 + 5×3 + 0×7 + 3×1 + 6×3 + 8×7 + 1×1 = 140. When a routing number fails, don’t change its last digit to make it pass: any of the nine digits may be the one that was mistyped. Get the number again from the bank, or look it up with [PayOps Kit’s routing number tool (opens in a new tab)](https://payopskit.com/routing-number). Reported as [FH_IMMEDIATE_DESTINATION](https://nacha-navigator.com/nacha-file-errors#fh-immediate-destination) [FH_ROUTING_LAYOUT](https://nacha-navigator.com/nacha-file-errors#fh-routing-layout) [FH_IMMEDIATE_ORIGIN](https://nacha-navigator.com/nacha-file-errors#fh-immediate-origin) [FH_IMMEDIATE_ORIGIN_ID](https://nacha-navigator.com/nacha-file-errors#fh-immediate-origin-id) [ROUTING_CHECK_DIGIT](https://nacha-navigator.com/nacha-file-errors#routing-check-digit) ### Control totals that don’t balance Each Company/Batch Control restates its batch: how many Entry Detail and Addenda records it holds (positions 5–10), the total of its debits (21–32) and the total of its credits (33–44), in cents with no decimal point. The File Control does the same for the whole file and adds the number of batches. When entries are added, removed or edited by hand and the controls aren’t recomputed, they stop matching. Whether an entry is a debit or a credit comes from the second digit of its Transaction Code: 1 to 4 is a credit, 5 to 9 a debit. Prenotes and zero-dollar entries count as entries but add nothing to the totals. | Line | Transaction code | Amount (30–39) | Debit | Credit | | --- | --- | --- | --- | --- | | 3 | 22 Checking credit | 0000125000 | | $1,250.00 | | 4 | 32 Savings credit | 0000050000 | | $500.00 | | 5 | 23 Checking credit prenote | 0000000000 | | $0.00 | | 6 | 27 Checking debit | 0000175000 | $1,750.00 | | The Company/Batch Control for these four entries carries: | Field | Positions | Value | | --- | --- | --- | | Entry/Addenda Count | 5–10 | 000004 | | Total Debit Entry Dollar Amount | 21–32 | 000000175000 | | Total Credit Entry Dollar Amount | 33–44 | 000000175000 | An addenda record after the entry on line 3 would make the count 000005 and leave both totals as they are. Common causes - Changing an amount in the file without updating its Batch Control and the File Control. - Deleting an entry without recounting the batch. - Leaving addenda records out of the count, or counting headers and controls in it. - Writing dollars with a decimal point (1250.00) instead of cents (0000125000). The viewer recomputes every count and total and shows the value it expects. Fix the Batch Controls first: the File Control’s figures are their sums. Reported as [BC_ENTRY_ADDENDA_COUNT](https://nacha-navigator.com/nacha-file-errors#bc-entry-addenda-count) [BC_TOTAL_DEBIT](https://nacha-navigator.com/nacha-file-errors#bc-total-debit) [BC_TOTAL_CREDIT](https://nacha-navigator.com/nacha-file-errors#bc-total-credit) [FC_BATCH_COUNT](https://nacha-navigator.com/nacha-file-errors#fc-batch-count) [FC_ENTRY_ADDENDA_COUNT](https://nacha-navigator.com/nacha-file-errors#fc-entry-addenda-count) [FC_TOTAL_DEBIT](https://nacha-navigator.com/nacha-file-errors#fc-total-debit) [FC_TOTAL_CREDIT](https://nacha-navigator.com/nacha-file-errors#fc-total-credit) The checks ## All 94 checks, by record Each check below has the severity the viewer reports it with, what it looks for, how to fix what it finds and where the requirement comes from. Where it is about one field or record, a link goes to that layout in the [NACHA file format](https://nacha-navigator.com/nacha-file-format) reference. The list ends with one note about the issue list itself, [ISSUES_TRUNCATED](https://nacha-navigator.com/nacha-file-errors#issues-truncated). | Group | Checks | Errors | Warnings | Notes | | --- | --- | --- | --- | --- | | [Input and structure](https://nacha-navigator.com/nacha-file-errors#structure-checks) | 23 | 15 | 6 | 2 | | [Field content](https://nacha-navigator.com/nacha-file-errors#field-checks) | 9 | 7 | 2 | 0 | | [File Header](https://nacha-navigator.com/nacha-file-errors#file-header-checks) | 9 | 7 | 1 | 1 | | [Company/Batch Header](https://nacha-navigator.com/nacha-file-errors#batch-header-checks) | 7 | 4 | 2 | 1 | | [Entry Detail](https://nacha-navigator.com/nacha-file-errors#entry-detail-checks) | 16 | 11 | 4 | 1 | | [Addenda](https://nacha-navigator.com/nacha-file-errors#addenda-checks) | 14 | 12 | 2 | 0 | | [Controls and totals](https://nacha-navigator.com/nacha-file-errors#control-checks) | 16 | 14 | 2 | 0 | | All checks | 94 | 70 | 19 | 5 | ### Input and structure Whether the file can be read as a NACHA file at all, and whether its records come in the right order. The viewer reports these as it reads the file. #### File has no records Error `FILE_EMPTY` **What it checks.** The file contains no NACHA records at all. **How to fix it.** Export the file again from the system that creates it, and check that you picked the ACH file itself rather than a report or an empty export. A NACHA file is plain text: lines of 94 characters that start with 1, 5, 6, 7, 8 or 9. Source: Nacha Operating Rules, Appendix One (ACH File Exchange Specifications). Format reference: [How a NACHA file is organized](https://nacha-navigator.com/nacha-file-format#overview). #### Byte-order mark Warning `BOM_PRESENT` **What it checks.** The file starts with a Unicode byte-order mark. NACHA files are plain ASCII; some banks reject the mark. **How to fix it.** Save the file without the byte-order mark: choose ASCII, or UTF-8 without BOM, as the encoding in the editor or export settings, so the file starts with the File Header’s record type code, 1. Source: Nacha Operating Rules, Appendix One (ACH File Exchange Specifications). #### Blank line between records Warning `BLANK_LINE` **What it checks.** Blank or whitespace-only lines are not records and are not allowed between records. **How to fix it.** Delete the empty lines between records so that every line is a record. They usually come from joining files or batches with an extra line break. Source: Nacha Operating Rules, Appendix One (ACH File Exchange Specifications). #### Blank lines at the end Note `TRAILING_BLANK_LINES` **What it checks.** Extra blank lines after the last record; most systems ignore them. **How to fix it.** Usually nothing: most systems ignore them. If your bank’s intake is strict, delete the empty lines after the last record; a single line break at the end of the file is fine. Source: Nacha Operating Rules, Appendix One (ACH File Exchange Specifications). #### End-of-file marker after the last record Warning `END_OF_FILE_MARKER` **What it checks.** The file ends with a DOS end-of-file character (Ctrl-Z, 0x1A) or NUL padding. It is not a record and is set aside; some banks reject a file that carries it. **How to fix it.** Remove the Ctrl-Z (0x1A) or NUL characters after the last record. Older DOS and Windows tools and some transfer setups add them, so turn that option off or strip them before sending the file. Source: Nacha Operating Rules, Appendix One (ACH File Exchange Specifications). #### Mixed line endings Warning `MIXED_LINE_ENDINGS` **What it checks.** Records are separated by a mixture of CRLF, LF and CR line endings. **How to fix it.** Convert the file to one line-ending style, CRLF or LF, whichever your bank expects. Mixed endings usually mean the file was edited or put together on different systems. Source: Nacha Operating Rules, Appendix One (ACH File Exchange Specifications). #### Records without line breaks Note `UNBLOCKED_RECORDS` **What it checks.** Records were concatenated with no line breaks; they were split every 94 characters. **How to fix it.** Most banks expect each record on its own line: insert a line break after every 94 characters. Keep the file unbroken only if your bank’s specifications ask for it. Source: Nacha Operating Rules, Appendix One (ACH File Exchange Specifications). Format reference: [How a NACHA file is organized](https://nacha-navigator.com/nacha-file-format#overview). #### Record is not 94 characters Error `RECORD_LENGTH` **What it checks.** Every record must be exactly 94 characters long (Record Size 094). **How to fix it.** Make the record exactly 94 characters. A short record has usually lost its trailing spaces to an editor or a spreadsheet: pad it with spaces to position 94. A long one has extra characters: find the field that grew and shorten it, or every field after it is read from the wrong positions. Source: Nacha Operating Rules, Appendix One (ACH File Exchange Specifications). Format reference: [How a NACHA file is organized](https://nacha-navigator.com/nacha-file-format#overview). #### Trailing whitespace Warning `TRAILING_WHITESPACE` **What it checks.** The record has blanks after position 94. Records must be exactly 94 characters. **How to fix it.** Remove the spaces after position 94 so that the record ends at 94 characters, and check the export or editor setting that pads lines to a longer width. Source: Nacha Operating Rules, Appendix One (ACH File Exchange Specifications). Format reference: [How a NACHA file is organized](https://nacha-navigator.com/nacha-file-format#overview). #### Invalid character Error `INVALID_CHARACTER` **What it checks.** Records may contain only printable ASCII characters (space through tilde); control and non-ASCII characters are not allowed. **How to fix it.** Replace the character with plain ASCII: accented letters with unaccented ones (É becomes E), curly quotes with straight ones, long dashes with hyphens and tabs with spaces. Clean the source data, such as names and addenda text, so the next export is clean too. Source: Nacha Operating Rules, Appendix One (ACH File Exchange Specifications). #### Unknown record type Error `UNKNOWN_RECORD_TYPE` **What it checks.** Position 1 must be a Record Type Code: 1, 5, 6, 7, 8 or 9. **How to fix it.** Make position 1 one of 1, 5, 6, 7, 8 or 9. Delete a line that isn’t a NACHA record (a title row, a comment, a line from another file); if the record starts with a space or a tab, it has shifted right, so remove that character. Source: Nacha Operating Rules, Appendix Three (ACH Record Format Specifications). Format reference: [The order of the records](https://nacha-navigator.com/nacha-file-format#record-order). #### No File Header Error `FILE_HEADER_MISSING` **What it checks.** A file must begin with exactly one File Header Record (type 1). **How to fix it.** Add a File Header Record (type 1) as the first line, with the Immediate Destination and Immediate Origin from your bank’s file specifications. A missing header often means the file was cut short or pieced together: export it again in full. Source: Nacha Operating Rules, Appendix One (ACH File Exchange Specifications). Format reference: [File Header record](https://nacha-navigator.com/nacha-file-format#file-header). #### File Header is not first Error `FILE_HEADER_NOT_FIRST` **What it checks.** The File Header Record must be the first record in the file. **How to fix it.** Move the File Header to the first line and delete whatever comes before it, such as a title row, a blank record or a record from another file. Source: Nacha Operating Rules, Appendix One (ACH File Exchange Specifications). Format reference: [File Header record](https://nacha-navigator.com/nacha-file-format#file-header). #### Second File Header Error `FILE_HEADER_DUPLICATE` **What it checks.** A file has exactly one File Header Record. **How to fix it.** Two files were probably joined. Send them as separate files, or combine their batches under one File Header and one File Control with recomputed counts and totals. Source: Nacha Operating Rules, Appendix One (ACH File Exchange Specifications). Format reference: [File Header record](https://nacha-navigator.com/nacha-file-format#file-header). #### No File Control Error `FILE_CONTROL_MISSING` **What it checks.** A file must end with a File Control Record (type 9), followed only by block-fill records. **How to fix it.** Add a File Control Record (type 9) after the last Batch Control, with the file’s batch count, block count, entry/addenda count, entry hash and debit and credit totals, then the block fill. A missing control usually means the file was truncated: export or download it again. Source: Nacha Operating Rules, Appendix One (ACH File Exchange Specifications). Format reference: [File Control record](https://nacha-navigator.com/nacha-file-format#file-control). #### Second File Control Error `FILE_CONTROL_DUPLICATE` **What it checks.** A file has exactly one File Control Record. **How to fix it.** Keep one File Control, at the end of the file. A second one usually means two files were concatenated: split them, or merge their batches and recompute a single File Control. Source: Nacha Operating Rules, Appendix One (ACH File Exchange Specifications). Format reference: [File Control record](https://nacha-navigator.com/nacha-file-format#file-control). #### Record after File Control Error `RECORD_AFTER_FILE_CONTROL` **What it checks.** Only block-fill records (all 9s) may follow the File Control Record. **How to fix it.** Move the record into the batch it belongs to, before the File Control, or delete it. If a whole file was appended after this one, send it separately. Source: Nacha Operating Rules, Appendix One (ACH File Exchange Specifications). Format reference: [Block-fill records](https://nacha-navigator.com/nacha-file-format#block-fill). #### Block fill before File Control Error `FILLER_BEFORE_FILE_CONTROL` **What it checks.** Block-fill records (all 9s) belong after the File Control Record. **How to fix it.** Move the block-fill records (all 9s) to the end of the file, after the File Control, or delete them and pad the file again. Source: Nacha Operating Rules, Appendix One (ACH File Exchange Specifications). Format reference: [Block-fill records](https://nacha-navigator.com/nacha-file-format#block-fill). #### Record outside a batch Error `BATCH_HEADER_MISSING` **What it checks.** Entry Detail, Addenda and Batch Control records must follow a Company/Batch Header Record. **How to fix it.** Put a Company/Batch Header Record (type 5) before the entries, or move the stray Entry Detail, Addenda or Batch Control record into the batch it belongs to. Source: Nacha Operating Rules, Appendix One (ACH File Exchange Specifications). Format reference: [Company/Batch Header record](https://nacha-navigator.com/nacha-file-format#batch-header). #### Batch not closed Error `BATCH_CONTROL_MISSING` **What it checks.** Every batch must end with a Company/Batch Control Record (type 8). **How to fix it.** Close the batch with a Company/Batch Control Record (type 8) before the next batch header or the File Control. It carries the batch’s counts, entry hash and totals, and repeats the header’s Service Class Code, Company Identification, ODFI and batch number. Source: Nacha Operating Rules, Appendix One (ACH File Exchange Specifications). Format reference: [Company/Batch Control record](https://nacha-navigator.com/nacha-file-format#batch-control). #### Addenda without an entry Error `ADDENDA_WITHOUT_ENTRY` **What it checks.** An Addenda Record must follow an Entry Detail Record or another Addenda Record. **How to fix it.** Move the addenda directly after the Entry Detail it belongs to and set that entry’s Addenda Record Indicator to 1, or delete it if it was left behind when an entry was removed. Source: Nacha Operating Rules, Appendix One (ACH File Exchange Specifications). Format reference: [Addenda type 05 record](https://nacha-navigator.com/nacha-file-format#addenda-05). #### File has no batches Warning `FILE_NO_BATCHES` **What it checks.** The file has a header and control but no batches. **How to fix it.** If the file should carry payments, the batches were lost along the way: export it again. If there is nothing to pay or collect this time, don’t send a file. Source: Nacha Operating Rules, Appendix One (ACH File Exchange Specifications). Format reference: [The order of the records](https://nacha-navigator.com/nacha-file-format#record-order). #### Batch has no entries Error `BATCH_NO_ENTRIES` **What it checks.** A batch must contain at least one Entry Detail Record. **How to fix it.** Add the batch’s Entry Detail records, or delete the empty batch (its header and control) and lower the File Control’s Batch Count by one. Source: Nacha Operating Rules, Appendix One (ACH File Exchange Specifications). Format reference: [Entry Detail record](https://nacha-navigator.com/nacha-file-format#entry-ppd). ### Field content Checks that apply to every field of every record: digits where digits belong, data where data is required, real dates, known codes and valid routing numbers. #### Non-numeric value in a numeric field Error `FIELD_NOT_NUMERIC` **What it checks.** Numeric fields contain digits only: right-justified and zero-filled, unsigned, no blanks. **How to fix it.** Write the field as digits only, right-justified and zero-filled: $12.50 in the 10-digit amount field is 0000001250. Remove spaces, decimal points, commas, signs and letters. Source: Nacha Operating Rules, Appendix One (ACH File Exchange Specifications). Format reference: [Field rules](https://nacha-navigator.com/nacha-file-format#field-rules). #### Mandatory field is blank Error `MANDATORY_FIELD_BLANK` **What it checks.** A field marked M (mandatory) must be filled in; ACH Operators reject the entry or batch otherwise. **How to fix it.** Fill in the field from your source data. Mandatory fields must hold valid data, and the ACH Operator can reject the batch or the whole file when they don’t. Source: Nacha Operating Rules, Appendix Three (ACH Record Format Specifications). Format reference: [Field rules](https://nacha-navigator.com/nacha-file-format#field-rules). #### Required field is blank Warning `REQUIRED_FIELD_BLANK` **What it checks.** A field marked R (required) is blank; the RDFI may return the entry. **How to fix it.** Fill in the field if you have the data. A blank Required field doesn’t stop the file, but the Receiver’s bank may return the entry. Source: Nacha Operating Rules, Appendix Three (ACH Record Format Specifications). Format reference: [Field rules](https://nacha-navigator.com/nacha-file-format#field-rules). #### Reserved field is not blank Warning `RESERVED_NOT_BLANK` **What it checks.** Reserved positions must be space-filled, and so must the blanks inside a layout, such as positions 18–20 of C06 Corrected Data. **How to fix it.** Replace the characters with spaces. Data in reserved positions usually means the field before them ran long or the record follows another layout; in a C06 NOC, the account number ends at position 17 of the Corrected Data and the Transaction Code goes in 21–22. Source: Nacha Operating Rules, Appendix Three (ACH Record Format Specifications). Format reference: [Field rules](https://nacha-navigator.com/nacha-file-format#field-rules). #### Invalid date or time Error `INVALID_DATE` **What it checks.** Date, time and Julian-day fields must hold real calendar values (YYMMDD, HHMM, MMDD, MMYY, DDD). **How to fix it.** Write a real calendar value in the field’s format: YYMMDD for dates (261030 is October 30, 2026) and HHMM for times (1405), or MMDD or MMYY where the layout says so. Look for a swapped month and day, or a 31st in a 30-day month. Source: Nacha Operating Rules, Appendix Three (ACH Record Format Specifications). Format reference: [Field rules](https://nacha-navigator.com/nacha-file-format#field-rules). #### Unknown code Error `INVALID_CODE` **What it checks.** The field must contain one of the codes defined for it. **How to fix it.** Use one of the values defined for the field, such as 0 or 1 for the Addenda Record Indicator, or FF, FV or VF for an IAT Foreign Exchange Indicator. If the value looks right, check the field before it: one that is a character too long or short shifts every field after it. Source: Nacha Operating Rules, Appendix Three (ACH Record Format Specifications). Format reference: [Code tables](https://nacha-navigator.com/nacha-file-format#code-tables). #### Code is not uppercase Error `CODE_NOT_UPPERCASE` **What it checks.** Codes such as the SEC code and the change and return reason codes must be uppercase. **How to fix it.** Write the code in capital letters: PPD rather than ppd, R01 rather than r01. Source: Nacha Operating Rules, Appendix Three (ACH Record Format Specifications). Format reference: [Code tables](https://nacha-navigator.com/nacha-file-format#code-tables). #### Invalid routing symbol Error `ROUTING_SYMBOL` **What it checks.** The first two digits of a routing number must be 00–12, 21–32, 61–72 or 80 (Federal Reserve routing symbol). **How to fix it.** Check the routing number against its source. Valid routing numbers start with 00–12, 21–32, 61–72 or 80, so other first two digits point to a typo, a value in the wrong field (such as an account number) or fields shifted by a character. Source: Nacha Operating Rules, Appendix Three (ACH Record Format Specifications). #### Routing number check digit Error `ROUTING_CHECK_DIGIT` **What it checks.** A 9-digit routing number must pass the ABA 3-7-1 check-digit test. **How to fix it.** Get the routing number again from its source (the Receiver, their bank or yours) and retype it. Don’t change the ninth digit to make the test pass: any of the nine digits may be the wrong one. Source: Nacha Operating Rules, Appendix Three (ACH Record Format Specifications). Format reference: [Totals and check digits](https://nacha-navigator.com/nacha-file-format#totals-and-hashes). ### File Header The first record (type 1): who the file is for and who sent it, and the fixed values that describe the format. #### Priority Code is not 01 Error `FH_PRIORITY_CODE` **What it checks.** The Priority Code must be "01". **How to fix it.** Set positions 2–3 of the File Header to 01. Source: Nacha Operating Rules, Appendix Three (ACH Record Format Specifications). Format reference: [Priority Code, File Header positions 2–3](https://nacha-navigator.com/nacha-file-format#file-header-priority-code). #### Invalid Immediate Destination Error `FH_IMMEDIATE_DESTINATION` **What it checks.** The Immediate Destination must be a blank followed by a 9-digit routing number that passes the check-digit test (bTTTTAAAAC). **How to fix it.** Use the routing number your bank gives for receiving files, written as a blank followed by the 9 digits in positions 4–13. If the check digit fails, the number was mistyped: copy it again from your bank’s file specifications. Source: Nacha Operating Rules, Appendix Three (ACH Record Format Specifications). Format reference: [Immediate Destination, File Header positions 4–13](https://nacha-navigator.com/nacha-file-format#file-header-immediate-destination). #### Routing number not in bTTTTAAAAC layout Warning `FH_ROUTING_LAYOUT` **What it checks.** The Immediate Destination or Origin holds a valid routing number, but not as a blank followed by the 9 digits (bTTTTAAAAC). **How to fix it.** Write the field as a blank followed by the 9-digit routing number: " 065503681", not "0065503681" or "065503681 ". Keep another layout only if your bank’s specifications ask for it. Source: Nacha Operating Rules, Appendix Three (ACH Record Format Specifications). Format reference: [File Header record](https://nacha-navigator.com/nacha-file-format#file-header). #### Invalid Immediate Origin Error `FH_IMMEDIATE_ORIGIN` **What it checks.** When the Immediate Origin is a routing number (bTTTTAAAAC) it must pass the check-digit test. **How to fix it.** Copy the Immediate Origin again from your bank’s file specifications: it fails the check-digit test, so one of its digits is wrong. Write it as a blank followed by the 9 digits in positions 14–23. Source: Nacha Operating Rules, Appendix Three (ACH Record Format Specifications). Format reference: [Immediate Origin, File Header positions 14–23](https://nacha-navigator.com/nacha-file-format#file-header-immediate-origin). #### Immediate Origin is not a routing number Note `FH_IMMEDIATE_ORIGIN_ID` **What it checks.** The Immediate Origin is a 10-character identifier rather than a routing number; this is allowed when agreed with the receiving point. **How to fix it.** Nothing to change if your bank assigned this identifier (often based on the company’s tax ID). If the field should hold a routing number, write it as a blank followed by the 9 digits. Source: Nacha Operating Rules, Appendix Three (ACH Record Format Specifications). Format reference: [Immediate Origin, File Header positions 14–23](https://nacha-navigator.com/nacha-file-format#file-header-immediate-origin). #### Invalid File ID Modifier Error `FH_FILE_ID_MODIFIER` **What it checks.** The File ID Modifier must be an uppercase letter A–Z or a digit 0–9. **How to fix it.** Put an uppercase letter or a digit in position 34: A for the first file created on a day, then B, C and so on for each further file that day, so that files from the same day can be told apart. Source: Nacha Operating Rules, Appendix Three (ACH Record Format Specifications). Format reference: [File ID Modifier, File Header position 34](https://nacha-navigator.com/nacha-file-format#file-header-file-id-modifier). #### Record Size is not 094 Error `FH_RECORD_SIZE` **What it checks.** The Record Size must be "094". **How to fix it.** Set positions 35–37 of the File Header to 094. Source: Nacha Operating Rules, Appendix Three (ACH Record Format Specifications). Format reference: [Record Size, File Header positions 35–37](https://nacha-navigator.com/nacha-file-format#file-header-record-size). #### Blocking Factor is not 10 Error `FH_BLOCKING_FACTOR` **What it checks.** The Blocking Factor must be "10". **How to fix it.** Set positions 38–39 of the File Header to 10, and pad the file with block-fill records to a multiple of 10 lines. Source: Nacha Operating Rules, Appendix Three (ACH Record Format Specifications). Format reference: [Blocking Factor, File Header positions 38–39](https://nacha-navigator.com/nacha-file-format#file-header-blocking-factor). #### Format Code is not 1 Error `FH_FORMAT_CODE` **What it checks.** The Format Code must be "1". **How to fix it.** Set position 40 of the File Header to 1. Source: Nacha Operating Rules, Appendix Three (ACH Record Format Specifications). Format reference: [Format Code, File Header position 40](https://nacha-navigator.com/nacha-file-format#file-header-format-code). ### Company/Batch Header The header of each batch (type 5): its Service Class Code, SEC code, Effective Entry Date and numbering. #### Invalid Service Class Code Error `BH_SERVICE_CLASS` **What it checks.** The Service Class Code must be 200, 220, 225 or 280. **How to fix it.** Use 220 for a batch of credits only, 225 for debits only or 200 for both, in positions 2–4 of the Batch Header, and the same code in its Batch Control. (280 is for ADV files that ACH Operators prepare.) Source: Nacha Operating Rules, Appendix Three (ACH Record Format Specifications). Format reference: [Service Class Code, Company/Batch Header positions 2–4](https://nacha-navigator.com/nacha-file-format#batch-header-service-class-code). #### Invalid SEC code Error `BH_SEC_CODE` **What it checks.** The Standard Entry Class Code must be one of the codes defined by the Rules, in uppercase. **How to fix it.** Write the Standard Entry Class code that matches how the payments were authorized and who receives them, such as PPD for consumer accounts or CCD for business accounts, in uppercase in positions 51–53. Source: Nacha Operating Rules, Appendix Three (ACH Record Format Specifications). Format reference: [Standard Entry Class Code, Company/Batch Header positions 51–53](https://nacha-navigator.com/nacha-file-format#batch-header-standard-entry-class-code). #### Effective date is not a banking day Warning `BH_EFFECTIVE_DATE_NOT_BANKING_DAY` **What it checks.** The Effective Entry Date falls on a weekend or a Federal Reserve holiday, so the entries settle on a later banking day. **How to fix it.** Set the Effective Entry Date (positions 70–75) to a banking day, a weekday that isn’t a Federal Reserve holiday. As it stands the entries settle on the next banking day, which may be later than you intended. Source: Nacha Operating Rules, Appendix Three (ACH Record Format Specifications). Format reference: [Effective Entry Date, Company/Batch Header positions 70–75](https://nacha-navigator.com/nacha-file-format#batch-header-effective-entry-date). #### Effective date is in the past Note `BH_EFFECTIVE_DATE_PAST` **What it checks.** The Effective Entry Date is before the reference date given to the validator; if sent now the entries settle at the next opportunity. **How to fix it.** Set the Effective Entry Date to the day the entries should settle, today or later. Entries with a past date settle at the next opportunity, which can be the same day when the file reaches the ACH Operator before a Same Day ACH deadline. Source: Nacha Operating Rules, Appendix Three (ACH Record Format Specifications). Format reference: [Effective Entry Date, Company/Batch Header positions 70–75](https://nacha-navigator.com/nacha-file-format#batch-header-effective-entry-date). #### Originator Status Code Error `BH_ORIGINATOR_STATUS` **What it checks.** The Originator Status Code must be 1 or 2 (0 only in ADV files). **How to fix it.** Put 1 in position 79 of the Batch Header, or 2 if the Originator is a Federal Government entity. 0 is only for ADV files that an ACH Operator prepares. Source: Nacha Operating Rules, Appendix Three (ACH Record Format Specifications). Format reference: [Originator Status Code, Company/Batch Header position 79](https://nacha-navigator.com/nacha-file-format#batch-header-originator-status-code). #### Batch numbers not ascending Warning `BH_BATCH_NUMBER_ORDER` **What it checks.** Batch numbers should be assigned in ascending sequence within the file. **How to fix it.** Number the batches in ascending order through the file (0000001, 0000002 and so on) and repeat each batch’s number in its Batch Control. Source: Nacha Operating Rules, Appendix Three (ACH Record Format Specifications). Format reference: [Batch Number, Company/Batch Header positions 88–94](https://nacha-navigator.com/nacha-file-format#batch-header-batch-number). #### Invalid ISO code Error `IAT_ISO_CODE` **What it checks.** IAT country codes are two uppercase letters (ISO 3166) and currency codes three (ISO 4217). **How to fix it.** Write countries as two uppercase letters from ISO 3166 (US, CA, MX) and currencies as three uppercase letters from ISO 4217 (USD, CAD, MXN). Source: Nacha Operating Rules, Appendix Three (ACH Record Format Specifications). Format reference: [IAT Company/Batch Header record](https://nacha-navigator.com/nacha-file-format#batch-header-iat). ### Entry Detail Each payment (type 6): its Transaction Code, routing and account numbers, amount, addenda fields and trace number. #### Invalid Transaction Code Error `ED_TRANSACTION_CODE` **What it checks.** The Transaction Code must be one defined by the Rules (21–24, 26–29, 31–34, 36–39, 41–44, 46–49, 51–56; 81–88 in ADV files). **How to fix it.** Use a code defined for the account type and direction, such as 22 (checking credit), 27 (checking debit), 32 (savings credit) or 37 (savings debit); prenotes use 23, 28, 33 or 38. Codes 81–88 belong only in ADV files. Source: Nacha Operating Rules, Appendix Three (ACH Record Format Specifications). Format reference: [Transaction codes](https://nacha-navigator.com/nacha-file-format#transaction-codes). #### Transaction Code not allowed for the SEC code Error `ED_TRANSACTION_CODE_SEC` **What it checks.** Some SEC codes allow only debits (ARC, BOC, POP, RCK, TEL, TRC, TRX, XCK), only credits (CIE), only zero-dollar acknowledgments (ACK, ATX), only the codes 23 and 33 (ENR), only return/NOC codes (COR) or only ADV codes (ADV). Reversing Entries (Company Entry Description REVERSAL) may move money the other way under ARC, BOC, POP, RCK, TEL, XCK and CIE (return reasons R35 and R36, Appendix Four). **How to fix it.** Use a Transaction Code that the batch’s SEC code allows, or move the entry to a batch whose SEC code fits it: a debit code under TEL or RCK, a credit code under CIE, 23 or 33 under ENR, 24 or 34 under ACK and ATX, and a return or NOC code under COR. Source: Nacha Operating Rules, Appendix Three (ACH Record Format Specifications). Format reference: [SEC codes](https://nacha-navigator.com/nacha-file-format#sec-codes). #### Entry direction does not match the Service Class Code Error `ED_SERVICE_CLASS_MISMATCH` **What it checks.** A batch with Service Class Code 220 may hold only credits, and 225 only debits. **How to fix it.** Change the batch’s Service Class Code to 200 (credits and debits) in both its header and its control, or move the entry to a batch whose Service Class Code matches its direction. Source: Nacha Operating Rules, Appendix Two (Specifications for Data Acceptance by ACH Operators). Format reference: [Service class codes](https://nacha-navigator.com/nacha-file-format#service-class-codes). #### RDFI routing number fails the check digit Error `ED_RDFI_CHECK_DIGIT` **What it checks.** Positions 4–12 (Receiving DFI Identification and Check Digit) must form a routing number that passes the ABA check-digit test. **How to fix it.** Ask the Receiver for their bank’s routing number again (a check or the bank’s website shows it) and correct positions 4–12. Don’t just change the check digit: any of the nine digits may be the wrong one. Source: Nacha Operating Rules, Appendix Three (ACH Record Format Specifications). Format reference: [Check Digit, Entry Detail position 12](https://nacha-navigator.com/nacha-file-format#entry-ppd-check-digit). #### DFI Account Number is blank Error `ED_ACCOUNT_BLANK` **What it checks.** Every entry needs the Receiver’s account number. ENR enrollments are the exception: they leave it blank and carry the enrollee’s account in the addenda. **How to fix it.** Put the Receiver’s account number in positions 13–29, left-justified. If you don’t have it, hold the entry until you do: the Receiver’s bank can’t post it without one. Source: Nacha Operating Rules, Appendix Three (ACH Record Format Specifications). Format reference: [DFI Account Number, Entry Detail positions 13–29](https://nacha-navigator.com/nacha-file-format#entry-ppd-dfi-account-number). #### Prenote with an amount Error `ED_PRENOTE_AMOUNT` **What it checks.** Prenotification entries (Transaction Codes 23, 28, 33, 38, 43, 48, 53) must have a zero amount. **How to fix it.** Set the amount (positions 30–39) to zeros. If the entry should move money, use the live code instead: 22 rather than 23, 27 rather than 28, 32 rather than 33, 37 rather than 38. Source: Nacha Operating Rules, Appendix Three (ACH Record Format Specifications). Format reference: [Amount, Entry Detail positions 30–39](https://nacha-navigator.com/nacha-file-format#entry-ppd-amount). #### Zero-dollar entry with an amount Error `ED_ZERO_DOLLAR_AMOUNT` **What it checks.** Zero-dollar Transaction Codes (24, 29, 34, 39, 44, 49, 54) and ACK, ATX, COR, DNE and ENR entries must have a zero amount. **How to fix it.** Set the amount to zeros, or use a live Transaction Code if money should move. ACK, ATX, COR, DNE and ENR entries never carry an amount. Source: Nacha Operating Rules, Appendix Three (ACH Record Format Specifications). Format reference: [Amount, Entry Detail positions 30–39](https://nacha-navigator.com/nacha-file-format#entry-ppd-amount). #### Zero-dollar entry without remittance Warning `ED_ZERO_DOLLAR_ADDENDA` **What it checks.** A zero-dollar entry exists to carry remittance data, so it should have an addenda record. **How to fix it.** Add the addenda record with the remittance information the entry is meant to carry and set its Addenda Record Indicator to 1, or drop the entry if there is nothing to send. Source: Nacha Operating Rules, Appendix Three (ACH Record Format Specifications). Format reference: [Addenda type 05 record](https://nacha-navigator.com/nacha-file-format#addenda-05). #### Live entry for $0.00 Warning `ED_LIVE_ZERO_AMOUNT` **What it checks.** A live-dollar Transaction Code carries a zero amount; use a prenote or zero-dollar code for non-monetary entries. **How to fix it.** Enter the payment amount. To check an account without moving money, use a prenote code (23, 28, 33, 38); to send remittance data on its own, use a zero-dollar code (24, 29, 34, 39). Source: Nacha Operating Rules, Appendix Three (ACH Record Format Specifications). Format reference: [Amount, Entry Detail positions 30–39](https://nacha-navigator.com/nacha-file-format#entry-ppd-amount). #### Addenda Record Indicator mismatch Error `ED_ADDENDA_INDICATOR` **What it checks.** The Addenda Record Indicator must be 1 when addenda follow the entry and 0 when none do. **How to fix it.** Set position 79 of the entry to 1 when addenda records follow it and to 0 when none do. Source: Nacha Operating Rules, Appendix Three (ACH Record Format Specifications). Format reference: [Addenda Record Indicator, Entry Detail position 79](https://nacha-navigator.com/nacha-file-format#entry-ppd-addenda-record-indicator). #### Number of Addenda Records mismatch Error `ED_ADDENDA_COUNT_FIELD` **What it checks.** CTX, ENR, ATX and TRX (positions 55–58) and IAT (positions 13–16) entries state how many addenda follow; it must match. **How to fix it.** Change the Number of Addenda Records (positions 55–58 for CTX, ENR, ATX and TRX; 13–16 for IAT) to the number of addenda that follow the entry, padded with leading zeros. Source: Nacha Operating Rules, Appendix Three (ACH Record Format Specifications). Format reference: [Number of Addenda Records, CTX Entry Detail positions 55–58](https://nacha-navigator.com/nacha-file-format#entry-ctx-number-of-addenda-records). #### Unusual Payment Type Code Note `ED_PAYMENT_TYPE` **What it checks.** WEB and TEL debits may carry a Payment Type Code in positions 77–78. It has been optional since September 17, 2021: the Originator and ODFI decide whether to use it and what it holds, and RDFIs cannot rely on it. "R " (recurring) and "S " (single entry) are the usual values; anything else is noted, not an error. **How to fix it.** Nothing has to change: the field is optional. If you use it, the usual values are "R " (recurring) and "S " (single entry), in uppercase; otherwise leave it blank. Source: Nacha Operating Rules, Appendix Three (ACH Record Format Specifications). Format reference: [Payment Type Code, WEB Entry Detail positions 77–78](https://nacha-navigator.com/nacha-file-format#entry-web-payment-type-code). #### Trace numbers not ascending Error `ED_TRACE_ORDER` **What it checks.** Trace numbers must be in ascending order within a batch. **How to fix it.** Renumber the batch so that trace numbers increase from entry to entry: the ODFI’s 8-digit routing number followed by a 7-digit sequence (0000001, 0000002 and so on). Update the addenda that repeat the trace number or its last 7 digits. Source: Nacha Operating Rules, Appendix Two (Specifications for Data Acceptance by ACH Operators). Format reference: [Trace Number, Entry Detail positions 80–94](https://nacha-navigator.com/nacha-file-format#entry-ppd-trace-number). #### Duplicate trace number Error `ED_TRACE_DUPLICATE` **What it checks.** A trace number identifies its entry within the batch, so it must be unique within the batch. **How to fix it.** Give each entry in the batch its own trace number, usually by renumbering the 7-digit sequence, and update its addenda to match. Source: Nacha Operating Rules, Appendix Three (ACH Record Format Specifications). Format reference: [Trace Number, Entry Detail positions 80–94](https://nacha-navigator.com/nacha-file-format#entry-ppd-trace-number). #### Trace number reused in another batch Warning `ED_TRACE_DUPLICATE_FILE` **What it checks.** Trace numbers must be unique within a batch; across the file, the Batch Number, File Creation Date and File ID Modifier tell entries apart. Many ODFIs still require trace numbers unique in the file, and a repeat makes returns and NOCs harder to match. **How to fix it.** If your ODFI wants trace numbers to be unique in the file, continue the sequence from one batch to the next instead of starting again in each batch. Source: Nacha Operating Rules, Appendix Three (ACH Record Format Specifications). Format reference: [Trace Number, Entry Detail positions 80–94](https://nacha-navigator.com/nacha-file-format#entry-ppd-trace-number). #### Trace number does not start with the ODFI Warning `ED_TRACE_ODFI` **What it checks.** The first 8 digits of a trace number are normally the batch’s Originating DFI Identification. **How to fix it.** Start each trace number with the batch’s Originating DFI Identification (positions 80–87 of the Batch Header), unless your ODFI has told you to use something else. Source: Nacha Operating Rules, Appendix Three (ACH Record Format Specifications). Format reference: [Trace Number, Entry Detail positions 80–94](https://nacha-navigator.com/nacha-file-format#entry-ppd-trace-number). ### Addenda Addenda records (type 7): which types an entry may carry and how many, and how each one points back to its entry. #### Unknown Addenda Type Code Error `AD_TYPE_CODE` **What it checks.** The Addenda Type Code must be 02, 05, 10–18, 98 or 99. **How to fix it.** Set positions 2–3 to the addenda type that fits the entry: 05 for payment related information, 02 for POS, SHR and MTE terminal data, 98 for a notification of change, 99 for a return, 10 to 18 for IAT. Source: Nacha Operating Rules, Appendix Three (ACH Record Format Specifications). Format reference: [Addenda type codes](https://nacha-navigator.com/nacha-file-format#addenda-type-codes). #### Addenda type not allowed Error `AD_TYPE_NOT_ALLOWED` **What it checks.** This addenda type is not used with this SEC code or entry (e.g. 02 only with POS, SHR and MTE; 98 only in COR batches; 99 only on returns). **How to fix it.** Use the addenda type the SEC code allows (05 under PPD or CCD, for example), remove the addenda, or move the entry to a batch with the right SEC code. ARC, BOC, POP, RCK, TEL, TRC and XCK entries carry no addenda; type 98 goes only in COR batches and type 99 only on returns. Source: Nacha Operating Rules, Appendix Three (ACH Record Format Specifications). Format reference: [SEC codes](https://nacha-navigator.com/nacha-file-format#sec-codes). #### Too many addenda Error `AD_TOO_MANY` **What it checks.** The SEC code limits how many addenda an entry may carry (ACK, CCD, CIE, DNE, PPD, WEB: 1; ATX, CTX, ENR, TRX: 9,999; IAT: 7 mandatory + 2 type 17 + 5 type 18). **How to fix it.** Keep within the SEC code’s limit: one addenda on ACK, CCD, CIE, DNE, MTE, POS, PPD, SHR and WEB entries, up to 9,999 on ATX, CTX, ENR and TRX, one 98 or 99 on a NOC or return, and at most 2 type 17 and 5 type 18 on IAT. Fit the remittance into fewer records, or use CTX for a corporate payment that needs more. Source: Nacha Operating Rules, Appendix Three (ACH Record Format Specifications). Format reference: [SEC codes](https://nacha-navigator.com/nacha-file-format#sec-codes). #### Required addenda missing Error `AD_MISSING` **What it checks.** POS, SHR and MTE entries need a type 02 addenda; DNE and ENR a type 05; COR entries a type 98; returns a type 99; IAT entries types 10–16. **How to fix it.** Add the addenda the entry needs and set its Addenda Record Indicator to 1: 02 for POS, SHR and MTE; 05 for DNE and ENR; 98 for a NOC in a COR batch; 99 for a return; 10 to 16 for IAT. Source: Nacha Operating Rules, Appendix Three (ACH Record Format Specifications). Format reference: [SEC codes](https://nacha-navigator.com/nacha-file-format#sec-codes). #### Addenda Sequence Number out of order Error `AD_SEQUENCE` **What it checks.** Addenda Sequence Numbers start at 0001 and increase by one for each addenda of the entry. **How to fix it.** Number each entry’s addenda 0001, 0002, 0003 and so on, in order. On IAT entries, type 17 and type 18 addenda are numbered separately, each from 0001. Source: Nacha Operating Rules, Appendix Three (ACH Record Format Specifications). Format reference: [Addenda Sequence Number, Addenda type 05 positions 84–87](https://nacha-navigator.com/nacha-file-format#addenda-05-addenda-sequence-number). #### Entry Detail Sequence Number mismatch Error `AD_ENTRY_SEQUENCE` **What it checks.** The Entry Detail Sequence Number must equal the last 7 digits of the entry’s trace number. **How to fix it.** Set the addenda’s Entry Detail Sequence Number (positions 88–94) to the last 7 digits of its entry’s trace number. Source: Nacha Operating Rules, Appendix Three (ACH Record Format Specifications). Format reference: [Entry Detail Sequence Number, Addenda type 05 positions 88–94](https://nacha-navigator.com/nacha-file-format#addenda-05-entry-detail-sequence-number). #### Addenda trace number mismatch Error `AD_TRACE_MISMATCH` **What it checks.** Type 02, 98 and 99 addenda repeat the trace number of their entry in positions 80–94. **How to fix it.** Copy the entry’s 15-digit trace number into positions 80–94 of its type 02, 98 or 99 addenda. Source: Nacha Operating Rules, Appendix Three (ACH Record Format Specifications). Format reference: [Trace Number, Addenda type 99 positions 80–94](https://nacha-navigator.com/nacha-file-format#addenda-99-trace-number). #### Unknown return reason code Error `AD_RETURN_REASON` **What it checks.** A type 99 addenda must carry a return reason code defined by the Rules (R01–R85, and R90 from March 17, 2028). **How to fix it.** Put a return reason code that the Rules assign, in uppercase, in positions 4–6 of the type 99 addenda: the assigned codes lie between R01 and R85, plus R90 from March 17, 2028. Source: Nacha Operating Rules, Appendix Four (Return Entries). Format reference: [Return reason codes](https://nacha-navigator.com/nacha-file-format#return-reason-codes). #### Return reason code not yet in effect Warning `AD_RETURN_REASON_NOT_EFFECTIVE` **What it checks.** R90 (Entry Returned Due to RDFI’s Sanctions Compliance Obligations) may be used from March 17, 2028. A file dated earlier should not use it; until then, a return made on an OFAC instruction uses R16. **How to fix it.** Use a code that is in effect on the file’s date. Until March 17, 2028, a return made on an OFAC instruction uses R16; use R90 only in files dated on or after that day. Source: Nacha Operating Rules, Appendix Four (Return Entries). Format reference: [Return reason codes](https://nacha-navigator.com/nacha-file-format#return-reason-codes). #### Return addenda on a non-return entry Error `AD_RETURN_ENTRY_CODE` **What it checks.** Type 98 and 99 addenda belong to entries with a return/NOC Transaction Code (21, 26, 31, 36, 41, 46, 51, 56). **How to fix it.** Give the entry the return/NOC Transaction Code for its account type (21, 26, 31, 36, 41, 46, 51 or 56), or remove the type 98 or 99 addenda if the entry isn’t a return or a NOC. Source: Nacha Operating Rules, Appendix Four (Return Entries). Format reference: [Transaction codes](https://nacha-navigator.com/nacha-file-format#transaction-codes). #### Date of death missing Warning `AD_DATE_OF_DEATH` **What it checks.** Returns for reason R14 or R15 should carry the date of death. **How to fix it.** Add the date of death, as YYMMDD, in positions 22–27 of the type 99 addenda of the R14 or R15 return. Source: Nacha Operating Rules, Appendix Four (Return Entries). Format reference: [Date of Death, Addenda type 99 positions 22–27](https://nacha-navigator.com/nacha-file-format#addenda-99-date-of-death). #### Unknown change code Error `AD_CHANGE_CODE` **What it checks.** A type 98 addenda must carry a current change code (C01–C03, C05–C09, C13 or C14), or C61–C69 for a refused NOC. C04 and C10–C12 are retired. **How to fix it.** Use a current change code in positions 4–6: C01–C03, C05–C09, C13 or C14, or C61–C69 to refuse a NOC. C04 and C10–C12 are retired and can’t be used. Source: Nacha Operating Rules, Appendix Five (Notification of Change). Format reference: [Change codes (NOC)](https://nacha-navigator.com/nacha-file-format#change-codes). #### Corrected Data invalid Error `AD_CORRECTED_DATA` **What it checks.** The Corrected Data of a NOC must be filled in and laid out as its change code requires. **How to fix it.** Put the corrected information in positions 36–64 in the layout its change code requires: the account number for C01, the 9-digit routing number for C02, or for C06 the account number in positions 1–17, blanks in 18–20 and the Transaction Code in 21–22. Source: Nacha Operating Rules, Appendix Five (Notification of Change). Format reference: [Change codes (NOC)](https://nacha-navigator.com/nacha-file-format#change-codes). #### IAT addenda out of order Error `AD_IAT_ORDER` **What it checks.** IAT entries carry addenda types 10, 11, 12, 13, 14, 15 and 16 in that order, then optional 17s and 18s. **How to fix it.** Place the IAT entry’s addenda directly after it, in order: types 10 to 16, then any type 17 (up to 2) and type 18 (up to 5) addenda. Source: Nacha Operating Rules, Appendix Three (ACH Record Format Specifications). Format reference: [Addenda type 10 record](https://nacha-navigator.com/nacha-file-format#addenda-10). ### Controls and totals The Company/Batch Control (type 8) and File Control (type 9) records, which count and total everything before them, and the block fill that pads the file. #### Service Class Code mismatch Error `BC_SERVICE_CLASS` **What it checks.** The Batch Control Service Class Code must match the Batch Header. **How to fix it.** Copy the Batch Header’s Service Class Code into positions 2–4 of the Batch Control. Source: Nacha Operating Rules, Appendix Three (ACH Record Format Specifications). Format reference: [Service Class Code, Company/Batch Control positions 2–4](https://nacha-navigator.com/nacha-file-format#batch-control-service-class-code). #### Entry/Addenda Count mismatch Error `BC_ENTRY_ADDENDA_COUNT` **What it checks.** The Entry/Addenda Count must equal the number of Entry Detail and Addenda records in the batch. **How to fix it.** Count the batch’s Entry Detail and Addenda records and write the number in positions 5–10 of the Batch Control, zero-filled. Source: Nacha Operating Rules, Appendix Three (ACH Record Format Specifications). Format reference: [Entry/Addenda Count, Company/Batch Control positions 5–10](https://nacha-navigator.com/nacha-file-format#batch-control-entry-addenda-count). #### Entry Hash mismatch Error `BC_ENTRY_HASH` **What it checks.** The Entry Hash must equal the sum of the 8-digit RDFI identifications in the batch, keeping the rightmost 10 digits. **How to fix it.** Add up the 8-digit RDFI identification (positions 4–11) of every entry in the batch and write the rightmost 10 digits of the sum in positions 11–20 of the Batch Control. Source: Nacha Operating Rules, Appendix Three (ACH Record Format Specifications). Format reference: [Entry Hash, Company/Batch Control positions 11–20](https://nacha-navigator.com/nacha-file-format#batch-control-entry-hash). #### Total debit mismatch Error `BC_TOTAL_DEBIT` **What it checks.** The Total Debit Entry Dollar Amount must equal the sum of the batch’s debit entries. **How to fix it.** Add up the amounts of the batch’s debit entries, in cents, and write the total in positions 21–32 of the Batch Control, zero-filled. A debit is a Transaction Code whose second digit is 5 to 9. Source: Nacha Operating Rules, Appendix Three (ACH Record Format Specifications). Format reference: [Total Debit Entry Dollar Amount, Company/Batch Control positions 21–32](https://nacha-navigator.com/nacha-file-format#batch-control-total-debit-entry-dollar-amount). #### Total credit mismatch Error `BC_TOTAL_CREDIT` **What it checks.** The Total Credit Entry Dollar Amount must equal the sum of the batch’s credit entries. **How to fix it.** Add up the amounts of the batch’s credit entries, in cents, and write the total in positions 33–44 of the Batch Control, zero-filled. A credit is a Transaction Code whose second digit is 1 to 4. Source: Nacha Operating Rules, Appendix Three (ACH Record Format Specifications). Format reference: [Total Credit Entry Dollar Amount, Company/Batch Control positions 33–44](https://nacha-navigator.com/nacha-file-format#batch-control-total-credit-entry-dollar-amount). #### Company Identification mismatch Error `BC_COMPANY_ID` **What it checks.** The Batch Control Company Identification must match the Batch Header. **How to fix it.** Copy the Company Identification from positions 41–50 of the Batch Header into positions 45–54 of the Batch Control. Source: Nacha Operating Rules, Appendix Three (ACH Record Format Specifications). Format reference: [Company Identification, Company/Batch Control positions 45–54](https://nacha-navigator.com/nacha-file-format#batch-control-company-identification). #### ODFI mismatch Error `BC_ODFI` **What it checks.** The Batch Control Originating DFI Identification must match the Batch Header. **How to fix it.** Copy the Originating DFI Identification from positions 80–87 of the Batch Header into the same positions of the Batch Control. Source: Nacha Operating Rules, Appendix Three (ACH Record Format Specifications). Format reference: [Originating DFI Identification, Company/Batch Control positions 80–87](https://nacha-navigator.com/nacha-file-format#batch-control-originating-dfi-identification). #### Batch Number mismatch Error `BC_BATCH_NUMBER` **What it checks.** The Batch Control Batch Number must match the Batch Header. **How to fix it.** Copy the Batch Number from positions 88–94 of the Batch Header into the same positions of the Batch Control. Source: Nacha Operating Rules, Appendix Three (ACH Record Format Specifications). Format reference: [Batch Number, Company/Batch Control positions 88–94](https://nacha-navigator.com/nacha-file-format#batch-control-batch-number). #### Batch Count mismatch Error `FC_BATCH_COUNT` **What it checks.** The Batch Count must equal the number of batches in the file. **How to fix it.** Count the batches (Company/Batch Header records) in the file and write the number in positions 2–7 of the File Control. Source: Nacha Operating Rules, Appendix Three (ACH Record Format Specifications). Format reference: [Batch Count, File Control positions 2–7](https://nacha-navigator.com/nacha-file-format#file-control-batch-count). #### Block Count mismatch Error `FC_BLOCK_COUNT` **What it checks.** The Block Count must equal the number of records (File Header through File Control, plus block fill) divided by 10, rounded up. **How to fix it.** Count the records from the File Header through the File Control, divide by 10 and round up, and write the result in positions 8–13. With block fill, that is the number of 10-record blocks: a 20-line file is 000002. Source: Nacha Operating Rules, Appendix One (ACH File Exchange Specifications). Format reference: [Block Count, File Control positions 8–13](https://nacha-navigator.com/nacha-file-format#file-control-block-count). #### Entry/Addenda Count mismatch Error `FC_ENTRY_ADDENDA_COUNT` **What it checks.** The file Entry/Addenda Count must equal the number of Entry Detail and Addenda records in the file. **How to fix it.** Write the number of Entry Detail and Addenda records in the whole file, the sum of the batch counts, in positions 14–21 of the File Control. Source: Nacha Operating Rules, Appendix Three (ACH Record Format Specifications). Format reference: [Entry/Addenda Count, File Control positions 14–21](https://nacha-navigator.com/nacha-file-format#file-control-entry-addenda-count). #### Entry Hash mismatch Error `FC_ENTRY_HASH` **What it checks.** The file Entry Hash must equal the sum of all RDFI identifications (the sum of the batch hashes), rightmost 10 digits. **How to fix it.** Add up every entry’s RDFI identification (or the batches’ Entry Hash values, once they are right) and write the rightmost 10 digits of the sum in positions 22–31 of the File Control. Source: Nacha Operating Rules, Appendix Three (ACH Record Format Specifications). Format reference: [Entry Hash, File Control positions 22–31](https://nacha-navigator.com/nacha-file-format#file-control-entry-hash). #### Total debit mismatch Error `FC_TOTAL_DEBIT` **What it checks.** The file Total Debit Entry Dollar Amount must equal the sum of all debit entries. **How to fix it.** Write the total of all debit entries in the file, in cents (the sum of the batches’ debit totals), in positions 32–43 of the File Control. Source: Nacha Operating Rules, Appendix Three (ACH Record Format Specifications). Format reference: [Total Debit Entry Dollar Amount in File, File Control positions 32–43](https://nacha-navigator.com/nacha-file-format#file-control-total-debit-entry-dollar-amount). #### Total credit mismatch Error `FC_TOTAL_CREDIT` **What it checks.** The file Total Credit Entry Dollar Amount must equal the sum of all credit entries. **How to fix it.** Write the total of all credit entries in the file, in cents (the sum of the batches’ credit totals), in positions 44–55 of the File Control. Source: Nacha Operating Rules, Appendix Three (ACH Record Format Specifications). Format reference: [Total Credit Entry Dollar Amount in File, File Control positions 44–55](https://nacha-navigator.com/nacha-file-format#file-control-total-credit-entry-dollar-amount). #### File is not padded to a multiple of 10 records Warning `BLOCK_FILL_MISSING` **What it checks.** With a blocking factor of 10, the file is padded with block-fill records (94 nines) to a multiple of 10 records. **How to fix it.** Add block-fill records, 94 nines each, after the File Control until the number of lines is a multiple of 10, and count them in the Block Count. Source: Nacha Operating Rules, Appendix One (ACH File Exchange Specifications). Format reference: [Block-fill records](https://nacha-navigator.com/nacha-file-format#block-fill). #### Too many block-fill records Warning `BLOCK_FILL_EXCESS` **What it checks.** Only enough block-fill records to complete the last block of 10 are needed. **How to fix it.** Delete block-fill records until only enough remain to complete the last block of 10, and update the Block Count to match. Source: Nacha Operating Rules, Appendix One (ACH File Exchange Specifications). Format reference: [Block-fill records](https://nacha-navigator.com/nacha-file-format#block-fill). ### Notes about the list Not a check of the file: a note the viewer adds to its list of issues. #### More issues not listed Note `ISSUES_TRUNCATED` **What it checks.** A rule fired more times than the listing limit; the remaining occurrences are counted, not listed. **How to fix it.** Fix the occurrences that are listed first: one cause, such as a shifted field or an export setting, usually explains the rest. Then open the corrected file again to see what remains. Source: NACHA Navigator (the validator’s own listing limit, not a Nacha rule). ## Sources The checks follow the record formats and file rules in the Nacha Operating Rules: Appendix One (file exchange), Appendix Two (data acceptance by ACH Operators), Appendix Three (record formats), Appendix Four (returns) and Appendix Five (notifications of change). The explanations and fixes on this page are our own. Banks can add requirements of their own, so check your bank’s file specifications too. NACHA Navigator is independent and not affiliated with or endorsed by Nacha. This page is for information only; it is not legal or compliance advice. [Nacha Operating Rules (opens nacha.org in a new tab)](https://www.nacha.org/rules) [Open the NACHA Viewer](https://nacha-navigator.com/) --- URL: https://nacha-navigator.com/ach-transaction-codes # ACH transaction codes Reference The two digits in positions 2–3 of every Entry Detail record: which kind of account the entry posts to, whether it is a credit or a debit, and whether it moves money. Last updated October 30, 2026 Every entry in a NACHA file carries a transaction code. The first digit names the account: checking, savings, general ledger or loan. The second says what the entry does: a live credit or debit, a prenote, a zero-dollar entry that carries remittance data, or a return or notification of change sent back by the receiving bank. So 22 puts money into a checking account and 27 takes money out of one; 32 and 37 do the same for a savings account. ## Reading the two digits ### First digit: the account | Digit | Account | Codes | | --- | --- | --- | | 2 | Checking account (a demand deposit account) | 21–24, 26–29 | | 3 | Savings account | 31–34, 36–39 | | 4 | A general ledger account at the financial institution | 41–44, 46–49 | | 5 | Loan account | 51–56 | | 8 | Not an account: an ACH Operator’s accounting record, only in ADV files | 81–88 | ### Second digit: what the entry is | Digit | What the entry is | Codes | Counts as | | --- | --- | --- | --- | | 1 | Return or notification of change (NOC) of a credit whose code ended in 2, 3 or 4 | 21, 31, 41, 51 | Credit | | 2 | Live credit: puts money into the account | 22, 32, 42, 52 | Credit | | 3 | Prenote of a credit: a $0.00 entry that checks the account first | 23, 33, 43, 53 | Credit | | 4 | Zero-dollar credit that carries remittance data | 24, 34, 44, 54 | Credit | | 5 | Loan debit, used only to reverse a loan credit | 55 | Debit | | 6 | Return or NOC of a debit whose code ended in 7, 8 or 9 (5 for a loan) | 26, 36, 46, 56 | Debit | | 7 | Live debit: takes money from the account | 27, 37, 47 | Debit | | 8 | Prenote of a debit | 28, 38, 48 | Debit | | 9 | Zero-dollar debit that carries remittance data | 29, 39, 49 | Debit | The second digit also decides which control total an entry counts in: codes ending in 1 to 4 are credits and 5 to 9 are debits, in the batch and the file totals alike. The ADV codes 81–88 don’t follow the pattern: each has its own meaning, and the odd ones are credits, the even ones debits. Not every pair of digits is a code. There is no prenote or zero-dollar loan debit, and the only loan debit, 55, exists to reverse a loan credit. A two-digit value that isn’t in the table below is not a transaction code, and the NACHA Viewer reports it as an [invalid Transaction Code](https://nacha-navigator.com/nacha-file-errors#ed-transaction-code). ## Every ACH transaction code All 38 codes, grouped by account, from the same table the NACHA Viewer and its validator use. Each row can be linked to directly: [#code-21](https://nacha-navigator.com/ach-transaction-codes#code-21) goes to 21. | Code | Account | Direction | Kind | Meaning | | --- | --- | --- | --- | --- | | 21 | Checking | Credit | Return or NOC | Return or NOC of a checking credit (original code 22, 23 or 24) | | 22 | Checking | Credit | Live | Checking credit (deposit) | | 23 | Checking | Credit | Prenote | Prenote: checking credit (also DNE and ENR non-dollar entries) | | 24 | Checking | Credit | Zero-dollar | Zero-dollar checking credit with remittance data (CCD, CTX, IAT); ACK and ATX acknowledgments | | 26 | Checking | Debit | Return or NOC | Return or NOC of a checking debit (original code 27, 28 or 29) | | 27 | Checking | Debit | Live | Checking debit (payment) | | 28 | Checking | Debit | Prenote | Prenote: checking debit | | 29 | Checking | Debit | Zero-dollar | Zero-dollar checking debit with remittance data (CCD, CTX, IAT) | | 31 | Savings | Credit | Return or NOC | Return or NOC of a savings credit (original code 32, 33 or 34) | | 32 | Savings | Credit | Live | Savings credit (deposit) | | 33 | Savings | Credit | Prenote | Prenote: savings credit (also DNE and ENR non-dollar entries) | | 34 | Savings | Credit | Zero-dollar | Zero-dollar savings credit with remittance data (CCD, CTX, IAT); ACK and ATX acknowledgments | | 36 | Savings | Debit | Return or NOC | Return or NOC of a savings debit (original code 37, 38 or 39) | | 37 | Savings | Debit | Live | Savings debit (payment) | | 38 | Savings | Debit | Prenote | Prenote: savings debit | | 39 | Savings | Debit | Zero-dollar | Zero-dollar savings debit with remittance data (CCD, CTX, IAT) | | 41 | General ledger | Credit | Return or NOC | Return or NOC of a general ledger credit (original code 42, 43 or 44) | | 42 | General ledger | Credit | Live | General ledger credit (deposit) | | 43 | General ledger | Credit | Prenote | Prenote: general ledger credit | | 44 | General ledger | Credit | Zero-dollar | Zero-dollar general ledger credit with remittance data (CCD, CTX) | | 46 | General ledger | Debit | Return or NOC | Return or NOC of a general ledger debit (original code 47, 48 or 49) | | 47 | General ledger | Debit | Live | General ledger debit (payment) | | 48 | General ledger | Debit | Prenote | Prenote: general ledger debit | | 49 | General ledger | Debit | Zero-dollar | Zero-dollar general ledger debit with remittance data (CCD, CTX) | | 51 | Loan | Credit | Return or NOC | Return or NOC of a loan credit (original code 52, 53 or 54) | | 52 | Loan | Credit | Live | Loan account credit (deposit to a loan) | | 53 | Loan | Credit | Prenote | Prenote: loan credit | | 54 | Loan | Credit | Zero-dollar | Zero-dollar loan credit with remittance data (CCD, CTX) | | 55 | Loan | Debit | Live | Loan account debit (reversals only) | | 56 | Loan | Debit | Return or NOC | Return or NOC of a loan debit (original code 55) | | 81 | Accounting (ADV) | Credit | Accounting advice | ADV: credit for ACH debits originated | | 82 | Accounting (ADV) | Debit | Accounting advice | ADV: debit for ACH credits originated | | 83 | Accounting (ADV) | Credit | Accounting advice | ADV: credit for ACH credits received | | 84 | Accounting (ADV) | Debit | Accounting advice | ADV: debit for ACH debits received | | 85 | Accounting (ADV) | Credit | Accounting advice | ADV: credit for ACH credits in rejected batches | | 86 | Accounting (ADV) | Debit | Accounting advice | ADV: debit for ACH debits in rejected batches | | 87 | Accounting (ADV) | Credit | Accounting advice | ADV: summary credit for respondent ACH activity | | 88 | Accounting (ADV) | Debit | Accounting advice | ADV: summary debit for respondent ACH activity | ## Where the code goes in a file The transaction code is [positions 2–3 of the Entry Detail record](https://nacha-navigator.com/nacha-file-format#entry-ppd-transaction-code), right after the record type 6. It is mandatory, and it sits in the same place whatever the batch’s SEC code. Here it is in line 3 of the PPD sample file: ``` 6220655033481111111 0000000010000001309 JOHN M SMITH 0065503680000001 ``` Record type 6, then transaction code 22: a live credit to a checking account, here for $0.10. ### What the code has to agree with - **The batch’s Service Class Code** (positions 2–4 of the [Company/Batch Header](https://nacha-navigator.com/nacha-file-format#batch-header)): a [220](https://nacha-navigator.com/nacha-file-format#service-class-220) batch holds only credits, a [225](https://nacha-navigator.com/nacha-file-format#service-class-225) batch only debits, and a 200 batch both. A code on the wrong side is an error: [entry direction does not match the Service Class Code](https://nacha-navigator.com/nacha-file-errors#ed-service-class-mismatch). - **The batch’s SEC code:** ARC, BOC, POP, RCK, TEL, TRC, TRX and XCK entries are debits, CIE entries are credits, ACK and ATX acknowledgments use 24 or 34, ENR enrollments use 23 or 33, COR entries use the return and NOC codes, and ADV batches use 81–88. A reversing entry may go the other way under ARC, BOC, POP, RCK, TEL, XCK and CIE. See [Transaction Code not allowed for the SEC code](https://nacha-navigator.com/nacha-file-errors#ed-transaction-code-sec). - **The amount:** prenotes and zero-dollar entries must be $0.00 ([prenote with an amount](https://nacha-navigator.com/nacha-file-errors#ed-prenote-amount), [zero-dollar entry with an amount](https://nacha-navigator.com/nacha-file-errors#ed-zero-dollar-amount)), and a live code with $0.00 gets a warning ([live entry for $0.00](https://nacha-navigator.com/nacha-file-errors#ed-live-zero-amount)). - **Its addenda:** a type 98 (notification of change) or type 99 (return) addenda may follow only an entry with a return or NOC code ([return addenda on a non-return entry](https://nacha-navigator.com/nacha-file-errors#ad-return-entry-code)). ## Prenotes and zero-dollar entries Live codes move money, and a return moves the original entry’s amount back. Every code is one of these kinds: **Kinds of transaction code and what each does with the amount** | Kind | Codes | Amount | | --- | --- | --- | | Live | 22, 27, 32, 37, 42, 47, 52, 55 | Moves money | | Prenote | 23, 28, 33, 38, 43, 48, 53 | Always $0.00 | | Zero-dollar | 24, 29, 34, 39, 44, 49, 54 | Always $0.00; remittance data goes in addenda records | | Return or NOC | 21, 26, 31, 36, 41, 46, 51, 56 | The amount being returned; $0.00 on a notification of change | | Accounting advice | 81–88 | Reports an amount but moves no money | ### Prenotes A prenote (prenotification) is a $0.00 entry with a code ending in 3 or 8: 23, 28, 33, 38, 43, 48, 53. An Originator can send one to test a routing and account number before the first live entry. Live entries may then start from the third banking day after the prenote’s settlement date if no return came back for it; if a notification of change came back, its correction comes first. ENR enrollments and DNE death notifications use 23 and 33 as well, without being prenotes. ### Zero-dollar entries A code ending in 4 or 9 (24, 29, 34, 39, 44, 49, 54) marks a zero-dollar entry: it carries remittance data in its addenda records instead of money. The [table of every code](https://nacha-navigator.com/ach-transaction-codes#all-codes) names the SEC codes that may use each one. ACK and ATX acknowledgments, which an RDFI sends back for a CCD or CTX credit, use 24 and 34. The NACHA Viewer warns about a zero-dollar entry with no addenda ([zero-dollar entry without remittance](https://nacha-navigator.com/nacha-file-errors#ed-zero-dollar-addenda)). ## Returns and notifications of change When an RDFI returns an entry or sends a notification of change (NOC), the entry it sends back carries the return or NOC code of the same account: 21 for a checking credit (22, 23 or 24), 26 for a checking debit (27, 28 or 29), and so on up to 56, for a loan debit (55). The reason travels in an addenda record: [type 99](https://nacha-navigator.com/nacha-file-format#addenda-99) with a [return reason code](https://nacha-navigator.com/nacha-file-format#return-reason-codes) for a return, [type 98](https://nacha-navigator.com/nacha-file-format#addenda-98) with a [change code](https://nacha-navigator.com/nacha-file-format#change-codes) for a NOC. Three change codes correct the transaction code itself, in the Corrected Data of the NOC: - [C05](https://nacha-navigator.com/nacha-file-format#noc-c05) Incorrect Transaction Code: correct Transaction Code in the first 2 positions. - [C06](https://nacha-navigator.com/nacha-file-format#noc-c06) Incorrect DFI Account Number and Incorrect Transaction Code: correct DFI Account Number in positions 1–17, three blanks (18–20), then the correct Transaction Code in 21–22. - [C07](https://nacha-navigator.com/nacha-file-format#noc-c07) Incorrect Routing Number, Incorrect DFI Account Number, and Incorrect Transaction Code: correct routing number (9), DFI Account Number (17) and Transaction Code (2). ## Reversals A reversing entry moves the same amount back the other way, on the same kind of account. So it uses the other live code of its account: a credit is reversed with that account’s debit code, and a debit with its credit code. **Transaction codes that reverse each other** | Account | Live credit | Live debit | | --- | --- | --- | | Checking | 22 | 27 | | Savings | 32 | 37 | | General ledger | 42 | 47 | | Loan | 52 | 55 | Prenotes, zero-dollar entries, NOCs and ADV records move no money, so there is nothing to reverse. A return is the Receiver’s bank sending an entry back, not an entry the Originator can reverse; an ODFI answers a faulty return by [dishonoring it](https://nacha-navigator.com/nacha-file-format#addenda-99-dishonored) (R61, R62, R67–R70). [ACH Reversal](https://nacha-navigator.com/ach-reversal) builds the reversing file from your original file, with the codes swapped and REVERSAL as the entry description. ## See them in a file The sample files open in the NACHA Viewer, which names each entry’s code and checks it: - [PPD payroll](https://nacha-navigator.com/?sample=ppd): prenotes to checking (23) and savings (33), and a live checking credit (22). - [CCD vendor payments](https://nacha-navigator.com/?sample=ccd-addenda): a credits-only and a debits-only batch (Service Class Codes 220 and 225), and a zero-dollar remittance entry (24). - [Returns and notifications of change](https://nacha-navigator.com/?sample=returns-noc): return codes 21, 26 and 36, and a C05 that corrects a transaction code. - [Validation demo](https://nacha-navigator.com/?sample=with-errors): among its deliberate problems, a prenote with an amount and a debit in a credits-only batch. To make a file, the [NACHA Generator](https://nacha-navigator.com/nacha-generator) picks the code from the account type, credit or debit, and whether the entry is a prenote: 22, 23, 27, 28, 32, 33, 37 and 38. The [sample files](https://nacha-navigator.com/sample-files) page lists every sample, ready to download. NACHA Navigator is independent and not affiliated with or endorsed by Nacha. This page describes the record format for general information; it is not legal or compliance advice. The [Nacha Operating Rules](https://www.nacha.org/rules) are the authority, and they change every year. --- URL: https://nacha-navigator.com/bai2-type-codes # BAI2 type codes BAI2 reference All 469 type codes of the BAI2 specification, each with its level and direction, plus 10 codes from outside the list that the BAI2 Viewer also recognizes. Last updated October 30, 2026 [Open the BAI2 Viewer](https://nacha-navigator.com/bai2-viewer) [BAI2 file format](https://nacha-navigator.com/bai2-file-format) ## Where type codes go A BAI2 file reports each amount with a three-digit type code that says what the amount is: a balance, a total, or one transaction. The level of the code decides which record it belongs in. **Type code levels and the records that carry them** | Level | Record | What the amount is | Codes | | --- | --- | --- | --- | | Status | [03](https://nacha-navigator.com/bai2-file-format#record-03) | A balance, reported in the 03 Account Identifier record. | 54 | | Summary | [03](https://nacha-navigator.com/bai2-file-format#record-03) | A total of credits or debits, reported in the 03 record with an optional item count. | 155 | | Detail | [16](https://nacha-navigator.com/bai2-file-format#record-16) | One transaction, reported in a 16 Transaction Detail record. | 260 | **In an 03 Account Identifier record** the codes come in groups of four fields: type code, amount, item count and funds type. Status codes report balances and leave the item count and funds type empty; summary codes report a total and may say how many items it covers. This 03 opens with the opening and closing ledger balances (010 and 015), then total credits (100: 2,325.00 in 2 items) and total debits (400: 750.00 in 1 item): ``` 03,0012345678,USD,010,1250000,,,015,1407500,,,100,232500,2,,400,75000,1,/ ``` **In a 16 Transaction Detail record** the type code is the second field and names one transaction. Here 475 is Check Paid, a debit of 750.00, with the check number 1043 as the customer reference: ``` 16,475,75000,,,1043,CHECK 1043 ``` Amounts have no decimal point: the currency sets the implied decimals, two for USD. Codes 100 to 399 are credits and 400 to 699 debits; 700 to 799 hold loan balances and loan transactions; 890 carries a message instead of an amount; and 900 to 999 are left to each bank. The full field layouts are on the BAI2 file format page, under [Account Identifier (03)](https://nacha-navigator.com/bai2-file-format#record-03) and [Transaction Detail (16)](https://nacha-navigator.com/bai2-file-format#record-16), and the [BAI2 Viewer](https://nacha-navigator.com/bai2-viewer) shows the type code of every amount in a file you open. Both lines above come from an example file explained line by line on the [format page](https://nacha-navigator.com/bai2-file-format#example). A detail code in an 03 or a status code in a 16 is a mistake the viewer reports; see the check `code.type-code-level` under [validation checks](https://nacha-navigator.com/bai2-file-format#rule-code.type-code-level). ## The 469 BAI2 type codes In code order and grouped by range, as the BAI2 specification lists them: 54 status codes, 155 summary codes and 260 detail codes. The level says which record carries the code and the direction whether money came in or went out; status codes are balances and have no direction. ### 001–099: Account status (balances) Balances such as ledger, available and float, reported in the 03 record. The amount may be signed; item count and funds type are left blank. 49 codes. **BAI2 type codes 001–099: Account status (balances)** | Code | Description | Level | Direction | | --- | --- | --- | --- | | 010 | Opening Ledger | Status | – | | 011 | Average Opening Ledger MTD | Status | – | | 012 | Average Opening Ledger YTD | Status | – | | 015 | Closing Ledger | Status | – | | 020 | Average Closing Ledger MTD | Status | – | | 021 | Average Closing Ledger – Previous Month | Status | – | | 022 | Aggregate Balance Adjustments | Status | – | | 024 | Average Closing Ledger YTD – Previous Month | Status | – | | 025 | Average Closing Ledger YTD | Status | – | | 030 | Current Ledger | Status | – | | 037 | ACH Net Position | Status | – | | 039 | Opening Available + Total Same-Day ACH DTC Deposit | Status | – | | 040 | Opening Available | Status | – | | 041 | Average Opening Available MTD | Status | – | | 042 | Average Opening Available YTD | Status | – | | 043 | Average Available – Previous Month | Status | – | | 044 | Disbursing Opening Available Balance | Status | – | | 045 | Closing Available | Status | – | | 050 | Average Closing Available MTD | Status | – | | 051 | Average Closing Available – Last Month | Status | – | | 054 | Average Closing Available YTD – Last Month | Status | – | | 055 | Average Closing Available YTD | Status | – | | 056 | Loan Balance | Status | – | | 057 | Total Investment Position | Status | – | | 059 | Current Available (CRS Suppressed) | Status | – | | 060 | Current Available | Status | – | | 061 | Average Current Available MTD | Status | – | | 062 | Average Current Available YTD | Status | – | | 063 | Total Float | Status | – | | 065 | Target Balance | Status | – | | 066 | Adjusted Balance | Status | – | | 067 | Adjusted Balance MTD | Status | – | | 068 | Adjusted Balance YTD | Status | – | | 070 | 0-Day Float | Status | – | | 072 | 1-Day Float | Status | – | | 073 | Float Adjustment | Status | – | | 074 | 2 or More Days Float | Status | – | | 075 | 3 or More Days Float | Status | – | | 076 | Adjustment to Balances | Status | – | | 077 | Average Adjustment to Balances MTD | Status | – | | 078 | Average Adjustment to Balances YTD | Status | – | | 079 | 4-Day Float | Status | – | | 080 | 5-Day Float | Status | – | | 081 | 6-Day Float | Status | – | | 082 | Average 1-Day Float MTD | Status | – | | 083 | Average 1-Day Float YTD | Status | – | | 084 | Average 2-Day Float MTD | Status | – | | 085 | Average 2-Day Float YTD | Status | – | | 086 | Transfer Calculation | Status | – | ### 100–399: Credits (summary and detail) Credits. Summary codes (100 is Total Credits) go in the 03 record; detail codes go in 16 records, one transaction each. 206 codes. **BAI2 type codes 100–399: Credits (summary and detail)** | Code | Description | Level | Direction | | --- | --- | --- | --- | | 100 | Total Credits | Summary | Credit | | 101 | Total Credit Amount MTD | Summary | Credit | | 105 | Credits Not Detailed | Summary | Credit | | 106 | Deposits Subject to Float | Summary | Credit | | 107 | Total Adjustment Credits YTD | Summary | Credit | | 108 | Credit (Any Type) | Detail | Credit | | 109 | Current Day Total Lockbox Deposits | Summary | Credit | | 110 | Total Lockbox Deposits | Summary | Credit | | 115 | Lockbox Deposit | Detail | Credit | | 116 | Item in Lockbox Deposit | Detail | Credit | | 118 | Lockbox Adjustment Credit | Detail | Credit | | 120 | EDI Transaction Credit | Summary | Credit | | 121 | EDI Transaction Credit | Detail | Credit | | 122 | EDIBANX Credit Received | Detail | Credit | | 123 | EDIBANX Credit Return | Detail | Credit | | 130 | Total Concentration Credits | Summary | Credit | | 131 | Total DTC Credits | Summary | Credit | | 135 | DTC Concentration Credit | Detail | Credit | | 136 | Item in DTC Deposit | Detail | Credit | | 140 | Total ACH Credits | Summary | Credit | | 142 | ACH Credit Received | Detail | Credit | | 143 | Item in ACH Deposit | Detail | Credit | | 145 | ACH Concentration Credit | Detail | Credit | | 146 | Total Bank Card Deposits | Summary | Credit | | 147 | Individual Bank Card Deposit | Detail | Credit | | 150 | Total Preauthorized Payment Credits | Summary | Credit | | 155 | Preauthorized Draft Credit | Detail | Credit | | 156 | Item in PAC Deposit | Detail | Credit | | 160 | Total ACH Disbursing Funding Credits | Summary | Credit | | 162 | Corporate Trade Payment Settlement | Summary | Credit | | 163 | Corporate Trade Payment Credits | Summary | Credit | | 164 | Corporate Trade Payment Credit | Detail | Credit | | 165 | Preauthorized ACH Credit | Detail | Credit | | 166 | ACH Settlement | Detail | Credit | | 167 | ACH Settlement Credits | Summary | Credit | | 168 | ACH Return Item or Adjustment Settlement | Detail | Credit | | 169 | Miscellaneous ACH Credit | Detail | Credit | | 170 | Total Other Check Deposits | Summary | Credit | | 171 | Individual Loan Deposit | Detail | Credit | | 172 | Deposit Correction | Detail | Credit | | 173 | Bank-Prepared Deposit | Detail | Credit | | 174 | Other Deposit | Detail | Credit | | 175 | Check Deposit Package | Detail | Credit | | 176 | Re-presented Check Deposit | Detail | Credit | | 178 | List Post Credits | Summary | Credit | | 180 | Total Loan Proceeds | Summary | Credit | | 182 | Total Bank-Prepared Deposits | Summary | Credit | | 184 | Draft Deposit | Detail | Credit | | 185 | Total Miscellaneous Deposits | Summary | Credit | | 186 | Total Cash Letter Credits | Summary | Credit | | 187 | Cash Letter Credit | Detail | Credit | | 188 | Total Cash Letter Adjustments | Summary | Credit | | 189 | Cash Letter Adjustment | Detail | Credit | | 190 | Total Incoming Money Transfers | Summary | Credit | | 191 | Individual Incoming Internal Money Transfer | Detail | Credit | | 195 | Incoming Money Transfer | Detail | Credit | | 196 | Money Transfer Adjustment | Detail | Credit | | 198 | Compensation | Detail | Credit | | 200 | Total Automatic Transfer Credits | Summary | Credit | | 201 | Individual Automatic Transfer Credit | Detail | Credit | | 202 | Bond Operations Credit | Detail | Credit | | 205 | Total Book Transfer Credits | Summary | Credit | | 206 | Book Transfer Credit | Detail | Credit | | 207 | Total International Money Transfer Credits | Summary | Credit | | 208 | Individual International Money Transfer Credit | Detail | Credit | | 210 | Total International Credits | Summary | Credit | | 212 | Foreign Letter of Credit | Detail | Credit | | 213 | Letter of Credit | Detail | Credit | | 214 | Foreign Exchange of Credit | Detail | Credit | | 215 | Total Letters of Credit | Summary | Credit | | 216 | Foreign Remittance Credit | Detail | Credit | | 218 | Foreign Collection Credit | Detail | Credit | | 221 | Foreign Check Purchase | Detail | Credit | | 222 | Foreign Checks Deposited | Detail | Credit | | 224 | Commission | Detail | Credit | | 226 | International Money Market Trading | Detail | Credit | | 227 | Standing Order | Detail | Credit | | 229 | Miscellaneous International Credit | Detail | Credit | | 230 | Total Security Credits | Summary | Credit | | 231 | Total Collection Credits | Summary | Credit | | 232 | Sale of Debt Security | Detail | Credit | | 233 | Securities Sold | Detail | Credit | | 234 | Sale of Equity Security | Detail | Credit | | 235 | Matured Reverse Repurchase Order | Detail | Credit | | 236 | Maturity of Debt Security | Detail | Credit | | 237 | Individual Collection Credit | Detail | Credit | | 238 | Collection of Dividends | Detail | Credit | | 239 | Total Bankers’ Acceptance Credits | Summary | Credit | | 240 | Coupon Collections – Banks | Detail | Credit | | 241 | Bankers’ Acceptances | Detail | Credit | | 242 | Collection of Interest Income | Detail | Credit | | 243 | Matured Fed Funds Purchased | Detail | Credit | | 244 | Interest/Matured Principal Payment | Detail | Credit | | 245 | Monthly Dividends | Summary | Credit | | 246 | Commercial Paper | Detail | Credit | | 247 | Capital Change | Detail | Credit | | 248 | Savings Bonds Sales Adjustment | Detail | Credit | | 249 | Miscellaneous Security Credit | Detail | Credit | | 250 | Total Checks Posted and Returned | Summary | Credit | | 251 | Total Debit Reversals | Summary | Credit | | 252 | Debit Reversal | Detail | Credit | | 254 | Posting Error Correction Credit | Detail | Credit | | 255 | Check Posted and Returned | Detail | Credit | | 256 | Total ACH Return Items | Summary | Credit | | 257 | Individual ACH Return Item | Detail | Credit | | 258 | ACH Reversal Credit | Detail | Credit | | 260 | Total Rejected Credits | Summary | Credit | | 261 | Individual Rejected Credit | Detail | Credit | | 263 | Overdraft | Detail | Credit | | 266 | Return Item | Detail | Credit | | 268 | Return Item Adjustment | Detail | Credit | | 270 | Total ZBA Credits | Summary | Credit | | 271 | Net Zero-Balance Amount | Summary | Credit | | 274 | Cumulative ZBA or Disbursement Credits | Detail | Credit | | 275 | ZBA Credit | Detail | Credit | | 276 | ZBA Float Adjustment | Detail | Credit | | 277 | ZBA Credit Transfer | Detail | Credit | | 278 | ZBA Credit Adjustment | Detail | Credit | | 280 | Total Controlled Disbursing Credits | Summary | Credit | | 281 | Individual Controlled Disbursing Credit | Detail | Credit | | 285 | Total DTC Disbursing Credits | Summary | Credit | | 286 | Individual DTC Disbursing Credit | Detail | Credit | | 294 | Total ATM Credits | Summary | Credit | | 295 | ATM Credit | Detail | Credit | | 301 | Commercial Deposit | Detail | Credit | | 302 | Correspondent Bank Deposit | Summary | Credit | | 303 | Total Wire Transfers In – FF | Summary | Credit | | 304 | Total Wire Transfers In – CHF | Summary | Credit | | 305 | Total Fed Funds Sold | Summary | Credit | | 306 | Fed Funds Sold | Detail | Credit | | 307 | Total Trust Credits | Summary | Credit | | 308 | Trust Credit | Detail | Credit | | 309 | Total Value - Dated Funds | Summary | Credit | | 310 | Total Commercial Deposits | Summary | Credit | | 315 | Total International Credits – FF | Summary | Credit | | 316 | Total International Credits – CHF | Summary | Credit | | 318 | Total Foreign Check Purchased | Summary | Credit | | 319 | Late Deposit | Summary | Credit | | 320 | Total Securities Sold – FF | Summary | Credit | | 321 | Total Securities Sold – CHF | Summary | Credit | | 324 | Total Securities Matured – FF | Summary | Credit | | 325 | Total Securities Matured – CHF | Summary | Credit | | 326 | Total Securities Interest | Summary | Credit | | 327 | Total Securities Matured | Summary | Credit | | 328 | Total Securities Interest – FF | Summary | Credit | | 329 | Total Securities Interest – CHF | Summary | Credit | | 330 | Total Escrow Credits | Summary | Credit | | 331 | Individual Escrow Credit | Detail | Credit | | 332 | Total Miscellaneous Securities Credits – FF | Summary | Credit | | 336 | Total Miscellaneous Securities Credits – CHF | Summary | Credit | | 338 | Total Securities Sold | Summary | Credit | | 340 | Total Broker Deposits | Summary | Credit | | 341 | Total Broker Deposits – FF | Summary | Credit | | 342 | Broker Deposit | Detail | Credit | | 343 | Total Broker Deposits – CHF | Summary | Credit | | 344 | Individual Back Value Credit | Detail | Credit | | 345 | Item in Brokers Deposit | Detail | Credit | | 346 | Sweep Interest Income | Detail | Credit | | 347 | Sweep Principal Sell | Detail | Credit | | 348 | Futures Credit | Detail | Credit | | 349 | Principal Payments Credit | Detail | Credit | | 350 | Investment Sold | Summary | Credit | | 351 | Individual Investment Sold | Detail | Credit | | 352 | Total Cash Center Credits | Summary | Credit | | 353 | Cash Center Credit | Detail | Credit | | 354 | Interest Credit | Detail | Credit | | 355 | Investment Interest | Summary | Credit | | 356 | Total Credit Adjustment | Summary | Credit | | 357 | Credit Adjustment | Detail | Credit | | 358 | YTD Adjustment Credit | Detail | Credit | | 359 | Interest Adjustment Credit | Detail | Credit | | 360 | Total Credits Less Wire Transfer and Returned Checks | Summary | Credit | | 361 | Grand Total Credits Less Grand Total Debits | Summary | Credit | | 362 | Correspondent Collection | Detail | Credit | | 363 | Correspondent Collection Adjustment | Detail | Credit | | 364 | Loan Participation | Detail | Credit | | 366 | Currency and Coin Deposited | Detail | Credit | | 367 | Food Stamp Letter | Detail | Credit | | 368 | Food Stamp Adjustment | Detail | Credit | | 369 | Clearing Settlement Credit | Detail | Credit | | 370 | Total Back Value Credits | Summary | Credit | | 372 | Back Value Adjustment | Detail | Credit | | 373 | Customer Payroll | Detail | Credit | | 374 | FRB Statement Recap | Detail | Credit | | 376 | Savings Bond Letter or Adjustment | Detail | Credit | | 377 | Treasury Tax and Loan Credit | Detail | Credit | | 378 | Transfer of Treasury Credit | Detail | Credit | | 379 | FRB Government Checks Cash Letter Credit | Detail | Credit | | 381 | FRB Government Check Adjustment | Detail | Credit | | 382 | FRB Postal Money Order Credit | Detail | Credit | | 383 | FRB Postal Money Order Adjustment | Detail | Credit | | 384 | FRB Cash Letter Auto Charge Credit | Detail | Credit | | 385 | Total Universal Credits | Summary | Credit | | 386 | FRB Cash Letter Auto Charge Adjustment | Detail | Credit | | 387 | FRB Fine-Sort Cash Letter Credit | Detail | Credit | | 388 | FRB Fine-Sort Adjustment | Detail | Credit | | 389 | Total Freight Payment Credits | Summary | Credit | | 390 | Total Miscellaneous Credits | Summary | Credit | | 391 | Universal Credit | Detail | Credit | | 392 | Freight Payment Credit | Detail | Credit | | 393 | Itemized Credit Over $10,000 | Detail | Credit | | 394 | Cumulative Credits | Detail | Credit | | 395 | Check Reversal | Detail | Credit | | 397 | Float Adjustment | Detail | Credit | | 398 | Miscellaneous Fee Refund | Detail | Credit | | 399 | Miscellaneous Credit | Detail | Credit | ### 400–699: Debits (summary and detail) Debits. Summary codes (400 is Total Debits) go in the 03 record; detail codes go in 16 records, one transaction each. 198 codes. **BAI2 type codes 400–699: Debits (summary and detail)** | Code | Description | Level | Direction | | --- | --- | --- | --- | | 400 | Total Debits | Summary | Debit | | 401 | Total Debit Amount MTD | Summary | Debit | | 403 | Today’s Total Debits | Summary | Debit | | 405 | Total Debit Less Wire Transfers and Charge-Backs | Summary | Debit | | 406 | Debits not Detailed | Summary | Debit | | 408 | Float Adjustment | Detail | Debit | | 409 | Debit (Any Type) | Detail | Debit | | 410 | Total YTD Adjustment | Summary | Debit | | 412 | Total Debits (Excluding Returned Items) | Summary | Debit | | 415 | Lockbox Debit | Detail | Debit | | 416 | Total Lockbox Debits | Summary | Debit | | 420 | EDI Transaction Debits | Summary | Debit | | 421 | EDI Transaction Debit | Detail | Debit | | 422 | EDIBANX Settlement Debit | Detail | Debit | | 423 | EDIBANX Return Item Debit | Detail | Debit | | 430 | Total Payable–Through Drafts | Summary | Debit | | 435 | Payable–Through Draft | Detail | Debit | | 445 | ACH Concentration Debit | Detail | Debit | | 446 | Total ACH Disbursement Funding Debits | Summary | Debit | | 447 | ACH Disbursement Funding Debit | Detail | Debit | | 450 | Total ACH Debits | Summary | Debit | | 451 | ACH Debit Received | Detail | Debit | | 452 | Item in ACH Disbursement or Debit | Detail | Debit | | 455 | Preauthorized ACH Debit | Detail | Debit | | 462 | Account Holder Initiated ACH Debit | Detail | Debit | | 463 | Corporate Trade Payment Debits | Summary | Debit | | 464 | Corporate Trade Payment Debit | Detail | Debit | | 465 | Corporate Trade Payment Settlement | Summary | Debit | | 466 | ACH Settlement | Detail | Debit | | 467 | ACH Settlement Debits | Summary | Debit | | 468 | ACH Return Item or Adjustment Settlement | Detail | Debit | | 469 | Miscellaneous ACH Debit | Detail | Debit | | 470 | Total Check Paid | Summary | Debit | | 471 | Total Check Paid – Cumulative MTD | Summary | Debit | | 472 | Cumulative Checks Paid | Detail | Debit | | 474 | Certified Check Debit | Detail | Debit | | 475 | Check Paid | Detail | Debit | | 476 | Federal Reserve Bank Letter Debit | Detail | Debit | | 477 | Bank Originated Debit | Detail | Debit | | 478 | List Post Debits | Summary | Debit | | 479 | List Post Debit | Detail | Debit | | 480 | Total Loan Payments | Summary | Debit | | 481 | Individual Loan Payment | Detail | Debit | | 482 | Total Bank-Originated Debits | Summary | Debit | | 484 | Draft | Detail | Debit | | 485 | DTC Debit | Detail | Debit | | 486 | Total Cash Letter Debits | Summary | Debit | | 487 | Cash Letter Debit | Detail | Debit | | 489 | Cash Letter Adjustment | Detail | Debit | | 490 | Total Outgoing Money Transfers | Summary | Debit | | 491 | Individual Outgoing Internal Money Transfer | Detail | Debit | | 493 | Customer Terminal Initiated Money Transfer | Detail | Debit | | 495 | Outgoing Money Transfer | Detail | Debit | | 496 | Money Transfer Adjustment | Detail | Debit | | 498 | Compensation | Detail | Debit | | 500 | Total Automatic Transfer Debits | Summary | Debit | | 501 | Individual Automatic Transfer Debit | Detail | Debit | | 502 | Bond Operations Debit | Detail | Debit | | 505 | Total Book Transfer Debits | Summary | Debit | | 506 | Book Transfer Debit | Detail | Debit | | 507 | Total International Money Transfer Debits | Summary | Debit | | 508 | Individual International Money Transfer Debits | Detail | Debit | | 510 | Total International Debits | Summary | Debit | | 512 | Letter of Credit Debit | Detail | Debit | | 513 | Letter of Credit | Detail | Debit | | 514 | Foreign Exchange Debit | Detail | Debit | | 515 | Total Letters of Credit | Summary | Debit | | 516 | Foreign Remittance Debit | Detail | Debit | | 518 | Foreign Collection Debit | Detail | Debit | | 522 | Foreign Checks Paid | Detail | Debit | | 524 | Commission | Detail | Debit | | 526 | International Money Market Trading | Detail | Debit | | 527 | Standing Order | Detail | Debit | | 529 | Miscellaneous International Debit | Detail | Debit | | 530 | Total Security Debits | Summary | Debit | | 531 | Securities Purchased | Detail | Debit | | 532 | Total Amount of Securities Purchased | Summary | Debit | | 533 | Security Collection Debit | Detail | Debit | | 534 | Total Miscellaneous Securities DB – FF | Summary | Debit | | 535 | Purchase of Equity Securities | Detail | Debit | | 536 | Total Miscellaneous Securities Debit – CHF | Summary | Debit | | 537 | Total Collection Debit | Summary | Debit | | 538 | Matured Repurchase Order | Detail | Debit | | 539 | Total Bankers’ Acceptances Debit | Summary | Debit | | 540 | Coupon Collection Debit | Detail | Debit | | 541 | Bankers’ Acceptances | Detail | Debit | | 542 | Purchase of Debt Securities | Detail | Debit | | 543 | Domestic Collection | Detail | Debit | | 544 | Interest/Matured Principal Payment | Detail | Debit | | 546 | Commercial paper | Detail | Debit | | 547 | Capital Change | Detail | Debit | | 548 | Savings Bonds Sales Adjustment | Detail | Debit | | 549 | Miscellaneous Security Debit | Detail | Debit | | 550 | Total Deposited Items Returned | Summary | Debit | | 551 | Total Credit Reversals | Summary | Debit | | 552 | Credit Reversal | Detail | Debit | | 554 | Posting Error Correction Debit | Detail | Debit | | 555 | Deposited Item Returned | Detail | Debit | | 556 | Total ACH Return Items | Summary | Debit | | 557 | Individual ACH Return Item | Detail | Debit | | 558 | ACH Reversal Debit | Detail | Debit | | 560 | Total Rejected Debits | Summary | Debit | | 561 | Individual Rejected Debit | Detail | Debit | | 563 | Overdraft | Detail | Debit | | 564 | Overdraft Fee | Detail | Debit | | 566 | Return Item | Detail | Debit | | 567 | Return Item Fee | Detail | Debit | | 568 | Return Item Adjustment | Detail | Debit | | 570 | Total ZBA Debits | Summary | Debit | | 574 | Cumulative ZBA Debits | Detail | Debit | | 575 | ZBA Debit | Detail | Debit | | 577 | ZBA Debit Transfer | Detail | Debit | | 578 | ZBA Debit Adjustment | Detail | Debit | | 580 | Total Controlled Disbursing Debits | Summary | Debit | | 581 | Individual Controlled Disbursing Debit | Detail | Debit | | 583 | Total Disbursing Checks Paid – Early Amount | Summary | Debit | | 584 | Total Disbursing Checks Paid – Later Amount | Summary | Debit | | 585 | Disbursing Funding Requirement | Summary | Debit | | 586 | FRB Presentment Estimate (Fed Estimate) | Summary | Debit | | 587 | Late Debits (After Notification) | Summary | Debit | | 588 | Total Disbursing Checks Paid-Last Amount | Summary | Debit | | 590 | Total DTC Debits | Summary | Debit | | 594 | Total ATM Debits | Summary | Debit | | 595 | ATM Debit | Detail | Debit | | 596 | Total ARP Debits | Summary | Debit | | 597 | ARP Debit | Detail | Debit | | 601 | Estimated Total Disbursement | Summary | Debit | | 602 | Adjusted Total Disbursement | Summary | Debit | | 610 | Total Funds Required | Summary | Debit | | 611 | Total Wire Transfers Out- CHF | Summary | Debit | | 612 | Total Wire Transfers Out – FF | Summary | Debit | | 613 | Total International Debit – CHF | Summary | Debit | | 614 | Total International Debit – FF | Summary | Debit | | 615 | Total Federal Reserve Bank – Commercial Bank Debit | Summary | Debit | | 616 | Federal Reserve Bank – Commercial Bank Debit | Detail | Debit | | 617 | Total Securities Purchased – CHF | Summary | Debit | | 618 | Total Securities Purchased – FF | Summary | Debit | | 621 | Total Broker Debits – CHF | Summary | Debit | | 622 | Broker Debit | Detail | Debit | | 623 | Total Broker Debits – FF | Summary | Debit | | 625 | Total Broker Debits | Summary | Debit | | 626 | Total Fed Funds Purchased | Summary | Debit | | 627 | Fed Funds Purchased | Detail | Debit | | 628 | Total Cash Center Debits | Summary | Debit | | 629 | Cash Center Debit | Detail | Debit | | 630 | Total Debit Adjustments | Summary | Debit | | 631 | Debit Adjustment | Detail | Debit | | 632 | Total Trust Debits | Summary | Debit | | 633 | Trust Debit | Detail | Debit | | 634 | YTD Adjustment Debit | Detail | Debit | | 640 | Total Escrow Debits | Summary | Debit | | 641 | Individual Escrow Debit | Detail | Debit | | 644 | Individual Back Value Debit | Detail | Debit | | 646 | Transfer Calculation Debit | Summary | Debit | | 650 | Investments Purchased | Summary | Debit | | 651 | Individual Investment purchased | Detail | Debit | | 654 | Interest Debit | Detail | Debit | | 655 | Total Investment Interest Debits | Summary | Debit | | 656 | Sweep Principal Buy | Detail | Debit | | 657 | Futures Debit | Detail | Debit | | 658 | Principal Payments Debit | Detail | Debit | | 659 | Interest Adjustment Debit | Detail | Debit | | 661 | Account Analysis Fee | Detail | Debit | | 662 | Correspondent Collection Debit | Detail | Debit | | 663 | Correspondent Collection Adjustment | Detail | Debit | | 664 | Loan Participation | Detail | Debit | | 665 | Intercept Debits | Summary | Debit | | 666 | Currency and Coin Shipped | Detail | Debit | | 667 | Food Stamp Letter | Detail | Debit | | 668 | Food Stamp Adjustment | Detail | Debit | | 669 | Clearing Settlement Debit | Detail | Debit | | 670 | Total Back Value Debits | Summary | Debit | | 672 | Back Value Adjustment | Detail | Debit | | 673 | Customer Payroll | Detail | Debit | | 674 | FRB Statement Recap | Detail | Debit | | 676 | Savings Bond Letter or Adjustment | Detail | Debit | | 677 | Treasury Tax and Loan Debit | Detail | Debit | | 678 | Transfer of Treasury Debit | Detail | Debit | | 679 | FRB Government Checks Cash Letter Debit | Detail | Debit | | 681 | FRB Government Check Adjustment | Detail | Debit | | 682 | FRB Postal Money Order Debit | Detail | Debit | | 683 | FRB Postal Money Order Adjustment | Detail | Debit | | 684 | FRB Cash Letter Auto Charge Debit | Detail | Debit | | 685 | Total Universal Debits | Summary | Debit | | 686 | FRB Cash Letter Auto Charge Adjustment | Detail | Debit | | 687 | FRB Fine-Sort Cash Letter Debit | Detail | Debit | | 688 | FRB Fine-Sort Adjustment | Detail | Debit | | 689 | FRB Freight Payment Debits | Summary | Debit | | 690 | Total Miscellaneous Debits | Summary | Debit | | 691 | Universal Debit | Detail | Debit | | 692 | Freight Payment Debit | Detail | Debit | | 693 | Itemized Debit Over $10,000 | Detail | Debit | | 694 | Deposit Reversal | Detail | Debit | | 695 | Deposit Correction Debit | Detail | Debit | | 696 | Regular Collection Debit | Detail | Debit | | 697 | Cumulative Debits | Detail | Debit | | 698 | Miscellaneous Fees | Detail | Debit | | 699 | Miscellaneous Debit | Detail | Debit | ### 700–799: Loan transactions Loans: status codes 701–709, credit codes 720–728 (a summary and the amounts applied to interest, principal and the like) and the debit summary 760. 15 codes. **BAI2 type codes 700–799: Loan transactions** | Code | Description | Level | Direction | | --- | --- | --- | --- | | 701 | Principal Loan Balance | Status | – | | 703 | Available Commitment Amount | Status | – | | 705 | Payment Amount Due | Status | – | | 707 | Principal Amount Past Due | Status | – | | 709 | Interest Amount Past Due | Status | – | | 720 | Total Loan Payment | Summary | Credit | | 721 | Amount Applied to Interest | Detail | Credit | | 722 | Amount Applied to Principal | Detail | Credit | | 723 | Amount Applied to Escrow | Detail | Credit | | 724 | Amount Applied to Late Charges | Detail | Credit | | 725 | Amount Applied to Buydown | Detail | Credit | | 726 | Amount Applied to Misc. Fees | Detail | Credit | | 727 | Amount Applied to Deferred Interest Detail | Detail | Credit | | 728 | Amount Applied to Service Charge | Detail | Credit | | 760 | Loan Disbursement | Summary | Debit | ### 800–899: Unassigned (890: non-monetary information) No codes are assigned here except 890, a detail code for a 16 record that carries a message in its text instead of an amount. 1 code. **BAI2 type codes 800–899: Unassigned (890: non-monetary information)** | Code | Description | Level | Direction | | --- | --- | --- | --- | | 890 | Contains Non-monetary Information | Detail | Non-monetary | ### 900–999: Bank-defined codes The specification lists no codes here: each bank assigns its own and should say what they mean in its BAI2 guide. The range still tells you the level and direction. **Bank-defined type code ranges** | Codes | Range | How they are used | | --- | --- | --- | | 900–919 | Custom account status (bank-defined) | Status codes your bank defines, reported in the 03 record like 001–099. | | 920–959 | Custom credits (bank-defined) | Credit codes your bank defines: a summary code in an 03 record, a detail code in a 16 record. | | 960–999 | Custom debits (bank-defined) | Debit codes your bank defines: a summary code in an 03 record, a detail code in a 16 record. | Code list adapted from [ministryofjustice/bai2](https://github.com/ministryofjustice/bai2) (MIT License; Copyright (C) 2015-2025 HM Government (Ministry of Justice Digital & Technology)) and checked against the type-code appendix of the BAI2 specification (BAI, 2005). ## 10 codes outside the BAI2 list These codes are not in the specification’s list, but the BAI2 Viewer recognizes them, with the meaning below, and does not flag them. Real-time payment codes such as 158 and 458 came into use at banks after the 2005 list; five others came with the code list this page is built on and turn up in no published source, so treat their names with care. **Type codes outside the BAI2 list** | Code | Description | Level | Direction | Source | | --- | --- | --- | --- | --- | | 087 | MTD Ave Collected | Status | – | **Unverified.** Not in the BAI2 list or in any bank list checked; the name is unverified. | | 088 | MTD Ave Neg Collected | Status | – | **Unverified.** Not in the BAI2 list or in any bank list checked; the name is unverified. | | 102 | Total Number of Credits | Summary | Credit | **Unverified.** Not in the BAI2 list or in any bank list checked; the name is unverified. | | 158 | Real Time Payment Credit | Detail | Credit | **Used by several banks.** Not in the BAI2 list. Banks use it for real-time payment credits. | | 159 | Total Real Time Payment Credits | Summary | Credit | **Used by several banks.** Not in the BAI2 list. Banks use it for the total of real-time payment credits. | | 402 | Total Number of Debits | Summary | Debit | **One bank’s code.** Not in the BAI2 list. Some banks use it for the number of debits. | | 458 | Real Time Payment Debit | Detail | Debit | **Used by several banks.** Not in the BAI2 list. Banks use it for real-time payment debits. | | 459 | Total Real Time Payment Debits | Summary | Debit | **Used by several banks.** Not in the BAI2 list. Banks use it for the total of real-time payment debits. | | 706 | Loan Participation | Detail | Credit | **Unverified.** Not in the BAI2 list or in any bank list checked; the name is unverified. | | 708 | Value Dated Funds | Detail | Credit | **Unverified.** Not in the BAI2 list or in any bank list checked; the name is unverified. | ## BAI2 and BTRS BAI2’s copyright passed from BAI to ASC X9 in 2008, and ASC X9 publishes its successor, the Balance and Transaction Reporting Standard (BTRS), as ANSI X9.121. A BTRS file builds on the BAI2 records and says Version Number 3 in its File Header, where a BAI2 file says 2. Its code list is not the BAI2 list. The 2012 edition cut the list to 181 codes, each tied to one summary code, added a few (035, 141, 371, 441 and 671), renamed many and gave some a different meaning: 040, 077, 078 and 370 changed. 077, for one, is Average Adjustment to Balances MTD in BAI2 but 2 Day Available in BTRS 2012. The current BTRS code list (version 3.3.1, with X9.121-2016 reaffirmed in 2021) is a free download from [ANSI](https://webstore.ansi.org/standards/ascx9/ansix91212016r2021); this page lists the BAI2 codes only. The BAI2 Viewer opens version 3 files but reads them with BAI2 meanings, and says so in a warning. Check any code in a BTRS file against your bank’s BTRS list. The record-level differences are on the [BAI2 file format](https://nacha-navigator.com/bai2-file-format#btrs) page. ## Sources and credits The list follows the type-code appendix of BAI’s Cash Management Balance Reporting Specifications, Version 2 (2005). The names are the specification’s, lightly normalized; the explanations on this page are our own. Banks add codes of their own and sometimes use listed codes in their own way, so check your bank’s BAI2 guide for codes it reports. NACHA Navigator is independent and not affiliated with BAI, ASC X9 or any bank. This page is for information only. [BAI2 specification (PDF)](https://cdn.bai.org/migrated-from-www/docs/default-source/libraries/site-general-downloads/cash_management_2005.pdf) [Open a sample report](https://nacha-navigator.com/bai2-viewer?sample=multi-account) --- URL: https://nacha-navigator.com/bai2-file-format # BAI2 file format: records and fields BAI2 reference How a BAI2 balance report is put together, field by field: record order, delimiters and continuations, amounts and funds types, control totals, and every check the BAI2 Viewer runs. Last updated October 30, 2026 [Open the BAI2 Viewer](https://nacha-navigator.com/bai2-viewer) [BAI2 type codes](https://nacha-navigator.com/bai2-type-codes) ## How a BAI2 file is organized A BAI2 file is plain text, one record per line. Each record starts with a two-digit record code and a comma. The records nest: one file holds one or more groups (the data one bank sends for one as-of date), each group holds the accounts it reports, and each account holds its transactions. The file, every group and every account end with a trailer that carries a control total and a record count. 1. [01 File Header Once, the first record](https://nacha-navigator.com/bai2-file-format#record-01) 2. [02 Group Header Starts each group](https://nacha-navigator.com/bai2-file-format#record-02) 3. [03 Account Identifier Starts each account](https://nacha-navigator.com/bai2-file-format#record-03) 4. [16 Transaction Detail One per transaction, optional](https://nacha-navigator.com/bai2-file-format#record-16) 5. [49 Account Trailer Closes each account](https://nacha-navigator.com/bai2-file-format#record-49) 6. [98 Group Trailer Closes each group](https://nacha-navigator.com/bai2-file-format#record-98) 7. [99 File Trailer Once, the last record](https://nacha-navigator.com/bai2-file-format#record-99) Indented records repeat: any number of groups per file, accounts per group and transactions per account. An [88 Continuation](https://nacha-navigator.com/bai2-file-format#record-88) can follow any of them to carry fields that did not fit on its line. ## Writing records Fields have no fixed positions. They are told apart by delimiters, and their order is set by the record layout. - **Commas separate fields, and a slash ends the record.** Anything after the slash on that line is ignored. The record code counts as field 1. - **Defaulted fields keep their place.** A field with no value is written as nothing between its delimiters: `,,` in the middle of a record and `,/` at its end. In `02,EXAMPLECO,EXAMPLEBANK,1,261028,2400,,2/` the currency is defaulted, so the group is in USD. - **The text of a 16 runs to the end of the record.** It is the last field of a Transaction Detail and the only field that may contain commas and slashes, so a 16 with text needs no closing slash. A 16 without text ends with a slash where the text would begin, and text never starts with a slash. - **An 88 continues the record before it.** When a record is too long for one line, the line ends with a slash and the next line starts `88,` with the record’s next field. Any record can be continued this way, from the 01 to the 99. A field is never split across lines, except the 16 text, which carries on across the 88s. An 88 cannot be the first record or follow a record that already has all its fields. - **Leading zeros count.** Record codes, type codes and account numbers keep their leading zeros: account 0012345678 is not account 12345678. - **Record length is free.** Lines are as long as their content unless the File Header sets a Physical Record Length; a record that does not fit continues on 88 lines. ``` 16,115,50000,S,30000,20000,0,LBX0001,,LOCKBOX DEPOSIT 88,3 CHECKS, LOCKBOX 4417 ``` The 88 adds to the 16’s text, which reads “LOCKBOX DEPOSIT 3 CHECKS, LOCKBOX 4417”. ## Amounts, dates and funds types - **Amounts have no decimal point.** The currency’s minor unit sets the implied decimals: `1250000` is 12,500.00 in USD, 1,250,000 in JPY (no decimals) and 1,250.000 in BHD (three). - **Only balances, totals and availability amounts can be negative.** Status (balance) amounts, control totals and the availability amounts of funds types S and D may start with + or -. Summary and transaction amounts are positive (a leading + is allowed but not needed): the [type code](https://nacha-navigator.com/bai2-type-codes) says whether money came in or went out. - **Currency codes are ISO 4217.** The Group Header sets the currency for its accounts (blank means USD), and an Account Identifier can set another for its own amounts (blank means the group’s). - **Dates are YYMMDD,** so `261028` is October 28, 2026. The viewer reads a two-digit year below 70 as 20YY. - **Times are HHMM on a 24-hour clock,** 0000 to 2359; both 2400 and 9999 mean the end of the day. Some banks write HHMMSS or HH:MM, which the viewer reads with a warning. ### Funds types The funds type says when the money is available. It follows the amount of a Transaction Detail and of each summary in an Account Identifier. A blank funds type means Z. **BAI2 funds types** | Code | Availability | Fields after it | Written as | | --- | --- | --- | --- | | 0 | Immediate availability | None | 0 | | 1 | One-day availability | None | 1 | | 2 | Two-or-more-day availability | None | 2 | | S | Distributed availability (simple) | Three amounts: available immediately, in one day, and in two or more days | S,30000,20000,0 | | V | Value dated | Value date (YYMMDD) and value time (HHMM, optional) | V,261030,0900 | | D | Distributed availability (detailed) | Number of distributions, then days and amount for each distribution | D,2,1,40000,3,10000 | | Z | Unknown availability | None; also the meaning of a blank funds type | Z | Availability amounts are in the currency and decimals of the amount they split, may be signed, and need not add up to it. They are not part of any control total. In the D example, 400.00 is available after one day and 100.00 after three. ## Control totals and record counts Every trailer checks what it closes. Totals are written like any amount, in minor units without a decimal point, and may be negative. - **Account Trailer (49):** the control total is the sum, with signs, of every amount in the account’s 03 (balances and summaries) and its 16 records, including amounts carried on 88s. Item counts and availability amounts are left out. The record count covers the 03, every 16 and 88, and the 49 itself. - **Group Trailer (98):** the control total is the sum of the group’s account control totals; then the number of accounts (03 records) and the number of records, from the 02 through the 98, 88s included. - **File Trailer (99):** the control total is the sum of the group control totals; then the number of groups (02 records) and the number of records in the whole file, from the 01 through the 99. Some banks leave the 03 summary amounts or the 890 amounts out of the account total, or count only the 16 amounts. The BAI2 Viewer recognizes those totals and reports them as warnings rather than errors (see [Account control total](https://nacha-navigator.com/bai2-file-format#rule-control.account-total)). ## An example, line by line A complete file with one account: two balances and two summaries, three transactions (one continued on an 88) and the three trailers. Every total and count in it is right; open it in the [BAI2 Viewer](https://nacha-navigator.com/bai2-viewer) by pasting it there. ``` 01,EXAMPLEBANK,EXAMPLECO,261029,0615,1029,,,2/ 02,EXAMPLECO,EXAMPLEBANK,1,261028,2400,USD,2/ 03,0012345678,USD,010,1250000,,,015,1407500,,,100,232500,2,,400,75000,1,/ 16,165,182500,0,ACH0001,INV1001,ACH CREDIT, NORTHWIND TRADERS 16,115,50000,S,30000,20000,0,LBX0001,,LOCKBOX DEPOSIT 88,3 CHECKS, LOCKBOX 4417 16,475,75000,,,1043,CHECK 1043 49,3272500,6/ 98,3272500,1,8/ 99,3272500,1,10/ ``` **The example file, explained line by line** | Line | Record | What it says | | --- | --- | --- | | 1 | [01](https://nacha-navigator.com/bai2-file-format#record-01) | File Header: sent by EXAMPLEBANK to EXAMPLECO on October 29, 2026 at 06:15, file number 1029. Physical Record Length and Block Size are defaulted (",,"); the version is 2. | | 2 | [02](https://nacha-navigator.com/bai2-file-format#record-02) | Group Header: data for EXAMPLECO (ultimate receiver) from EXAMPLEBANK (originator), status 1 (update), as of the end of October 28, 2026 (2400), in USD, final previous-day data (modifier 2). | | 3 | [03](https://nacha-navigator.com/bai2-file-format#record-03) | Account 0012345678 in USD: opening ledger (010) 12,500.00, closing ledger (015) 14,075.00, total credits (100) 2,325.00 in 2 items and total debits (400) 750.00 in 1 item. Each group of four fields is type code, amount, item count and funds type. | | 4 | [16](https://nacha-navigator.com/bai2-file-format#record-16) | An ACH credit (165) of 1,825.00, available immediately (funds type 0), with bank and customer references. The text runs to the end of the line, comma included, so there is no "/". | | 5 | [16](https://nacha-navigator.com/bai2-file-format#record-16) | A lockbox deposit (115) of 500.00 with distributed availability (S): 300.00 today, 200.00 in one day, 0.00 later. The customer reference is defaulted (",,"). | | 6 | [88](https://nacha-navigator.com/bai2-file-format#record-88) | Continuation: the rest of the 115’s text, which reads “LOCKBOX DEPOSIT 3 CHECKS, LOCKBOX 4417”. | | 7 | [16](https://nacha-navigator.com/bai2-file-format#record-16) | A paid check (475) of 750.00. The funds type and bank reference are defaulted; the customer reference is the check number. | | 8 | [49](https://nacha-navigator.com/bai2-file-format#record-49) | Account Trailer: control total 3272500 (32,725.00), the sum of every amount in the 03 (12,500.00 + 14,075.00 + 2,325.00 + 750.00) and the 16s (1,825.00 + 500.00 + 750.00), without the availability amounts or item counts. 6 records: the 03, three 16s, the 88 and the 49. | | 9 | [98](https://nacha-navigator.com/bai2-file-format#record-98) | Group Trailer: the sum of the group’s account control totals, 1 account, and 8 records (the 02, the account’s 6 and the 98). | | 10 | [99](https://nacha-navigator.com/bai2-file-format#record-99) | File Trailer: the sum of the group control totals, 1 group, and 10 records: every line of the file. | ## Record layouts The fields of each record in order, numbered from the record code (field 1); the specification lists them by name. Required fields must have a value; optional fields may be defaulted. The descriptions are the BAI2 Viewer’s. ### 01 File Header First record of the file: sender, receiver, creation date and time, file ID and format version. **File Header (01): fields** | Field | Name | Required | Description | | --- | --- | --- | --- | | 1 | Record Code | Yes | 01: File Header, the first record of the file. | | 2 | Sender Identification | Yes | Who sent the file, usually the bank or its processor. | | 3 | Receiver Identification | Yes | Who receives the file, usually the customer or its processor. | | 4 | File Creation Date | Yes | Date the file was created (YYMMDD). | | 5 | File Creation Time | Yes | Time the file was created (HHMM, 24-hour clock). | | 6 | File Identification Number | Yes | Number the sender assigns so files created on the same date can be told apart. | | 7 | Physical Record Length | No | Characters per physical record. Blank means variable-length records. | | 8 | Block Size | No | Number of physical records in a block. Optional, usually blank. | | 9 | Version Number | Yes | BAI format version. Must be 2 for BAI2. | In the example file ``` 01,EXAMPLEBANK,EXAMPLECO,261029,0615,1029,,,2/ ``` ### 02 Group Header Starts a group of accounts reported by one originator, with the as-of date, time and currency. **Group Header (02): fields** | Field | Name | Required | Description | | --- | --- | --- | --- | | 1 | Record Code | Yes | 02: Group Header, starts a group of accounts. | | 2 | Ultimate Receiver Identification | No | Final receiver of the data in this group. Optional. | | 3 | Originator Identification | Yes | Bank that originated the data in this group, often by its routing number. | | 4 | Group Status | Yes | 1 Update, 2 Deletion, 3 Correction, 4 Test Only. | | 5 | As-of-Date | Yes | Date the balances and transactions in this group refer to (YYMMDD). | | 6 | As-of-Time | No | Time of day the data refers to (HHMM). 2400 or 9999 means end of day. Optional. | | 7 | Currency Code | No | ISO 4217 currency of the group’s amounts. Blank means USD. | | 8 | As-of-Date Modifier | No | 1 Interim previous-day, 2 Final previous-day, 3 Interim same-day, 4 Final same-day. Optional. | In the example file ``` 02,EXAMPLECO,EXAMPLEBANK,1,261028,2400,USD,2/ ``` ### 03 Account Identifier and Summary Status Starts an account: account number, currency, then balances (status codes) and summaries. **Account Identifier and Summary Status (03): fields** | Field | Name | Required | Description | | --- | --- | --- | --- | | 1 | Record Code | Yes | 03: Account Identifier and Summary Status, starts an account. | | 2 | Customer Account Number | Yes | Account number at the originating bank. Leading zeros are significant. | | 3 | Currency Code | No | ISO 4217 currency of this account. Blank means the group currency. | Then, for each balance or summary, these four fields. The first group is fields 4 to 7, the next starts at field 8, and so on. **Account Identifier and Summary Status (03): the fields of each balance or summary** | Field | Name | Required | Description | | --- | --- | --- | --- | | 4 | Type Code | Yes | Status (balance) or summary type code for the amount that follows. | | 5 | Amount | No | Implied decimals set by the currency. Status amounts may be signed; summary amounts are unsigned. | | 6 | Item Count | No | Number of items in the summary amount. Blank for status codes. | | 7 | Funds Type | No | Availability: 0 immediate, 1 one day, 2 two or more days, S distributed, V value dated, D detailed distribution, Z or blank unknown. | After the Funds Type, [funds types](https://nacha-navigator.com/bai2-file-format#funds-types) S, V and D add fields: S Immediate Availability, One-Day Availability, Two-or-More-Day Availability; V Value Date, Value Time; D Number of Distributions, Availability in Days, Available Amount, the last two repeated for each distribution. The {type code, amount, item count, funds type} group repeats as often as needed and continues on 88 records. In the example file ``` 03,0012345678,USD,010,1250000,,,015,1407500,,,100,232500,2,,400,75000,1,/ ``` ### 16 Transaction Detail One transaction: type code, amount, availability, bank and customer references, and text. **Transaction Detail (16): fields** | Field | Name | Required | Description | | --- | --- | --- | --- | | 1 | Record Code | Yes | 16: Transaction Detail, one transaction in the account. | | 2 | Type Code | Yes | Detail type code. Its range sets credit (100–399) or debit (400–699). | | 3 | Amount | No | Optional; blank means no amount is reported. Unsigned, with implied decimals set by the currency. The type code sets credit or debit. | | 4 | Funds Type | No | Availability: 0 immediate, 1 one day, 2 two or more days, S distributed, V value dated, D detailed distribution, Z or blank unknown. | | 5 | Bank Reference Number | No | Reference the bank assigned to the transaction. Optional. | | 6 | Customer Reference Number | No | Reference from the customer, such as a check number. Optional. | | 7 | Text | No | Free-form description. Runs to the end of the record, may contain commas, and continues on 88 records. | After the Funds Type, [funds types](https://nacha-navigator.com/bai2-file-format#funds-types) S, V and D add fields: S Immediate Availability, One-Day Availability, Two-or-More-Day Availability; V Value Date, Value Time; D Number of Distributions, Availability in Days, Available Amount, the last two repeated for each distribution. Text is the rest of the record, commas included, and continues on 88 records. In the example file ``` 16,165,182500,0,ACH0001,INV1001,ACH CREDIT, NORTHWIND TRADERS 16,115,50000,S,30000,20000,0,LBX0001,,LOCKBOX DEPOSIT 16,475,75000,,,1043,CHECK 1043 ``` ### 88 Continuation Carries the rest of the record before it when one line is not enough. Any record type can be continued. **Continuation (88): fields** | Field | Name | Required | Description | | --- | --- | --- | --- | | 1 | Record Code | Yes | 88: Continuation, carrying the next fields of the record before it. | Carries the next fields of the record before it, whatever its type. A field is never split across lines; only the 16 text runs on. In the example file ``` 88,3 CHECKS, LOCKBOX 4417 ``` ### 49 Account Trailer Closes the account with its control total and record count. **Account Trailer (49): fields** | Field | Name | Required | Description | | --- | --- | --- | --- | | 1 | Record Code | Yes | 49: Account Trailer, closes the account. | | 2 | Account Control Total | Yes | Algebraic sum of every amount in the account’s 03 record and all of its 16 records. | | 3 | Number of Records | Yes | Records in the account: the 03, every 16 and 88, and this 49. | In the example file ``` 49,3272500,6/ ``` ### 98 Group Trailer Closes the group with its control total, number of accounts and record count. **Group Trailer (98): fields** | Field | Name | Required | Description | | --- | --- | --- | --- | | 1 | Record Code | Yes | 98: Group Trailer, closes the group. | | 2 | Group Control Total | Yes | Sum of the Account Control Totals in the group. | | 3 | Number of Accounts | Yes | Number of 03 records in the group. | | 4 | Number of Records | Yes | Records in the group: the 02, every account record and 88, and this 98. | In the example file ``` 98,3272500,1,8/ ``` ### 99 File Trailer Last record of the file, with the file control total, number of groups and record count. **File Trailer (99): fields** | Field | Name | Required | Description | | --- | --- | --- | --- | | 1 | Record Code | Yes | 99: File Trailer, the last record of the file. | | 2 | File Control Total | Yes | Sum of the Group Control Totals in the file. | | 3 | Number of Groups | Yes | Number of 02 records in the file. | | 4 | Number of Records | Yes | Every record in the file from the 01 through this 99, including 88s. | In the example file ``` 99,3272500,1,10/ ``` ## Group Header codes The two coded fields of the Group Header. The status is required; the modifier is optional. ### Group Status (02, field 4) **Group Status (02, field 4)** | Code | Meaning | | --- | --- | | 1 | Update | | 2 | Deletion | | 3 | Correction | | 4 | Test Only | ### As-of-Date Modifier (02, field 8) **As-of-Date Modifier (02, field 8)** | Code | Meaning | | --- | --- | | 1 | Interim previous-day data | | 2 | Final previous-day data | | 3 | Interim same-day data | | 4 | Final same-day data | ## BAI2 and BTRS (version 3) BAI2’s successor is the Balance and Transaction Reporting Standard (BTRS), ANSI X9.121, published by ASC X9. A BTRS file uses the same records and delimiters and says Version Number 3 in its File Header. The 2012 edition differs from BAI2 in several ways, among them: - **Two more records,** 89 Batch Detail and 90 Invoice Detail. - **More structure in the 88.** An 88 can carry a Fedwire or CHIPS wire’s remittance details, marked with Fedwire/CHIPS tags or ISO 20022 tags. - **Currency codes are required.** The Group Header and every Account Identifier must name their currency. In BAI2 either may be left blank: USD for a group, the group’s currency for an account. - **UTF-8 text.** The 16, 88, 89 and 90 records may carry UTF-8 text, including characters outside ASCII. - **No funds type D.** The detailed distribution is gone; 0, 1, 2, S, V and Z remain. - **Its own type-code list.** 181 codes in 2012, each tied to a summary code, with some codes renamed or given a new meaning (see [BAI2 and BTRS type codes](https://nacha-navigator.com/bai2-type-codes#btrs)). The current list is version 3.3.1, free from [ANSI](https://webstore.ansi.org/standards/ascx9/ansix91212016r2021). **Records BTRS adds** | Code | Record | In the BAI2 Viewer | | --- | --- | --- | | 89 | Batch Detail | Shown as raw text with a note; its fields are not decoded. | | 90 | Invoice Detail | Shown as raw text with a note; its fields are not decoded. | The viewer opens version 3 files with BAI2 layouts and code meanings, and warns that some meanings differ. The record layouts and checks on this page are BAI2’s. ## Validation checks The 53 checks the BAI2 Viewer runs on every file, with the code it shows for each. An error breaks a rule of the format, such as a control total that does not add up; a warning is something a strict reader may reject, though the file still reads; info is worth knowing but harmless. Some checks are reported at more than one severity, depending on what was found. Each check’s last line names the part of the specification it comes from, with field numbers counted from the record code as in the layouts above. The viewer reads files leniently, accepting a few common deviations with a warning where a strict reading would report an error. ### File and record format Whether the file reads as BAI2 at all, and how each line is written. 1. #### Empty file Error `format.empty` The file holds no records, only nothing or blank lines, so there is nothing to show. Specification: BAI2 file structure: 01 … 99. 2. #### Not a BAI2 file Error `format.not-bai2` The first line does not start with a BAI2 record code and fewer than half of the lines do, so the file is not read as BAI2. A NACHA, CSV or X9 file ends here. Specification: BAI2 record codes 01, 02, 03, 16, 49, 88, 98, 99. 3. #### Character encoding Info `format.encoding` The file is EBCDIC (code page 037) or UTF-16 rather than ASCII text; it was converted to text before reading. Specification: BAI2 files are ASCII text. 4. #### Blank lines Info `format.blank-lines` Blank lines between records were skipped. BAI2 has no blank records, but they change nothing else. Specification: BAI2 physical records. 5. #### Leading whitespace Warning `format.leading-whitespace` Lines start with spaces before the record code. The viewer reads from the record code; a stricter reader may reject the line. Specification: BAI2 physical records start with the record code. 6. #### Non-ASCII characters Info `format.non-ascii` Some lines contain characters outside printable ASCII, such as accented letters or control characters. Specification: BAI2 files are ASCII text. 7. #### No line breaks Error Info `format.no-line-breaks` The file has no line breaks. When it divides into records of the Physical Record Length in the File Header (or of 80 characters), it is split that way and noted; when it does not, it reads as one long record, which is an error. Specification: 01 File Header, field 7 Physical Record Length. 8. #### Record longer than declared Warning `format.record-length` Lines are longer than the Physical Record Length the File Header declares, or the declared length is shorter than the header itself. Specification: 01 File Header, field 7 Physical Record Length. 9. #### Unknown record code Error `format.unknown-record` A line starts with a code that is not a BAI2 record code (01, 02, 03, 16, 49, 88, 98 or 99). It is kept as raw text. Specification: BAI2 record codes 01, 02, 03, 16, 49, 88, 98, 99. 10. #### BTRS record Info `format.btrs-record` A BTRS record (89 Batch Detail or 90 Invoice Detail) in a version 3 file. The viewer reads BAI2 layouts, so it is shown as raw text. Specification: BTRS (ANSI X9.121, version 3) records 89 Batch Detail and 90 Invoice Detail. 11. #### Record code not followed by a comma Error `format.record-code-delimiter` The two-digit record code is not followed by a comma, as in "16;165,…". Specification: BAI2 field delimiters. 12. #### Record not ended with "/" Warning `format.missing-terminator` A record other than a Transaction Detail does not end with "/". The 16 is the exception because its text runs to the end of the record. Specification: BAI2 field delimiters: "/" ends a record. 13. #### Data after "/" Warning `format.data-after-terminator` Characters follow the "/" that ends a record. BAI2 ignores everything after the slash, and so does the viewer. Specification: BAI2 field delimiters: "/" ends a record. 14. #### Fields beyond the record layout Warning `format.extra-fields` A record has more non-empty fields than its layout defines. The extra fields are shown but ignored. Specification: BAI2 record formats. 15. #### Version number Warning `format.version` The Version Number in the File Header is not 2. Version 3 marks a BTRS file, read with BAI2 code meanings; any other version is read as BAI2. Specification: 01 File Header, field 9 Version Number (2). 16. #### Issue limit reached Info `format.issue-limit` The file has more issues than the viewer lists (5,000); the rest are counted but not shown. A limit of the viewer, not a rule of the format. 17. #### Too many lines Error `format.too-many-lines` The file has more lines than the viewer opens (500,000), so it is not read. A limit of the viewer, not a rule of the format. ### File structure Whether the records nest as 01, groups, accounts, trailers and 99. 1. #### File does not start with 01 Error `structure.first-record` The first record is not a File Header (01). Specification: BAI2 file structure: 01 is the first record. 2. #### No Group Header Error `structure.no-group` The file has no Group Header (02), so no account belongs to a group. Specification: BAI2 file structure: 01 { 02 … 98 } 99. 3. #### Second File Header Error `structure.duplicate-file-header` A second File Header (01) appears inside the file. Two files may have been joined together. Specification: BAI2 file structure: one 01 per file. 4. #### Record out of order Error `structure.unexpected-record` A record is out of place: an 03 outside a group, a 16 outside an account, or a 49 or 98 with no open account or group to close. Specification: BAI2 file structure: 01 { 02 { 03 16\* 49 }\* 98 }\* 99. 5. #### Missing Account Trailer Error `structure.missing-account-trailer` An account (03) is not closed by an Account Trailer (49) before the next account, the group trailer or the end of the file. Specification: 49 Account Trailer closes every 03. 6. #### Missing Group Trailer Error `structure.missing-group-trailer` A group (02) is not closed by a Group Trailer (98) before the next group or the end of the file. Specification: 98 Group Trailer closes every 02. 7. #### Missing File Trailer Error `structure.missing-file-trailer` The file does not end with a File Trailer (99). Specification: 99 File Trailer is the last record. 8. #### Records after the File Trailer Error `structure.after-file-trailer` Records follow the File Trailer (99). They are not part of the file; if the first is another 01, two files may have been joined. Specification: 99 File Trailer is the last record. 9. #### Continuation with nothing to continue Error `structure.orphan-continuation` An 88 has nothing to continue: it is the first record, or the record before it already has all its fields. If it looks like a group trailer, the message asks whether 98 was meant. Specification: 88 Continuation carries the next fields of the record before it. 10. #### 88 used as a Group Trailer Warning `structure.legacy-88-group-trailer` An 88 written where the Group Trailer belongs, as some older software does, after a complete 49 or 02. The viewer reads it as a 98; in BAI2, 88 only continues a record. Specification: 98 Group Trailer; 88 is Continuation. 11. #### "/" inside an 03 summary Warning `structure.slash-mid-summary` A "/" ends an 03 line partway through a summary, and the 88 that follows starts with a type code. The viewer treats the rest of that summary as defaulted and the 88 as the next summary, which is what such files mean. Specification: 03 Account Identifier and Summary Status; 88 Continuation. ### Field values Dates, times, amounts, counts and codes in individual fields. 1. #### Required field missing Error `field.required` A field the layout requires is empty, such as the Originator Identification in an 02 or a trailer’s control total. Specification: BAI2 record formats. 2. #### Invalid date Error `field.date` A date is not a real YYMMDD date: it has the wrong length, month 13, or a day the month does not have. Specification: BAI2 dates are YYMMDD. 3. #### Invalid time Error `field.time` A time is not a valid HHMM time: 0000 to 2359, or 2400 or 9999 for the end of the day. Specification: BAI2 times are HHMM, 0000–2400 (9999 = end of day). 4. #### Non-standard time format Warning `field.time-format` A time is written as HHMMSS or HH:MM. It is read, but BAI2 times are four digits. Specification: BAI2 times are HHMM. 5. #### Not a whole number Error Warning `field.numeric` A number field (an item count, a record, account or group count, or a funds type D count) holds something other than digits. It is a warning for the File Identification Number, Physical Record Length and Block Size in the 01, and an error everywhere else. Specification: BAI2 numeric fields. 6. #### Invalid amount Error `field.amount` An amount is not digits with an optional sign, for example 1250.00: BAI2 amounts have no decimal point. Specification: BAI2 amounts: digits with implied decimals, optional sign. 7. #### Negative unsigned amount Error `field.amount-sign` A summary or transaction amount is negative. Those amounts are positive (a leading + is allowed); the type code says whether it is a credit or a debit. Specification: 03 summary and 16 amounts are unsigned; the type code sets the direction. 8. #### Currency code Error Warning Info `field.currency` A currency code is not an ISO 4217 code (an error; its amounts are shown with 2 decimals), is lowercase (a warning when read leniently, else an error), or is a withdrawn code (info). Specification: 02 field 7 / 03 field 3: ISO 4217 currency code. 9. #### Group Status Error `field.group-status` The Group Status in an 02 is not 1, 2, 3 or 4. Specification: 02 Group Header, field 4: 1, 2, 3 or 4. 10. #### As-of-Date Modifier Error `field.as-of-modifier` The As-of-Date Modifier in an 02 is not 1, 2, 3 or 4. Specification: 02 Group Header, field 8: 1, 2, 3 or 4. 11. #### Funds Type Error Warning `field.funds-type` A funds type is not 0, 1, 2, S, V, D or Z (an error), or is a lowercase letter (a warning when read leniently, else an error). Specification: Funds Type: 0, 1, 2, S, V, D or Z. 12. #### Availability fields Error `field.availability` Funds type D says more distributions follow than the record holds. Specification: Funds Type S (3 amounts), V (date, time), D (count, days/amount pairs). 13. #### Item count on a status code Info `field.status-item-count` An item count is given with a status (balance) code in an 03. Item counts belong to summary codes. Specification: 03 Item Count applies to summary type codes. 14. #### Funds type on a status code Info `field.status-funds-type` A funds type is given with a status (balance) code in an 03. Funds types belong to summary codes. Specification: 03 Funds Type applies to summary type codes. ### Type codes Whether each type code is valid and in the right record. 1. #### Invalid type code Error `code.type-code` A type code is not three digits from 001 to 999. Specification: BAI2 type codes are 3 digits. 2. #### Type code in the wrong record Error Warning Info `code.type-code-level` A type code is in the wrong record: a status code in a 16 is an error, a detail code in an 03 a warning, and a summary code in a 16 worth a note. Specification: 03 carries status/summary codes; 16 carries detail codes. 3. #### Unrecognized type code Info `code.type-code-unrecognized` A three-digit code that is neither in the list nor in a bank-defined range (900 to 999). It is described by its range; ask the bank what it means. Specification: BAI2 type-code list. ### Control totals and counts The totals and record counts in the 49, 98 and 99 trailers. 1. #### Account control total Error Warning `control.account-total` The 49 Account Control Total is not the sum of every amount in the account’s 03 and 16 records. It is a warning when the total matches a way some banks add up (without the 03 summaries, without 890 amounts, or the 16 amounts alone). Specification: 49 Account Trailer, field 2 Account Control Total. 2. #### Account record count Error `control.account-records` The 49 Number of Records does not count the account’s records: its 03, every 16 and 88, and the 49 itself. Specification: 49 Account Trailer, field 3 Number of Records. 3. #### Group control total Error `control.group-total` The 98 Group Control Total is not the sum of the group’s Account Control Totals. Specification: 98 Group Trailer, field 2 Group Control Total. 4. #### Group account count Error `control.group-accounts` The 98 Number of Accounts does not match the number of 03 records in the group. Specification: 98 Group Trailer, field 3 Number of Accounts. 5. #### Group record count Error `control.group-records` The 98 Number of Records does not count the group’s records: its 02, every account record and 88, and the 98 itself. Specification: 98 Group Trailer, field 4 Number of Records. 6. #### File control total Error `control.file-total` The 99 File Control Total is not the sum of the Group Control Totals. Specification: 99 File Trailer, field 2 File Control Total. 7. #### File group count Error `control.file-groups` The 99 Number of Groups does not match the number of 02 records in the file. Specification: 99 File Trailer, field 3 Number of Groups. 8. #### File record count Error `control.file-records` The 99 Number of Records does not count every record from the 01 through the 99, 88s included. Specification: 99 File Trailer, field 4 Number of Records. ## Sources This page follows BAI’s Cash Management Balance Reporting Specifications, Version 2 (2005), in our own words, and describes how the BAI2 Viewer applies it. Banks differ in the details, so check your bank’s BAI2 guide for its record lengths, codes and conventions. Type code names come from a list adapted from [ministryofjustice/bai2](https://github.com/ministryofjustice/bai2) (MIT License). NACHA Navigator is independent and not affiliated with BAI or ASC X9. This page is for information only and is not legal or compliance advice. [BAI2 specification (PDF)](https://cdn.bai.org/migrated-from-www/docs/default-source/libraries/site-general-downloads/cash_management_2005.pdf) [Sample BAI2 file](https://nacha-navigator.com/samples/bai2/sample-multi-account.bai) [All sample files](https://nacha-navigator.com/sample-files) --- URL: https://nacha-navigator.com/x9-file-format # X9.37 file format: record types and fields X9 reference The image cash letter format of DSTU X9.37-2003 and ANSI X9.100-187, record by record: how a file is organized, every field layout with its positions, the main code tables and the checks the X9 Viewer runs. Last updated October 30, 2026 [Open the X9 Viewer](https://nacha-navigator.com/x9-viewer) [Sample cash letter](https://nacha-navigator.com/samples/x9/sample-cash-letter.x9) ## How an X9.37 file is organized An X9.37 file, or image cash letter, carries checks between banks as fixed records, each starting with a two-digit record type. The records nest: the file holds cash letters, a cash letter holds bundles, a bundle holds the items (checks presented for payment, or returns), and each item carries its addenda and its image views. Every bundle, cash letter and the file itself close with a control record that states their counts and totals. 1. [01 File Header Once, the first record](https://nacha-navigator.com/x9-file-format#type-01) 2. [10 Cash Letter Header Starts each cash letter](https://nacha-navigator.com/x9-file-format#type-10) 3. [20 Bundle Header Starts each bundle](https://nacha-navigator.com/x9-file-format#type-20) 4. [25 Check Detail One per check presented (forward collection)](https://nacha-navigator.com/x9-file-format#type-25) 5. [26 27 28 Check Detail Addenda A, B and C After their check, before its images](https://nacha-navigator.com/x9-file-format#type-26) 6. [31 Return One per returned item (return cash letters)](https://nacha-navigator.com/x9-file-format#type-31) 7. [32 33 34 35 Return Addenda A to D After their return, before its images](https://nacha-navigator.com/x9-file-format#type-32) 8. [50 52 Image View Detail and Image View Data A pair per image view, usually front then back](https://nacha-navigator.com/x9-file-format#type-50) 9. [54 Image View Analysis Optional, after the view it describes](https://nacha-navigator.com/x9-file-format#type-54) 10. [61 62 Credit records Where the exchange partners use them, in a bundle or cash letter](https://nacha-navigator.com/x9-file-format#type-61) 11. [70 Bundle Control Closes each bundle](https://nacha-navigator.com/x9-file-format#type-70) 12. [75 85 Box Summary and Routing Number Summary Optional, after the bundles of a cash letter (40 and 41 in DSTU files)](https://nacha-navigator.com/x9-file-format#type-75) 13. [90 Cash Letter Control Closes each cash letter](https://nacha-navigator.com/x9-file-format#type-90) 14. [99 File Control Once, the last record](https://nacha-navigator.com/x9-file-format#type-99) Indented records repeat: any number of cash letters per file, bundles per cash letter and items per bundle. A [User Record (68)](https://nacha-navigator.com/x9-file-format#type-68) can appear wherever its owner puts one. ## Editions and standard levels “X9.37” is the common name for the format, after the draft standard DSTU X9.37-2003. ANSI X9.100-187 replaced the draft in 2008 and has been revised since, most recently in 2021. The File Header’s Standard Level (positions 3–4) says which edition a file follows, and the X9 Viewer picks each record’s layout from it. **Editions of the X9.37 format** | Edition | Standard Level | Notes | | --- | --- | --- | | DSTU X9.37-2003 | 03 | Draft standard for trial use (DSTU) for check image exchange. Replaced by X9.100-187; the Federal Reserve still accepts it. | | X9.100-187-2008 | 30 | The US standard that replaced DSTU X9.37-2003. It adds fields in positions the DSTU left reserved. | | X9.100-187-2013 | 35 | Revision of the 2008 edition. | | X9.100-187-2016 | 35 | Revision of the 2013 edition. From this edition on, return reasons are defined in the separate standard X9.100-188. | | X9.100-187-2021 (current) | Not confirmed | Current edition; revises the 2016 edition. Not yet reviewed here, so the Standard Level its files carry and any layout changes are unconfirmed. | ### Related standards - **ANSI X9.100-180:** The non-domestic successor of DSTU X9.37 (used in Canada); it defines its own type 61 credit record. - **ANSI X9.100-181:** The TIFF image format for exchanged check images. - **ANSI X9.100-188:** Return reasons for check image exchange and image replacement documents, customer and administrative (current edition 2023). - **ASC X9 TR 47 (Universal Companion Document):** Industry rules for using X9.100-187 between exchange partners (current edition 2022). ## Bytes, encodings and record lengths - **Text is EBCDIC or ASCII.** Record text is EBCDIC (code page 037 in the US) or ASCII, and the first record’s type bytes tell which. Image data and digital signatures are binary and never converted. - **Each record starts with a 4-byte length.** The usual transmission format puts the record’s length in four bytes, big-endian, in front of every record. Some files have no prefix (records back to back, or one per line in ASCII exports), an IBM record descriptor word (a 2-byte length and two zero bytes), or a little-endian length written by some PC tools. The X9 Viewer detects all four. - **Records are 80 bytes,** except the 100-byte Credit (62) and four variable-length types whose own length fields say how long they are: the image archive addenda (27 and 34), Image View Data (52) and User Record (68). - **Numbers are digits only.** Amounts are in cents with no decimal point (`0000123456` is $1,234.56), dates are `YYYYMMDD` and times `hhmm` on a 24-hour clock. Routing numbers carry the ABA check digit; in checks and returns the ninth digit is a field of its own. ## Check images Each view of an item is a pair of records: an [Image View Detail (50)](https://nacha-navigator.com/x9-file-format#type-50) that describes it and an [Image View Data (52)](https://nacha-navigator.com/x9-file-format#type-52) that carries the bytes. A check usually has two views, front (View Side Indicator 0) then back (1); an [Image View Analysis (54)](https://nacha-navigator.com/x9-file-format#type-54) may follow either. - **TIFF with Group 4 compression is the default.** Image View Format 00 (TIFF 6) with compression 00 (CCITT Group 4, a black-and-white fax encoding) needs no agreement between the banks; JPEG, PNG and the other formats do. ANSI X9.100-181 defines the TIFF profile for exchanged images. - **The image is near the end of the 52.** After the fixed fields (to position 105) come the image reference key (X bytes), a 5-digit signature length and the digital signature (Y bytes), then a 7-digit image length and the image (Z bytes). The image data starts at byte 118 + X + Y of the record. - **The 50 states what the 52 should hold:** whether an image is present (Image Indicator), its format and compression, and its size in bytes. The X9 Viewer compares them with the image it finds and decodes TIFF Group 4 views for display. ## Totals and counts the viewer checks Every control record is compared with what the file actually holds. Amounts are compared to the cent. - **Bundle Control (70):** the number of items (checks or returns), their total amount, the total of the checks whose MICR Valid Indicator is 1 (a warning when it is off) and the number of image views (50 records) in the bundle. - **Cash Letter Control (90):** the number of bundles, items and image views in the cash letter, and the items’ total amount. - **File Control (99):** the number of cash letters, the number of records of every type (the 01 and 99 included), the number of items and their total amount. - **Credits:** from the 2008 edition on, the Credit Total Indicator in the 70, 90 and 99 says whether credit records (61, 62) are part of those counts and totals: 1 includes them, 0 leaves them out. With a blank indicator, or in a DSTU file, the viewer accepts either. - **Items:** each check’s or return’s addendum count against the addenda that follow it, and the record numbers of those addenda. A Routing Number Summary (85) is checked against the items for its routing number (a warning). ## Record types The 25 record types the X9 Viewer decodes. Types 61, 62 and 68 are not in DSTU X9.37-2003; 40 and 41 are only in it; and 61 is not defined by either standard: the bank or clearing arrangement sets its layout. **X9.37 record types** | Type | Record | Bytes | DSTU 2003 | X9.100-187 | What it holds | | --- | --- | --- | --- | --- | --- | | [01](https://nacha-navigator.com/x9-file-format#type-01) | File Header Record | 80 | Yes | Yes | Opens the file: standard level, test or production, immediate destination and origin, and creation date and time. | | [10](https://nacha-navigator.com/x9-file-format#type-10) | Cash Letter Header Record | 80 | Yes | Yes | Opens a cash letter: the bundles sent together for one business day, with collection type, routing numbers and cash letter ID. | | [20](https://nacha-navigator.com/x9-file-format#type-20) | Bundle Header Record | 80 | Yes | Yes | Opens a bundle of items within a cash letter, with its business date, ID and sequence number. | | [25](https://nacha-navigator.com/x9-file-format#type-25) | Check Detail Record | 80 | Yes | Yes | One check presented for payment: MICR line data (routing number, On-Us, Auxiliary On-Us), amount and item sequence number. | | [26](https://nacha-navigator.com/x9-file-format#type-26) | Check Detail Addendum A Record | 80 | Yes | Yes | Bank of first deposit (BOFD) endorsement: return location, BOFD business date, deposit account and payee. | | [27](https://nacha-navigator.com/x9-file-format#type-27) | Check Detail Addendum B Record | Variable | Yes | Yes | Image archive reference for the check: microfilm sequence number and a variable-length image reference key. | | [28](https://nacha-navigator.com/x9-file-format#type-28) | Check Detail Addendum C Record | 80 | Yes | Yes | A subsequent endorsement, one record per endorsing bank after the BOFD. | | [31](https://nacha-navigator.com/x9-file-format#type-31) | Return Record | 80 | Yes | Yes | One returned item: payor bank routing number, On-Us, amount, return reason and forward bundle date. | | [32](https://nacha-navigator.com/x9-file-format#type-32) | Return Addendum A Record | 80 | Yes | Yes | BOFD endorsement on the returned item (same layout as type 26). | | [33](https://nacha-navigator.com/x9-file-format#type-33) | Return Addendum B Record | 80 | Yes | Yes | Payor bank details for the return: bank name, item sequence number, business date and payor account name. | | [34](https://nacha-navigator.com/x9-file-format#type-34) | Return Addendum C Record | Variable | Yes | Yes | Image archive reference for the returned item (same layout as type 27). | | [35](https://nacha-navigator.com/x9-file-format#type-35) | Return Addendum D Record | 80 | Yes | Yes | An endorsing bank on the returned item (same layout as type 28). | | [40](https://nacha-navigator.com/x9-file-format#type-40) | Account Totals Detail Record | 80 | Yes | No | Item count and amount for a key account or account range. | | [41](https://nacha-navigator.com/x9-file-format#type-41) | Non-Hit Totals Detail Record | 80 | Yes | No | Item count and amount for items that matched no key account. | | [50](https://nacha-navigator.com/x9-file-format#type-50) | Image View Detail Record | 80 | Yes | Yes | Describes one image view of the item (front or back): format, compression, creator and digital-signature settings. Its Image View Data record follows. | | [52](https://nacha-navigator.com/x9-file-format#type-52) | Image View Data Record | Variable | Yes | Yes | Carries the image bytes of the preceding Image View Detail, with the image reference key and optional digital signature. | | [54](https://nacha-navigator.com/x9-file-format#type-54) | Image View Analysis Record | 80 | Yes | Yes | Image quality and usability test results for the preceding image view. | | [61](https://nacha-navigator.com/x9-file-format#type-61) | Credit Reconciliation Record | 80 | No | No | A credit for the deposit, within a cash letter or bundle. | | [62](https://nacha-navigator.com/x9-file-format#type-62) | Credit Record | 100 | No | Yes | A credit for the deposit, with a 14-digit amount. | | [68](https://nacha-navigator.com/x9-file-format#type-68) | User Record | Variable | No | Yes | Data defined by the record owner: the general format, or format 001 for a payee endorsement. | | [70](https://nacha-navigator.com/x9-file-format#type-70) | Bundle Control Record | 80 | Yes | Yes | Closes a bundle with its item count, total amount, MICR-valid amount and image count. | | [75](https://nacha-navigator.com/x9-file-format#type-75) | Box Summary Record | 80 | Yes | Yes | Totals for a box of bundles: destination, bundle count and box total. | | [85](https://nacha-navigator.com/x9-file-format#type-85) | Routing Number Summary Record | 80 | Yes | Yes | Item count and amount totals for one routing number within the cash letter. | | [90](https://nacha-navigator.com/x9-file-format#type-90) | Cash Letter Control Record | 80 | Yes | Yes | Closes a cash letter with its bundle, item and image counts, total amount, ECE institution name and settlement date. | | [99](https://nacha-navigator.com/x9-file-format#type-99) | File Control Record | 80 | Yes | Yes | Closes the file with its cash letter, record and item counts and the file total amount. | ## Record layouts Every field of every record type, with positions counted from 1 and both ends included. Usage is M (mandatory) or C (conditional: present when it applies). Where a DSTU X9.37-2003 file differs, the differences follow the layout. In variable-length records, X, Y and Z stand for the lengths given in the record’s own length fields. **Data types used in the field tables** | Type | Characters allowed | | --- | --- | | N | Numeric: digits 0 to 9 | | A | Alphabetic: letters | | AN | Alphanumeric: letters and digits | | ANS | Alphanumeric and special characters | | B | Blank | | NB | Numeric or blank | | NS | Numeric and special characters | | NBSM | Numeric, blank and the special MICR characters (the dash, and \* for a character that could not be read) | | NBSMOS | As NBSM, plus the On-Us symbol (/) | | Binary | Bytes that are not text: image data and digital signatures | ### 01 File Header Record Opens the file: standard level, test or production, immediate destination and origin, and creation date and time. 80 bytes. Defined in DSTU X9.37-2003, X9.100-187-2008/2013/2016. **X9.100-187 (2008 to 2016 editions): 80 bytes** | Position | Field | Length | Type | Usage | Description | | --- | --- | --- | --- | --- | --- | | 1–2 | Record Type | 2 | N | M | Always "01". | | 3–4 | Standard Level | 2 | N | M | Edition of the standard the file follows. [Standard Level codes](https://nacha-navigator.com/x9-file-format#codes-standard-level) | | 5 | Test File Indicator | 1 | A | M | Whether the file is test or production. | | 6–14 | Immediate Destination Routing Number | 9 | N | M | Routing number of the institution receiving the file. | | 15–23 | Immediate Origin Routing Number | 9 | N | M | Routing number of the institution sending the file. | | 24–31 | File Creation Date | 8 | N | M | Date the file was created (YYYYMMDD). | | 32–35 | File Creation Time | 4 | N | M | Time the file was created (hhmm, 24-hour clock). | | 36 | Resend Indicator | 1 | A | M | Whether the file is being resent. | | 37–54 | Immediate Destination Name | 18 | ANS | C | Name of the institution receiving the file. | | 55–72 | Immediate Origin Name | 18 | ANS | C | Name of the institution sending the file. | | 73 | File ID Modifier | 1 | AN | C | Distinguishes files created on the same date and time between the same institutions. | | 74–75 | Country Code | 2 | A | C | Country of the sending institution (e.g. US). | | 76–79 | User Field | 4 | ANS | C | For use at the discretion of the institution creating the record. | | 80 | Companion Document Indicator | 1 | AN | C | Identifies the companion document (clearing arrangement rules) the file follows. Added in X9.100-187-2008; Reserved in DSTU X9.37-2003. | **DSTU X9.37-2003: the fields that differ from X9.100-187 (2008 to 2016 editions)** | Position | Field | Length | Type | Usage | Description | | --- | --- | --- | --- | --- | --- | | 80 | Reserved | 1 | B | M | Reserved for future use; blank. | ### 10 Cash Letter Header Record Opens a cash letter: the bundles sent together for one business day, with collection type, routing numbers and cash letter ID. 80 bytes. Defined in DSTU X9.37-2003, X9.100-187-2008/2013/2016. **X9.100-187 (2008 to 2016 editions): 80 bytes** | Position | Field | Length | Type | Usage | Description | | --- | --- | --- | --- | --- | --- | | 1–2 | Record Type | 2 | N | M | Always "10". | | 3–4 | Collection Type Indicator | 2 | N | M | Kind of items in the cash letter. [Collection Type Indicator codes](https://nacha-navigator.com/x9-file-format#codes-collection-type) | | 5–13 | Destination Routing Number | 9 | N | M | Routing number of the institution the cash letter is sent to. | | 14–22 | ECE Institution Routing Number | 9 | N | M | Routing number of the institution that created the cash letter. | | 23–30 | Cash Letter Business Date | 8 | N | M | Business day of the cash letter (YYYYMMDD). | | 31–38 | Cash Letter Creation Date | 8 | N | M | Date the cash letter was created (YYYYMMDD). | | 39–42 | Cash Letter Creation Time | 4 | N | M | Time the cash letter was created (hhmm). | | 43 | Cash Letter Record Type Indicator | 1 | A | M | Which item and image records the cash letter contains. [Cash Letter Record Type Indicator codes](https://nacha-navigator.com/x9-file-format#codes-cash-letter-record-type) | | 44 | Cash Letter Documentation Type Indicator | 1 | AN | C | Default documentation type for the items; Z means each item states its own. [Documentation Type Indicator codes](https://nacha-navigator.com/x9-file-format#codes-documentation-type) | | 45–52 | Cash Letter ID | 8 | AN | M | Identifier assigned by the institution that created the cash letter. | | 53–66 | Originator Contact Name | 14 | ANS | C | Contact at the institution that created the cash letter. | | 67–76 | Originator Contact Phone Number | 10 | N | C | Phone number of the originator contact. | | 77 | Fed Work Type | 1 | AN | C | Federal Reserve work type, when the cash letter is sent to the Federal Reserve. | | 78 | Returns Indicator | 1 | A | C | Kind of returns in a return cash letter. Added in X9.100-187-2008; Reserved in DSTU X9.37-2003. | | 79 | User Field | 1 | ANS | C | For use at the discretion of the institution creating the record. | | 80 | Reserved | 1 | B | M | Reserved for future use; blank. | **DSTU X9.37-2003: the fields that differ from X9.100-187 (2008 to 2016 editions)** | Position | Field | Length | Type | Usage | Description | | --- | --- | --- | --- | --- | --- | | 45–52 | Cash Letter ID | 8 | AN | C | Identifier assigned by the institution that created the cash letter. | | 78 | User Field | 1 | ANS | C | For use at the discretion of the institution creating the record. | | 79–80 | Reserved | 2 | B | M | Reserved for future use; blank. | ### 20 Bundle Header Record Opens a bundle of items within a cash letter, with its business date, ID and sequence number. 80 bytes. Defined in DSTU X9.37-2003, X9.100-187-2008/2013/2016. **X9.100-187 (2008 to 2016 editions): 80 bytes** | Position | Field | Length | Type | Usage | Description | | --- | --- | --- | --- | --- | --- | | 1–2 | Record Type | 2 | N | M | Always "20". | | 3–4 | Collection Type Indicator | 2 | N | M | Kind of items in the bundle. [Collection Type Indicator codes](https://nacha-navigator.com/x9-file-format#codes-collection-type) | | 5–13 | Destination Routing Number | 9 | N | M | Routing number of the institution the bundle is sent to. | | 14–22 | ECE Institution Routing Number | 9 | N | M | Routing number of the institution that created the bundle. | | 23–30 | Bundle Business Date | 8 | N | M | Business day of the bundle (YYYYMMDD). | | 31–38 | Bundle Creation Date | 8 | N | M | Date the bundle was created (YYYYMMDD). | | 39–48 | Bundle ID | 10 | AN | C | Identifier assigned by the institution that created the bundle. | | 49–52 | Bundle Sequence Number | 4 | NB | C | Order of the bundle within the cash letter. | | 53–54 | Cycle Number | 2 | AN | C | Presentment cycle agreed between the exchange partners. | | 55–63 | Reserved | 9 | B | M | Reserved for future use; blank. | | 64–68 | User Field | 5 | ANS | C | For use at the discretion of the institution creating the record. | | 69–80 | Reserved | 12 | B | M | Reserved for future use; blank. | **DSTU X9.37-2003: the fields that differ from X9.100-187 (2008 to 2016 editions)** | Position | Field | Length | Type | Usage | Description | | --- | --- | --- | --- | --- | --- | | 55–63 | Return Location Routing Number | 9 | N | C | Where returns for the bundle should be sent. Reserved from X9.100-187-2008 on. | ### 25 Check Detail Record One check presented for payment: MICR line data (routing number, On-Us, Auxiliary On-Us), amount and item sequence number. 80 bytes. Defined in DSTU X9.37-2003, X9.100-187-2008/2013/2016. **DSTU X9.37-2003 and X9.100-187 (2008 to 2016 editions), the same layout: 80 bytes** | Position | Field | Length | Type | Usage | Description | | --- | --- | --- | --- | --- | --- | | 1–2 | Record Type | 2 | N | M | Always "25". | | 3–17 | Auxiliary On-Us | 15 | NBSM | C | MICR Auxiliary On-Us field: usually the serial number of a business check. | | 18 | External Processing Code | 1 | NS | C | MICR position 44, used for special purposes authorized by X9. | | 19–26 | Payor Bank Routing Number | 8 | N | M | First 8 digits (TTTTAAAA) of the routing number of the bank the check is drawn on. | | 27 | Payor Bank Routing Number Check Digit | 1 | N | M | Ninth digit of the payor bank routing number (ABA check digit). | | 28–47 | On-Us | 20 | NBSMOS | C | MICR On-Us field: the payor's account number and often the serial number; '/' is the On-Us symbol. | | 48–57 | Item Amount | 10 | N | M | Amount of the check in cents. | | 58–72 | ECE Institution Item Sequence Number | 15 | NB | M | Number assigned by the institution that created the record; unique within the file. | | 73 | Documentation Type Indicator | 1 | AN | C | Whether an image and/or paper accompanies the item. [Documentation Type Indicator codes](https://nacha-navigator.com/x9-file-format#codes-documentation-type) | | 74 | Electronic Return Acceptance Indicator | 1 | AN | C | Whether the institution that created the record will accept electronic returns and return notifications for the item. | | 75 | MICR Valid Indicator | 1 | N | C | Result of reading the MICR line. [MICR Valid Indicator codes](https://nacha-navigator.com/x9-file-format#codes-micr-valid) | | 76 | BOFD Indicator | 1 | A | M | Whether the ECE institution is the bank of first deposit. [BOFD Indicator codes](https://nacha-navigator.com/x9-file-format#codes-bofd) | | 77–78 | Check Detail Record Addendum Count | 2 | N | M | Number of Check Detail Addendum A, B and C records (26/27/28) that follow. | | 79 | Correction Indicator | 1 | N | C | Whether and how the MICR line was repaired. [Correction Indicator codes](https://nacha-navigator.com/x9-file-format#codes-correction) | | 80 | Archive Type Indicator | 1 | AN | C | How the item is archived. [Archive Type Indicator codes](https://nacha-navigator.com/x9-file-format#codes-archive-type) | ### 26 Check Detail Addendum A Record Bank of first deposit (BOFD) endorsement: return location, BOFD business date, deposit account and payee. 80 bytes. Defined in DSTU X9.37-2003, X9.100-187-2008/2013/2016. **X9.100-187 (2008 to 2016 editions): 80 bytes** | Position | Field | Length | Type | Usage | Description | | --- | --- | --- | --- | --- | --- | | 1–2 | Record Type | 2 | N | M | Always "26". | | 3 | Check Detail Addendum A Record Number | 1 | N | M | Position of this record among the item’s Addendum A records, starting at 1. | | 4–12 | Return Location Routing Number | 9 | N | M | Where returns and return notifications should be sent; usually the BOFD. | | 13–20 | BOFD Business (Endorsement) Date | 8 | N | M | Business date of the BOFD endorsement (YYYYMMDD). | | 21–35 | BOFD Item Sequence Number | 15 | NB | C | Sequence number assigned by the BOFD. | | 36–53 | Deposit Account Number at BOFD | 18 | ANS | C | Account the item was deposited to. | | 54–58 | BOFD Deposit Branch | 5 | ANS | C | Branch where the item was deposited. | | 59–73 | Payee Name | 15 | ANS | C | Name of the payee. | | 74 | Truncation Indicator | 1 | A | M | Whether the BOFD truncated the original check. | | 75 | BOFD Conversion Indicator | 1 | AN | C | How the BOFD converted the item. [Conversion Indicator codes](https://nacha-navigator.com/x9-file-format#codes-conversion) | | 76 | BOFD Correction Indicator | 1 | N | C | Whether and how the BOFD repaired the MICR line. [Correction Indicator codes](https://nacha-navigator.com/x9-file-format#codes-correction) | | 77 | User Field | 1 | ANS | C | For use at the discretion of the institution creating the record. | | 78–80 | Reserved | 3 | B | M | Reserved for future use; blank. | **DSTU X9.37-2003: the fields that differ from X9.100-187 (2008 to 2016 editions)** | Position | Field | Length | Type | Usage | Description | | --- | --- | --- | --- | --- | --- | | 4–12 | Bank of First Deposit (BOFD) Routing Number | 9 | N | M | Routing number of the bank of first deposit. | ### 27 Check Detail Addendum B Record Image archive reference for the check: microfilm sequence number and a variable-length image reference key. Variable length. Defined in DSTU X9.37-2003, X9.100-187-2008/2013/2016. **DSTU X9.37-2003 and X9.100-187 (2008 to 2016 editions), the same layout: 46+X bytes** | Position | Field | Length | Type | Usage | Description | | --- | --- | --- | --- | --- | --- | | 1–2 | Record Type | 2 | N | M | Always "27". | | 3 | Image Reference Key Indicator | 1 | N | M | Whether an Image Reference Key is present. | | 4–18 | Microfilm Archive Sequence Number | 15 | NB | C | Sequence number of the item in the microfilm archive. | | 19–22 | Length of Image Reference Key | 4 | N | M | Number of bytes in the Image Reference Key that follows. | | 23–22+X | Image Reference Key | X | ANS | C | Key for retrieving the archived image. Its length, X, is the value of field 4 (Length of Image Reference Key). | | 23+X–37+X | Description | 15 | ANS | C | Description of the archive reference. | | 38+X–41+X | User Field | 4 | ANS | C | For use at the discretion of the institution creating the record. | | 42+X–46+X | Reserved | 5 | B | M | Reserved for future use; blank. | ### 28 Check Detail Addendum C Record A subsequent endorsement, one record per endorsing bank after the BOFD. 80 bytes. Defined in DSTU X9.37-2003, X9.100-187-2008/2013/2016. **X9.100-187 (2008 to 2016 editions): 80 bytes** | Position | Field | Length | Type | Usage | Description | | --- | --- | --- | --- | --- | --- | | 1–2 | Record Type | 2 | N | M | Always "28". | | 3–4 | Check Detail Addendum C Record Number | 2 | N | M | Position of this record among the item’s endorsement addenda, starting at 01. | | 5–13 | Endorsing Bank Routing Number | 9 | N | M | Routing number of the endorsing bank. | | 14–21 | Endorsing Bank Business (Endorsement) Date | 8 | N | M | Business date of the endorsement (YYYYMMDD). | | 22–36 | Endorsing Bank Item Sequence Number | 15 | NB | M | Sequence number assigned by the endorsing bank. | | 37 | Truncation Indicator | 1 | A | M | Whether the endorsing bank truncated the original check. | | 38 | Endorsing Bank Conversion Indicator | 1 | AN | C | How the endorsing bank converted the item. [Conversion Indicator codes](https://nacha-navigator.com/x9-file-format#codes-conversion) | | 39 | Endorsing Bank Correction Indicator | 1 | N | C | Whether and how the endorsing bank repaired the MICR line. [Correction Indicator codes](https://nacha-navigator.com/x9-file-format#codes-correction) | | 40 | Return Reason | 1 | AN | C | Return reason, when the endorsement is on a returned item. [Return Reason codes](https://nacha-navigator.com/x9-file-format#codes-return-reason) Meanings as listed in X9.100-187-2008. From the 2016 edition on, return reasons are defined in ANSI X9.100-188 (current edition 2023), which separates customer and administrative reasons and may list other codes; check them against your exchange partner’s list. | | 41–59 | User Field | 19 | ANS | C | For use at the discretion of the institution creating the record. | | 60 | Endorsing Bank Identifier | 1 | AN | C | Role of the endorsing bank in the exchange. Added in X9.100-187-2008; Reserved in DSTU X9.37-2003. | | 61–80 | Reserved | 20 | B | M | Reserved for future use; blank. | **DSTU X9.37-2003: the fields that differ from X9.100-187 (2008 to 2016 editions)** | Position | Field | Length | Type | Usage | Description | | --- | --- | --- | --- | --- | --- | | 40 | Return Reason | 1 | AN | C | Return reason, when the endorsement is on a returned item. [Return Reason codes](https://nacha-navigator.com/x9-file-format#codes-return-reason) Meanings as listed for DSTU X9.37-2003, where T is Stop Payment Suspect. | | 60–80 | Reserved | 21 | B | M | Reserved for future use; blank. | ### 31 Return Record One returned item: payor bank routing number, On-Us, amount, return reason and forward bundle date. 80 bytes. Defined in DSTU X9.37-2003, X9.100-187-2008/2013/2016. **X9.100-187 (2008 to 2016 editions): 80 bytes** | Position | Field | Length | Type | Usage | Description | | --- | --- | --- | --- | --- | --- | | 1–2 | Record Type | 2 | N | M | Always "31". | | 3–10 | Payor Bank Routing Number | 8 | N | M | First 8 digits (TTTTAAAA) of the routing number of the bank the item was drawn on. | | 11 | Payor Bank Routing Number Check Digit | 1 | N | M | Ninth digit of the payor bank routing number (ABA check digit). | | 12–31 | On-Us Return Record | 20 | NBSMOS | C | MICR On-Us field of the returned item; '/' is the On-Us symbol. | | 32–41 | Item Amount | 10 | N | M | Amount of the returned item in cents. | | 42 | Return Reason | 1 | AN | M | Why the item is being returned. [Return Reason codes](https://nacha-navigator.com/x9-file-format#codes-return-reason) Meanings as listed in X9.100-187-2008. From the 2016 edition on, return reasons are defined in ANSI X9.100-188 (current edition 2023), which separates customer and administrative reasons and may list other codes; check them against your exchange partner’s list. | | 43–44 | Return Record Addendum Count | 2 | N | M | Number of Return Addendum A, B, C and D records (32/33/34/35) that follow. | | 45 | Return Documentation Type Indicator | 1 | AN | C | Whether an image and/or paper accompanies the return. [Documentation Type Indicator codes](https://nacha-navigator.com/x9-file-format#codes-documentation-type) | | 46–53 | Forward Bundle Date | 8 | N | C | Business date of the bundle in which the item was originally presented. | | 54–68 | ECE Institution Item Sequence Number | 15 | NB | C | Sequence number from the original forward presentment. | | 69 | External Processing Code | 1 | NS | C | MICR position 44, used for special purposes authorized by X9. | | 70 | Return Notification Indicator | 1 | N | M | Whether the record is a return or a return notification. | | 71 | Return Archive Type Indicator | 1 | AN | C | How the returned item is archived. [Archive Type Indicator codes](https://nacha-navigator.com/x9-file-format#codes-archive-type) | | 72 | Number of Times Returned | 1 | N | C | How many times the item has been returned. Added in X9.100-187-2008; Reserved in DSTU X9.37-2003. | | 73–80 | Reserved | 8 | B | M | Reserved for future use; blank. | **DSTU X9.37-2003: the fields that differ from X9.100-187 (2008 to 2016 editions)** | Position | Field | Length | Type | Usage | Description | | --- | --- | --- | --- | --- | --- | | 42 | Return Reason | 1 | AN | M | Why the item is being returned. [Return Reason codes](https://nacha-navigator.com/x9-file-format#codes-return-reason) Meanings as listed for DSTU X9.37-2003, where T is Stop Payment Suspect. | | 72–80 | Reserved | 9 | B | M | Reserved for future use; blank. | ### 32 Return Addendum A Record BOFD endorsement on the returned item (same layout as type 26). 80 bytes. Defined in DSTU X9.37-2003, X9.100-187-2008/2013/2016. The layout is that of [type 26](https://nacha-navigator.com/x9-file-format#type-26), Check Detail Addendum A Record, except for the fields below. **X9.100-187 (2008 to 2016 editions): the fields that differ from type 26** | Position | Field | Length | Type | Usage | Description | | --- | --- | --- | --- | --- | --- | | 3 | Return Addendum A Record Number | 1 | N | M | Position of this record among the item’s Addendum A records, starting at 1. | | 76 | BOFD Correction Indicator | 1 | N | C | Whether and how the BOFD repaired the MICR line. [Correction Indicator codes](https://nacha-navigator.com/x9-file-format#codes-correction) | **DSTU X9.37-2003: the fields that differ from X9.100-187 (2008 to 2016 editions)** | Position | Field | Length | Type | Usage | Description | | --- | --- | --- | --- | --- | --- | | 4–12 | Bank of First Deposit (BOFD) Routing Number | 9 | N | M | Routing number of the bank of first deposit. | ### 33 Return Addendum B Record Payor bank details for the return: bank name, item sequence number, business date and payor account name. 80 bytes. Defined in DSTU X9.37-2003, X9.100-187-2008/2013/2016. **DSTU X9.37-2003 and X9.100-187 (2008 to 2016 editions), the same layout: 80 bytes** | Position | Field | Length | Type | Usage | Description | | --- | --- | --- | --- | --- | --- | | 1–2 | Record Type | 2 | N | M | Always "33". | | 3–20 | Payor Bank Name | 18 | ANS | C | Name of the bank the item was drawn on. | | 21–35 | Auxiliary On-Us | 15 | NBSM | C | MICR Auxiliary On-Us field of the returned item. | | 36–50 | Payor Bank Item Sequence Number | 15 | NB | C | Sequence number assigned by the payor bank. | | 51–58 | Payor Bank Business Date | 8 | N | C | Business date of the payor bank (YYYYMMDD). | | 59–80 | Payor Account Name | 22 | ANS | C | Name on the payor’s account. | ### 34 Return Addendum C Record Image archive reference for the returned item (same layout as type 27). Variable length. Defined in DSTU X9.37-2003, X9.100-187-2008/2013/2016. The layout is that of [type 27](https://nacha-navigator.com/x9-file-format#type-27), Check Detail Addendum B Record; only the record type differs. ### 35 Return Addendum D Record An endorsing bank on the returned item (same layout as type 28). 80 bytes. Defined in DSTU X9.37-2003, X9.100-187-2008/2013/2016. The layout is that of [type 28](https://nacha-navigator.com/x9-file-format#type-28), Check Detail Addendum C Record, except for the fields below. **X9.100-187 (2008 to 2016 editions): the fields that differ from type 28** | Position | Field | Length | Type | Usage | Description | | --- | --- | --- | --- | --- | --- | | 3–4 | Return Addendum D Record Number | 2 | N | M | Position of this record among the item’s endorsement addenda, starting at 01. | **DSTU X9.37-2003: the fields that differ from X9.100-187 (2008 to 2016 editions)** | Position | Field | Length | Type | Usage | Description | | --- | --- | --- | --- | --- | --- | | 40 | Return Reason | 1 | AN | C | Return reason, when the endorsement is on a returned item. [Return Reason codes](https://nacha-navigator.com/x9-file-format#codes-return-reason) Meanings as listed for DSTU X9.37-2003, where T is Stop Payment Suspect. | | 60–80 | Reserved | 21 | B | M | Reserved for future use; blank. | ### 40 Account Totals Detail Record Item count and amount for a key account or account range. 80 bytes. Defined in DSTU X9.37-2003. **DSTU X9.37-2003: 80 bytes** | Position | Field | Length | Type | Usage | Description | | --- | --- | --- | --- | --- | --- | | 1–2 | Record Type | 2 | N | M | Always "40". | | 3–11 | Destination Routing Number | 9 | N | M | Routing number the totals are reported to. | | 12–29 | Key Account / Low Account in Key Account Range | 18 | ANS | M | Key account, or the first account of a key account range. | | 30–47 | Key Account / High Account in Key Account Range | 18 | ANS | M | Key account, or the last account of a key account range. | | 48–59 | Total Item Count | 12 | N | M | Items for the key account (range). | | 60–73 | Total Item Amount | 14 | N | M | Amount of the items for the key account (range), in cents. | | 74–77 | User Field | 4 | ANS | C | For use at the discretion of the institution creating the record. | | 78–80 | Reserved | 3 | B | M | Reserved for future use; blank. | ### 41 Non-Hit Totals Detail Record Item count and amount for items that matched no key account. 80 bytes. Defined in DSTU X9.37-2003. **DSTU X9.37-2003: 80 bytes** | Position | Field | Length | Type | Usage | Description | | --- | --- | --- | --- | --- | --- | | 1–2 | Record Type | 2 | N | M | Always "41". | | 3–11 | Destination Routing Number | 9 | N | M | Routing number the totals are reported to. | | 12 | Non-Hit Indicator | 1 | AN | M | Which non-hit totals the record reports. | | 13–24 | Total Item Count | 12 | N | M | Items that did not match a key account. | | 25–38 | Total Item Amount | 14 | N | M | Amount of the items that did not match a key account, in cents. | | 39–42 | User Field | 4 | ANS | C | For use at the discretion of the institution creating the record. | | 43–80 | Reserved | 38 | B | M | Reserved for future use; blank. | ### 50 Image View Detail Record Describes one image view of the item (front or back): format, compression, creator and digital-signature settings. Its Image View Data record follows. 80 bytes. Defined in DSTU X9.37-2003, X9.100-187-2008/2013/2016. **X9.100-187 (2008 to 2016 editions): 80 bytes** | Position | Field | Length | Type | Usage | Description | | --- | --- | --- | --- | --- | --- | | 1–2 | Record Type | 2 | N | M | Always "50". | | 3 | Image Indicator | 1 | N | M | Whether an image view is present and whether it shows the actual check. [Image Indicator codes](https://nacha-navigator.com/x9-file-format#codes-image-indicator) | | 4–12 | Image Creator Routing Number | 9 | N | M | Routing number of the institution that created the image. | | 13–20 | Image Creator Date | 8 | N | M | Date the image was created (YYYYMMDD). | | 21–22 | Image View Format Indicator | 2 | N | C | Image file format; 00 (TIFF 6) needs no agreement, the others do. [Image View Format Indicator codes](https://nacha-navigator.com/x9-file-format#codes-image-format) | | 23–24 | Image View Compression Algorithm Identifier | 2 | N | C | Compression; 00 (CCITT Group 4) needs no agreement, the others do. [Image View Compression Algorithm Identifier codes](https://nacha-navigator.com/x9-file-format#codes-image-compression) | | 25–31 | Image View Data Size | 7 | N | C | Number of bytes in the image data of the following Image View Data record. | | 32 | View Side Indicator | 1 | N | M | Front or back of the item. | | 33–34 | View Descriptor | 2 | N | M | Full view (00) or one of the partial views (01-13: date, payee, amount, signature, MICR line, endorsements, ...). | | 35 | Digital Signature Indicator | 1 | N | C | Whether the Image View Data record carries a digital signature. | | 36–37 | Digital Signature Method | 2 | N | C | Algorithm of the digital signature. [Digital Signature Method codes](https://nacha-navigator.com/x9-file-format#codes-signature-method) | | 38–42 | Security Key Size | 5 | N | C | Length of the digital signature key in bits. | | 43–49 | Start of Protected Data | 7 | N | C | Offset of the first image byte covered by the digital signature. | | 50–56 | Length of Protected Data | 7 | N | C | Number of image bytes covered by the digital signature. | | 57 | Image Recreate Indicator | 1 | N | C | Whether the sender can recreate the image view. | | 58–65 | User Field | 8 | ANS | C | For use at the discretion of the institution creating the record. | | 66 | Image TIFF Variance Indicator | 1 | AN | C | Whether the TIFF image uses one of the variances allowed by X9.100-181. Added in X9.100-187-2008; Reserved in DSTU X9.37-2003. | | 67 | Override Indicator | 1 | AN | C | Overrides an image quality (IQA) test failure; letters identify the failed test. Added in X9.100-187-2008; Reserved in DSTU X9.37-2003. | | 68–80 | Reserved | 13 | B | M | Reserved for future use; blank. | **DSTU X9.37-2003: the fields that differ from X9.100-187 (2008 to 2016 editions)** | Position | Field | Length | Type | Usage | Description | | --- | --- | --- | --- | --- | --- | | 66–80 | Reserved | 15 | B | M | Reserved for future use; blank. | ### 52 Image View Data Record Carries the image bytes of the preceding Image View Detail, with the image reference key and optional digital signature. Variable length. Defined in DSTU X9.37-2003, X9.100-187-2008/2013/2016. Variable length: the image data starts at byte 118 + X + Y (1-based), where X and Y are the reference key and signature lengths. **DSTU X9.37-2003 and X9.100-187 (2008 to 2016 editions), the same layout: 117+X+Y+Z bytes** | Position | Field | Length | Type | Usage | Description | | --- | --- | --- | --- | --- | --- | | 1–2 | Record Type | 2 | N | M | Always "52". | | 3–11 | ECE Institution Routing Number | 9 | N | M | Routing number of the institution that created the item record. | | 12–19 | Bundle Business Date | 8 | N | M | Business date of the bundle the image belongs to (YYYYMMDD). | | 20–21 | Cycle Number | 2 | AN | C | Cycle number from the Bundle Header. | | 22–36 | ECE Institution Item Sequence Number | 15 | NB | C | Sequence number of the item the image belongs to. | | 37–52 | Security Originator Name | 16 | ANS | C | Originator of the digital signature. | | 53–68 | Security Authenticator Name | 16 | ANS | C | Authenticator of the digital signature. | | 69–84 | Security Key Name | 16 | ANS | C | Name of the key used for the digital signature. | | 85 | Clipping Origin | 1 | NB | C | Corner the clipping coordinates are measured from (0 = no clipping). | | 86–89 | Clipping Coordinate h1 | 4 | N | C | Horizontal start of the clipped area, in pixels. | | 90–93 | Clipping Coordinate h2 | 4 | N | C | Horizontal end of the clipped area, in pixels. | | 94–97 | Clipping Coordinate v1 | 4 | N | C | Vertical start of the clipped area, in pixels. | | 98–101 | Clipping Coordinate v2 | 4 | N | C | Vertical end of the clipped area, in pixels. | | 102–105 | Length of Image Reference Key | 4 | NB | C | Number of bytes (X) in the Image Reference Key. | | 106–105+X | Image Reference Key | X | ANS | C | Key the creator uses to locate the image. Its length, X, is the value of field 14 (Length of Image Reference Key). | | 106+X–110+X | Length of Digital Signature | 5 | NB | C | Number of bytes (Y) in the digital signature. | | 111+X–110+X+Y | Digital Signature | Y | Binary | C | Digital signature over the protected image data (binary). Its length, Y, is the value of field 16 (Length of Digital Signature). | | 111+X+Y–117+X+Y | Length of Image Data | 7 | NB | C | Number of bytes (Z) of image data. | | 118+X+Y–117+X+Y+Z | Image Data | Z | Binary | C | The image view (binary; TIFF Group 4 unless agreed otherwise). Its length, Z, is the value of field 18 (Length of Image Data). | ### 54 Image View Analysis Record Image quality and usability test results for the preceding image view. 80 bytes. Defined in DSTU X9.37-2003, X9.100-187-2008/2013/2016. **DSTU X9.37-2003 and X9.100-187 (2008 to 2016 editions), the same layout: 80 bytes** | Position | Field | Length | Type | Usage | Description | | --- | --- | --- | --- | --- | --- | | 1–2 | Record Type | 2 | N | M | Always "54". | | 3 | Global Image Quality | 1 | N | M | Whether the image was tested for image quality conditions, and whether any were reported. [Global Image Quality codes](https://nacha-navigator.com/x9-file-format#codes-global-image-quality) | | 4 | Global Image Usability | 1 | N | M | Whether the image was tested for image usability conditions, and whether any were reported. [Global Image Usability codes](https://nacha-navigator.com/x9-file-format#codes-global-image-usability) | | 5 | Imaging Bank Specific Test | 1 | N | M | Whether the imaging bank ran tests of its own; their results are reported in the User Field. [Imaging Bank Specific Test codes](https://nacha-navigator.com/x9-file-format#codes-bank-specific-test) | | 6 | Partial Image | 1 | N | C | Part of the item is missing from the image. [Image quality tests codes](https://nacha-navigator.com/x9-file-format#codes-quality-test) | | 7 | Excessive Image Skew | 1 | N | C | The image is skewed beyond the agreed limit. [Image quality tests codes](https://nacha-navigator.com/x9-file-format#codes-quality-test) | | 8 | Piggyback Image | 1 | N | C | Another item overlaps the image. [Image quality tests codes](https://nacha-navigator.com/x9-file-format#codes-quality-test) | | 9 | Too Light or Too Dark | 1 | N | C | The image is too light or too dark. [Image quality tests codes](https://nacha-navigator.com/x9-file-format#codes-quality-test) | | 10 | Streaks and/or Bands | 1 | N | C | The image has streaks or bands. [Image quality tests codes](https://nacha-navigator.com/x9-file-format#codes-quality-test) | | 11 | Below Minimum Image Size | 1 | N | C | The image is smaller than the agreed minimum. [Image quality tests codes](https://nacha-navigator.com/x9-file-format#codes-quality-test) | | 12 | Exceeds Maximum Image Size | 1 | N | C | The image is larger than the agreed maximum. [Image quality tests codes](https://nacha-navigator.com/x9-file-format#codes-quality-test) | | 13–25 | Reserved | 13 | B | M | Reserved for future use; blank. | | 26 | Image-Enabled POD | 1 | N | C | Whether the image was used in an image-enabled proof of deposit (POD) application. [Image-Enabled POD codes](https://nacha-navigator.com/x9-file-format#codes-image-enabled-pod) | | 27 | Source Document Bad | 1 | N | C | For an unusable image, whether the source document is unusable too. [Source Document Bad codes](https://nacha-navigator.com/x9-file-format#codes-source-document-bad) | | 28 | Date Usability | 1 | N | C | Whether the date on the image can be used. [Image usability tests codes](https://nacha-navigator.com/x9-file-format#codes-usability-test) | | 29 | Payee Usability | 1 | N | C | Whether the payee name on the image can be used. [Image usability tests codes](https://nacha-navigator.com/x9-file-format#codes-usability-test) | | 30 | Convenience Amount Usability | 1 | N | C | Whether the numeric (convenience) amount on the image can be used. [Image usability tests codes](https://nacha-navigator.com/x9-file-format#codes-usability-test) | | 31 | Legal Amount Usability | 1 | N | C | Whether the written (legal) amount on the image can be used. [Image usability tests codes](https://nacha-navigator.com/x9-file-format#codes-usability-test) | | 32 | Signature(s) Usability | 1 | N | C | Whether the signature on the image can be used. [Image usability tests codes](https://nacha-navigator.com/x9-file-format#codes-usability-test) | | 33 | Payor Name and Address Usability | 1 | N | C | Whether the payor name and address on the image can be used. [Image usability tests codes](https://nacha-navigator.com/x9-file-format#codes-usability-test) | | 34 | MICR Line Usability | 1 | N | C | Whether the MICR line on the image can be used. [Image usability tests codes](https://nacha-navigator.com/x9-file-format#codes-usability-test) | | 35 | Memo Line Usability | 1 | N | C | Whether the memo line on the image can be used. [Image usability tests codes](https://nacha-navigator.com/x9-file-format#codes-usability-test) | | 36 | Payor Bank Name and Address Usability | 1 | N | C | Whether the payor bank name and address on the image can be used. [Image usability tests codes](https://nacha-navigator.com/x9-file-format#codes-usability-test) | | 37 | Payee Endorsement Usability | 1 | N | C | Whether the payee endorsement on the image can be used. [Image usability tests codes](https://nacha-navigator.com/x9-file-format#codes-usability-test) | | 38 | BOFD Endorsement Usability | 1 | N | C | Whether the BOFD endorsement on the image can be used. [Image usability tests codes](https://nacha-navigator.com/x9-file-format#codes-usability-test) | | 39 | Transit Endorsement Usability | 1 | N | C | Whether the transit endorsement on the image can be used. [Image usability tests codes](https://nacha-navigator.com/x9-file-format#codes-usability-test) | | 40–45 | Reserved | 6 | B | M | Reserved for future use; blank. | | 46–65 | User Field | 20 | ANS | C | For use at the discretion of the institution creating the record. | | 66–80 | Reserved | 15 | B | M | Reserved for future use; blank. | ### 61 Credit Reconciliation Record A credit for the deposit, within a cash letter or bundle. 80 bytes. Bank-defined (not in DSTU X9.37-2003; X9.100-180 defines one). Type 61 is not a DSTU X9.37-2003 record, and its layout is set by the bank or clearing arrangement. Fields follow a common 80-byte credit layout; a record with a Record Usage Indicator of 5 at position 3, which moves every later field one byte to the right, is read with that layout instead. Check your exchange partner’s specification. **Bank-defined (common credit layout): 80 bytes** | Position | Field | Length | Type | Usage | Description | | --- | --- | --- | --- | --- | --- | | 1–2 | Record Type | 2 | N | M | Always "61". | | 3–17 | Auxiliary On-Us | 15 | NBSM | C | MICR Auxiliary On-Us field of the credit. | | 18 | External Processing Code | 1 | NS | C | MICR position 44. | | 19–27 | Posting Bank Routing Number | 9 | N | M | Routing number of the bank that posts the credit. | | 28–47 | On-Us | 20 | NBSMOS | C | MICR On-Us field of the credit: the account to credit. | | 48–57 | Item Amount | 10 | N | M | Amount of the credit in cents. | | 58–72 | ECE Institution Item Sequence Number | 15 | NB | C | Sequence number assigned by the institution that created the record. | | 73 | Documentation Type Indicator | 1 | AN | C | Whether an image and/or paper accompanies the credit. [Documentation Type Indicator codes](https://nacha-navigator.com/x9-file-format#codes-documentation-type) | | 74 | Type of Account Code | 1 | AN | C | Kind of account being credited. | | 75 | Source of Work Code | 1 | AN | C | Where the deposited work came from. | | 76 | Work Type | 1 | AN | C | Kind of work the credit covers. | | 77 | Debit Credit Indicator | 1 | AN | C | Whether the record is a credit or a debit adjustment. | | 78–80 | Reserved | 3 | B | M | Reserved for future use; blank. | **Bank-defined (Record Usage Indicator at position 3): 80 bytes, the fields that differ from the layout above** | Position | Field | Length | Type | Usage | Description | | --- | --- | --- | --- | --- | --- | | 3 | Record Usage Indicator | 1 | AN | M | How the record is used: 5 marks a credit/reconciliation record. Its presence means the record follows the layout with this indicator at position 3. | | 4–18 | Auxiliary On-Us | 15 | NBSM | C | MICR Auxiliary On-Us field of the credit. | | 19 | External Processing Code | 1 | NS | C | MICR position 44. | | 20–28 | Posting Bank Routing Number | 9 | N | M | Routing number of the bank that posts the credit. | | 29–48 | On-Us | 20 | NBSMOS | M | MICR On-Us field of the credit: the account to credit. | | 49–58 | Item Amount | 10 | N | M | Amount of the credit in cents. | | 59–73 | Item Sequence Number | 15 | NB | M | Sequence number that identifies the credit in the cash letter. | | 74 | Documentation Type Indicator | 1 | AN | C | Whether an image and/or paper accompanies the credit. [Documentation Type Indicator codes](https://nacha-navigator.com/x9-file-format#codes-documentation-type) | | 75 | Type of Account Code | 1 | AN | C | Kind of account being credited. | | 76–77 | Source of Work Code | 2 | AN | C | Where the deposited work came from. | ### 62 Credit Record A credit for the deposit, with a 14-digit amount. 100 bytes. Defined in X9.100-187-2013/2016. **X9.100-187-2013/2016: 100 bytes** | Position | Field | Length | Type | Usage | Description | | --- | --- | --- | --- | --- | --- | | 1–2 | Record Type | 2 | N | M | Always "62". | | 3–17 | Auxiliary On-Us | 15 | NBSM | C | MICR Auxiliary On-Us field of the credit. | | 18 | External Processing Code | 1 | NS | C | MICR position 44. | | 19–27 | Posting Bank Routing Number | 9 | N | M | Routing number of the bank that posts the credit. | | 28–47 | On-Us | 20 | NBSMOS | C | MICR On-Us field of the credit: the account to credit. | | 48–61 | Item Amount | 14 | N | M | Amount of the credit in cents. | | 62–76 | Credit Item Sequence Number | 15 | NB | C | Sequence number of the credit. | | 77 | Documentation Type Indicator | 1 | AN | C | Whether an image and/or paper accompanies the credit. [Documentation Type Indicator codes](https://nacha-navigator.com/x9-file-format#codes-documentation-type) | | 78 | Type of Account Code | 1 | AN | C | Kind of account being credited. | | 79–80 | Source of Work Code | 2 | N | C | Where the deposited work came from (21-50 are user defined). | | 81–96 | User Field | 16 | ANS | C | For use at the discretion of the institution creating the record. | | 97–100 | Reserved | 4 | B | M | Reserved for future use; blank. | ### 68 User Record Data defined by the record owner: the general format, or format 001 for a payee endorsement. Variable length. Defined in X9.100-187-2013/2016 (2008 not verified). **X9.100-187-2013/2016 (2008 not verified): 45+X bytes** | Position | Field | Length | Type | Usage | Description | | --- | --- | --- | --- | --- | --- | | 1–2 | Record Type | 2 | N | M | Always "68". | | 3 | Owner Identifier Indicator | 1 | AN | M | How the record owner is identified (e.g. by routing number). | | 4–12 | Owner Identifier | 9 | ANS | C | Identifier of the record owner. | | 13–32 | Owner Identifier Modifier | 20 | ANS | C | Qualifies the owner identifier. | | 33–35 | User Record Format Type | 3 | AN | M | Format of the user data (001 = payee endorsement). | | 36–38 | Format Type Version Level | 3 | N | M | Version of the user record format. | | 39–45 | Length of User Data | 7 | N | M | Number of bytes of user data that follow. | | 46–45+X | User Data | X | ANS | M | Data defined by the record owner. Its length, X, is the value of field 7 (Length of User Data). | **Payee endorsement (format 001): 335 bytes, the fields that differ from the layout above** | Position | Field | Length | Type | Usage | Description | | --- | --- | --- | --- | --- | --- | | 46–95 | Name of Payee | 50 | ANS | C | Name of the payee who endorsed the item. | | 96–103 | Endorsement Date | 8 | NB | C | Date of the endorsement (YYYYMMDD). | | 104–112 | Bank Routing Number | 9 | N | C | Routing number of the bank the item was deposited to. | | 113–132 | Bank Account Number | 20 | ANS | C | Account the item was deposited to. | | 133–152 | Customer Identifier | 20 | ANS | C | Identifier of the depositing customer. | | 153–202 | Customer Contact Information | 50 | ANS | C | Contact information of the depositing customer. | | 203–210 | Store / Merchant / Processing Site Number | 8 | ANS | C | Where the item was captured. | | 211–235 | Internal Control / Sequence Number | 25 | ANS | C | Capture site control or sequence number. | | 236–239 | Time | 4 | N | C | Time of the endorsement (hhmm). | | 240–269 | Operator Name / Initials | 30 | ANS | C | Operator who captured the item. | | 270–274 | Operator Number | 5 | ANS | C | Number of the operator. | | 275–304 | Manager / Supervisor Name / Initials | 30 | ANS | C | Approving manager or supervisor. | | 305–309 | Manager / Supervisor Number | 5 | ANS | C | Number of the manager or supervisor. | | 310–324 | Equipment Number | 15 | ANS | C | Capture device identifier. | | 325 | Endorsement Indicator | 1 | AN | C | Kind of endorsement. | | 326–335 | User Field | 10 | ANS | C | For use at the discretion of the institution creating the record. | ### 70 Bundle Control Record Closes a bundle with its item count, total amount, MICR-valid amount and image count. 80 bytes. Defined in DSTU X9.37-2003, X9.100-187-2008/2013/2016. **X9.100-187 (2008 to 2016 editions): 80 bytes** | Position | Field | Length | Type | Usage | Description | | --- | --- | --- | --- | --- | --- | | 1–2 | Record Type | 2 | N | M | Always "70". | | 3–6 | Items Within Bundle Count | 4 | N | M | Number of Check Detail (25) or Return (31) records in the bundle. | | 7–18 | Bundle Total Amount | 12 | N | M | Sum of the item amounts in the bundle, in cents. | | 19–30 | MICR Valid Total Amount | 12 | N | C | Sum of the amounts of checks in the bundle whose MICR Valid Indicator is 1, in cents. | | 31–35 | Images Within Bundle Count | 5 | N | M | Number of Image View Detail (50) records in the bundle. | | 36–55 | User Field | 20 | ANS | C | For use at the discretion of the institution creating the record. | | 56 | Credit Total Indicator | 1 | N | C | Whether credit records (61/62) are included in the totals. Added in X9.100-187-2008; Reserved in DSTU X9.37-2003. | | 57–80 | Reserved | 24 | B | M | Reserved for future use; blank. | **DSTU X9.37-2003: the fields that differ from X9.100-187 (2008 to 2016 editions)** | Position | Field | Length | Type | Usage | Description | | --- | --- | --- | --- | --- | --- | | 56–80 | Reserved | 25 | B | M | Reserved for future use; blank. | ### 75 Box Summary Record Totals for a box of bundles: destination, bundle count and box total. 80 bytes. Defined in DSTU X9.37-2003, X9.100-187-2008/2013/2016. **DSTU X9.37-2003 and X9.100-187 (2008 to 2016 editions), the same layout: 80 bytes** | Position | Field | Length | Type | Usage | Description | | --- | --- | --- | --- | --- | --- | | 1–2 | Record Type | 2 | N | M | Always "75". | | 3–11 | Destination Routing Number | 9 | N | M | Routing number the box is sent to. | | 12–14 | Box Sequence Number | 3 | N | M | Order of the box. | | 15–18 | Box Bundle Count | 4 | N | M | Number of bundles in the box. | | 19–26 | Box Number ID | 8 | AN | M | Identifier of the box. | | 27–40 | Box Total Amount | 14 | N | M | Sum of the item amounts in the box, in cents. | | 41–80 | Reserved | 40 | B | M | Reserved for future use; blank. | ### 85 Routing Number Summary Record Item count and amount totals for one routing number within the cash letter. 80 bytes. Defined in DSTU X9.37-2003, X9.100-187-2008/2013/2016. **DSTU X9.37-2003 and X9.100-187 (2008 to 2016 editions), the same layout: 80 bytes** | Position | Field | Length | Type | Usage | Description | | --- | --- | --- | --- | --- | --- | | 1–2 | Record Type | 2 | N | M | Always "85". | | 3–11 | Routing Number Within Cash Letter | 9 | N | M | Routing number the totals are for. | | 12–25 | Routing Number Total Amount | 14 | N | M | Sum of the amounts of the items for this routing number, in cents. | | 26–31 | Routing Number Item Count | 6 | N | M | Number of items for this routing number. | | 32–55 | User Field | 24 | ANS | C | For use at the discretion of the institution creating the record. | | 56–80 | Reserved | 25 | B | M | Reserved for future use; blank. | ### 90 Cash Letter Control Record Closes a cash letter with its bundle, item and image counts, total amount, ECE institution name and settlement date. 80 bytes. Defined in DSTU X9.37-2003, X9.100-187-2008/2013/2016. **X9.100-187 (2008 to 2016 editions): 80 bytes** | Position | Field | Length | Type | Usage | Description | | --- | --- | --- | --- | --- | --- | | 1–2 | Record Type | 2 | N | M | Always "90". | | 3–8 | Bundle Count | 6 | N | M | Number of bundles in the cash letter. | | 9–16 | Items Within Cash Letter Count | 8 | N | M | Number of Check Detail (25) or Return (31) records in the cash letter. | | 17–30 | Cash Letter Total Amount | 14 | N | M | Sum of the item amounts in the cash letter, in cents. | | 31–39 | Images Within Cash Letter Count | 9 | N | M | Number of Image View Detail (50) records in the cash letter. | | 40–57 | ECE Institution Name | 18 | ANS | C | Name of the institution that created the cash letter. | | 58–65 | Settlement Date | 8 | N | C | Date the cash letter settles (YYYYMMDD). | | 66 | Credit Total Indicator | 1 | N | C | Whether credit records (61/62) are included in the totals. Added in X9.100-187-2008; Reserved in DSTU X9.37-2003. | | 67–80 | Reserved | 14 | B | M | Reserved for future use; blank. | **DSTU X9.37-2003: the fields that differ from X9.100-187 (2008 to 2016 editions)** | Position | Field | Length | Type | Usage | Description | | --- | --- | --- | --- | --- | --- | | 66–80 | Reserved | 15 | B | M | Reserved for future use; blank. | ### 99 File Control Record Closes the file with its cash letter, record and item counts and the file total amount. 80 bytes. Defined in DSTU X9.37-2003, X9.100-187-2008/2013/2016. **X9.100-187 (2008 to 2016 editions): 80 bytes** | Position | Field | Length | Type | Usage | Description | | --- | --- | --- | --- | --- | --- | | 1–2 | Record Type | 2 | N | M | Always "99". | | 3–8 | Cash Letter Count | 6 | N | M | Number of cash letters in the file. | | 9–16 | Total Record Count | 8 | N | M | Number of records of every type in the file, including the File Header and File Control. | | 17–24 | Total Item Count | 8 | N | M | Number of Check Detail (25) and Return (31) records in the file. | | 25–40 | File Total Amount | 16 | N | M | Sum of the item amounts in the file, in cents. | | 41–54 | Immediate Origin Contact Name | 14 | ANS | C | Contact at the institution that sent the file. | | 55–64 | Immediate Origin Contact Phone Number | 10 | N | C | Phone number of the contact. | | 65 | Credit Total Indicator | 1 | N | C | Whether credit records (61/62) are included in the totals. Added in X9.100-187-2008; Reserved in DSTU X9.37-2003. | | 66–80 | Reserved | 15 | B | M | Reserved for future use; blank. | **DSTU X9.37-2003: the fields that differ from X9.100-187 (2008 to 2016 editions)** | Position | Field | Length | Type | Usage | Description | | --- | --- | --- | --- | --- | --- | | 65–80 | Reserved | 16 | B | M | Reserved for future use; blank. | ## Code tables The values of the main coded fields, as the X9 Viewer decodes them. These tables were checked against the Federal Reserve’s DSTU X9.37-2003 documentation and other public sources; coded fields without a table here take values your exchange partner’s specification lists. ### Standard Level Used in 01 field 2. | Code | Meaning | | --- | --- | | 03 | DSTU X9.37-2003 | | 30 | X9.100-187-2008 | | 35 | X9.100-187-2013 or later | ### Collection Type Indicator Used in 10 field 2, 20 field 2. | Code | Meaning | | --- | --- | | 00 | Preliminary forward information | | 01 | Forward presentment | | 02 | Forward presentment, same-day settlement | | 03 | Return | | 04 | Return notification | | 05 | Preliminary return notification | | 06 | Final return notification | | 20 | No detail | | 99 | Bundles not the same collection type | ### Cash Letter Record Type Indicator Used in 10 field 8. | Code | Meaning | | --- | --- | | N | No electronic check records or image records | | E | Electronic check records, no image records | | I | Electronic check records and image records | | F | Image records for a previously sent electronic (E) cash letter | ### Documentation Type Indicator Used in 10 field 9, 25 field 9, 31 field 8, 61 field 8, 61 field 9, 62 field 8. | Code | Meaning | | --- | --- | | A | No image provided, paper provided separately | | B | No image provided, paper provided separately, image upon request | | C | Image provided separately, no paper provided | | D | Image provided separately, no paper provided, image upon request | | E | Image and paper provided separately | | F | Image and paper provided separately, image upon request | | G | Image included, no paper provided | | H | Image included, no paper provided, image upon request | | I | Image included, paper provided separately | | J | Image included, paper provided separately, image upon request | | K | No image provided, no paper provided | | L | No image provided, no paper provided, image upon request | | M | No image provided, electronic check provided separately | | Z | Not the same type (see each item) | ### MICR Valid Indicator Used in 25 field 11. | Code | Meaning | | --- | --- | | 1 | Good read | | 2 | Good read, missing field | | 3 | Read error encountered | | 4 | Missing field and read error encountered | ### BOFD Indicator Used in 25 field 12. | Code | Meaning | | --- | --- | | Y | ECE institution is the BOFD | | N | ECE institution is not the BOFD | | U | Unknown | ### Correction Indicator Used in 25 field 14, 26 field 11, 28 field 8, 32 field 11, 35 field 8. | Code | Meaning | | --- | --- | | 0 | No repair | | 1 | Repaired (form of repair unknown) | | 2 | Repaired without operator intervention | | 3 | Repaired with operator intervention | | 4 | Undetermined whether repaired | The BOFD Correction Indicator of a Return Addendum A (32) may also be `5` (BOFD routing number repaired by the Federal Reserve). ### Archive Type Indicator Used in 25 field 15, 31 field 13. | Code | Meaning | | --- | --- | | A | Microfilm | | B | Image | | C | Paper | | D | Microfilm and image | | E | Microfilm and paper | | F | Image and paper | | G | Microfilm, image and paper | | H | Electronic check instrument | | I | None | ### Conversion Indicator Used in 26 field 10, 28 field 7, 32 field 10, 35 field 7. | Code | Meaning | | --- | --- | | 0 | Did not convert physical document | | 1 | Original paper converted to IRD | | 2 | Original paper converted to image | | 3 | IRD converted to another IRD | | 4 | IRD converted to image of IRD | | 5 | Image converted to an IRD | | 6 | Image converted to another image (e.g. transcoded) | | 7 | Did not convert image (same as source) | | 8 | Undetermined | ### Return Reason Used in 28 field 9, 31 field 6, 35 field 9. Meanings as listed in X9.100-187-2008. From the 2016 edition on, return reasons are defined in ANSI X9.100-188 (current edition 2023), which separates customer and administrative reasons and may list other codes; check them against your exchange partner’s list. The current edition of X9.100-188 is a free download from [ANSI](https://webstore.ansi.org/standards/ascx9/ansix91001882023). | Code | Meaning | | --- | --- | | A | NSF: not sufficient funds | | B | UCF: uncollected funds hold | | C | Stop payment | | D | Closed account | | E | UTLA: unable to locate account | | F | Frozen / blocked account | | G | Stale dated | | H | Post dated | | I | Endorsement missing | | J | Endorsement irregular | | K | Signature(s) missing | | L | Signature(s) irregular, suspected forgery | | M | Non-cash item (non-negotiable) | | N | Altered / fictitious item, suspected counterfeit | | O | Unable to process (e.g. mutilated item) | | P | Item exceeds stated maximum value | | Q | Not authorized | | R | Branch / account sold (wrong bank) | | S | Refer to maker | | T | Item cannot be re-presented | | U | Unusable image | | V | Image fails security check | | W | Cannot determine amount | | X | Refer to image | | Y | Duplicate presentment | | Z | Forgery | | 1 | Warranty breach | | 2 | RCC warranty breach | | 3 | Forged and counterfeit warranty breach | | 4 | Retired / ineligible routing number | In DSTU X9.37-2003 files, `T` is “Stop payment suspect” rather than “Item cannot be re-presented”. ### Image Indicator Used in 50 field 2. | Code | Meaning | | --- | --- | | 0 | Image view not present | | 1 | Image view present, actual check | | 2 | Image view present, not an actual check (e.g. IRD or carrier document) | | 3 | Image view present, cannot determine whether it is an actual check | ### Image View Format Indicator Used in 50 field 5. | Code | Meaning | | --- | --- | | 00 | TIFF 6 | | 01 | IOCA FS 11 | | 20 | PNG | | 21 | JFIF (JPEG) | | 22 | SPIFF | | 23 | JBIG data stream | | 24 | JPEG 2000 | ### Image View Compression Algorithm Identifier Used in 50 field 6. | Code | Meaning | | --- | --- | | 00 | Group 4 facsimile (CCITT T.6) | | 01 | JPEG baseline | | 02 | ABIC | | 21 | PNG | | 22 | JBIG | | 23 | JPEG 2000 | ### Digital Signature Method Used in 50 field 11. | Code | Meaning | | --- | --- | | 00 | DSA with SHA-1 | | 01 | RSA with MD5 | | 02 | RSA with MDC2 | | 03 | RSA with SHA-1 | | 04 | ECDSA with SHA-1 | ### Global Image Quality Used in 54 field 2. | Code | Meaning | | --- | --- | | 0 | Not tested for image quality conditions | | 1 | Tested; one or more image quality conditions reported | | 2 | Tested; no image quality conditions reported | ### Global Image Usability Used in 54 field 3. | Code | Meaning | | --- | --- | | 0 | Not tested for image usability conditions | | 1 | Tested; one or more image usability conditions reported | | 2 | Tested; no image usability conditions reported | ### Imaging Bank Specific Test Used in 54 field 4. | Code | Meaning | | --- | --- | | 0 | No user-defined tests | | 1 | Other conditions tested; one or more reported in the User Field | | 2 | Other conditions tested; none reported in the User Field | ### Image quality tests Used in 54 field 5, 54 field 6, 54 field 7, 54 field 8, 54 field 9, 54 field 10, 54 field 11. | Code | Meaning | | --- | --- | | 0 | Condition not tested | | 1 | Condition present | | 2 | Condition not present | ### Image usability tests Used in 54 field 27, 54 field 28, 54 field 29, 54 field 30, 54 field 31, 54 field 32, 54 field 33, 54 field 34, 54 field 35, 54 field 36, 54 field 37, 54 field 38. | Code | Meaning | | --- | --- | | 0 | Not tested | | 1 | Unusable | | 2 | Usable | ### Image-Enabled POD Used in 54 field 25. | Code | Meaning | | --- | --- | | 0 | Unknown whether the image was used for image-enabled POD | | 1 | Image not used for image-enabled POD | | 2 | Image used for image-enabled POD | ### Source Document Bad Used in 54 field 26. | Code | Meaning | | --- | --- | | 0 | Not tested | | 1 | Image unusable; source document unusable | | 2 | Image unusable; source document may be usable | ## Validation checks The 64 checks the X9 Viewer runs, with the code it shows for each: E for an error, W for a warning and I for information, then the check’s number. An error breaks a rule of the format, such as a total that does not match; a warning points to something a receiver may reject or that looks wrong, though the file still reads; info is worth knowing. Some checks are reported at more than one severity, depending on the field. ### Framing Whether the bytes split into records at all (codes 1 to 6). 1. #### Empty file Error `E001` The file has no bytes. 2. #### Not an X9 file Error `E002` The file does not start with an X9 File Header (type 01) in EBCDIC or ASCII, with or without length prefixes. The message says so when the file looks like a NACHA or BAI2 file, a PDF, an image or a ZIP archive. X9 files start with a File Header (type 01), optionally after a 4-byte length. 3. #### File truncated Error `E003` The last record needs more bytes than the file has left: the file was cut short, often in transfer. The file was cut short in transfer; request it again. 4. #### Unreadable bytes Error `E004` A length prefix or record type cannot be read. When a valid record turns up further on, reading resumes there; otherwise the rest of the file is not read. A length prefix or record type is corrupt. 5. #### Bytes between records Error `E005` Bytes between two records do not form a record and were skipped, such as block descriptors or damaged data. Block descriptors or corruption between records. 6. #### Padding after the last record Info `I006` Filler follows the last record: zeros, blanks, line breaks or an end-of-file byte. ### Record order and records Whether every record sits where it belongs in the file, cash letter, bundle and item, and has the right length (codes 101 to 131). 1. #### File Header not first Error `E101` The File Header (01) is not the first record. 2. #### Second File Header Error `E102` A second File Header (01) appears in the file. Two files may have been concatenated. 3. #### No File Header Error `E103` The file has no File Header (01). 4. #### No File Control Error `E104` The file has no File Control (99). The file may be truncated. 5. #### Second File Control Error `E105` A second File Control (99) appears in the file. 6. #### Records after File Control Error `E106` Records follow the File Control (99). Two files may have been concatenated. 7. #### Cash letter not closed Error `E107` A cash letter has no Cash Letter Control (90) before the next Cash Letter Header, the File Control or the end of the file. Each Cash Letter Header (10) needs a Cash Letter Control (90). 8. #### Bundle not closed Error `E108` A bundle has no Bundle Control (70) before the next bundle, the cash letter’s control or the end of the file. Each Bundle Header (20) needs a Bundle Control (70). 9. #### Bundle outside a cash letter Error `E109` A Bundle Header (20) is not inside a cash letter. 10. #### Item outside a bundle Error `E110` A Check Detail (25) or Return (31) is not inside a bundle. 11. #### Addendum without an item Error `E111` An addendum record has no check or return before it. 12. #### Wrong addendum type Error `E112` An addendum of the wrong family: a check (25) takes addenda 26, 27 and 28; a return (31) takes 32, 33, 34 and 35. Checks take addenda 26/27/28; returns take 32/33/34/35. 13. #### Addendum after image records Warning `W113` An addendum comes after the item’s image records. Addenda come first, then the image views. 14. #### Image view without an item Error `E114` An Image View Detail (50) has no check, return or credit record before it. 15. #### Image View Data missing Error `E115` An Image View Detail (50) is not followed by its Image View Data (52). Every Image View Detail (50) is followed by an Image View Data (52). 16. #### Image View Data without detail Error `E116` An Image View Data (52) has no Image View Detail (50) of its own before it. 17. #### Image View Analysis out of place Warning `W117` An Image View Analysis (54) does not follow an Image View Data (52), or a view already has one. 18. #### Credit outside a cash letter Error `E118` A credit record (61 or 62) is not inside a cash letter. 19. #### Bundle Control without header Error `E119` A Bundle Control (70) has no open bundle to close. 20. #### Cash Letter Control without header Error `E120` A Cash Letter Control (90) has no open cash letter to close. 21. #### Summary record outside a cash letter Error `E121` A summary record (40, 41, 75 or 85) is not inside a cash letter. 22. #### Summary record inside a bundle Error `E122` A summary record (40, 41, 75 or 85) sits inside a bundle; it belongs after the Bundle Control (70). 23. #### Unknown record type Warning `W130` A record type that neither X9.100-187 nor DSTU X9.37-2003 defines. The record is kept as it is. 24. #### Wrong record length Error Warning `E131 / W131` A record is not the length its type calls for: 80 bytes for most types, 100 for type 62, and what their own length fields say for 27, 34 and 68. It is a warning when the file has one record per line and the record is short, as when an export trims trailing blanks. Fixed records are 80 bytes (type 62: 100); variable records follow their length fields. ### Totals and counts The controls compared with what the file holds (codes 201 to 215). Credit records (61 and 62) count toward item counts and amounts when the Credit Total Indicator is 1, not when it is 0; with a blank indicator or in a DSTU file, either reading is accepted. 1. #### Bundle item count Error `E201` The Items Within Bundle Count (70) is not the number of checks or returns in the bundle. Items Within Bundle Count (70) counts the 25/31 records of the bundle. 2. #### Bundle total amount Error `E202` The Bundle Total Amount (70) is not the sum of the bundle’s item amounts. Bundle Total Amount (70) is the sum of the item amounts in the bundle. 3. #### MICR valid total Warning `W203` The MICR Valid Total Amount (70) is not the sum of the amounts of the checks whose MICR Valid Indicator is 1. MICR Valid Total Amount (70) sums the checks whose MICR Valid Indicator is 1. 4. #### Bundle image count Error `E204` The Images Within Bundle Count (70) is not the number of Image View Detail (50) records in the bundle. Images Within Bundle Count (70) counts the Image View Detail (50) records. 5. #### Cash letter bundle count Error `E205` The Bundle Count (90) is not the number of bundles in the cash letter. 6. #### Cash letter item count Error `E206` The Items Within Cash Letter Count (90) is not the number of checks or returns in the cash letter. 7. #### Cash letter total amount Error `E207` The Cash Letter Total Amount (90) is not the sum of the item amounts in the cash letter. 8. #### Cash letter image count Error `E208` The Images Within Cash Letter Count (90) is not the number of Image View Detail (50) records in the cash letter. 9. #### File cash letter count Error `E209` The Cash Letter Count (99) is not the number of cash letters in the file. 10. #### File record count Error `E210` The Total Record Count (99) is not the number of records in the file, File Header and File Control included. Total Record Count (99) includes the File Header and File Control. 11. #### File item count Error `E211` The Total Item Count (99) is not the number of checks and returns in the file. 12. #### File total amount Error `E212` The File Total Amount (99) is not the sum of the item amounts in the file. 13. #### Addendum count Error `E213` The addendum count of a check (25) or return (31) is not the number of addendum records that follow it. The 25/31 record states how many addenda follow it. 14. #### Addendum record numbers Warning `W214` The record numbers of an item’s addenda (26, 28, 32 or 35) do not run 1, 2, 3 in order within their type. 15. #### Routing number summary Warning `W215` A Routing Number Summary (85) does not match the count or total amount of the cash letter’s items for that routing number. ### Image records The Image View Detail and Image View Data records and the image bytes (codes 301 to 310). 1. #### Unreadable image length field Error `E301` A length field of an Image View Data (52) record is not a number, so its image cannot be located. 2. #### Image data truncated Error `E302` The Length of Image Data in a 52 promises more bytes than the record holds. Length of Image Data says more bytes than the record holds. 3. #### Extra bytes after image data Warning `W303` Bytes follow the image data inside a 52 record. 4. #### Image size differs from Image View Detail Warning `W304` The Image View Data Size in a 50 differs from the Length of Image Data in its 52. 5. #### Image Indicator says no image Warning `W305` A 50 says no image view is present (Image Indicator 0), yet its 52 carries image data. 6. #### Image view without image data Warning `W306` A 50 says an image view is present, yet its 52 carries no image data. 7. #### Image format differs from its indicator Warning `W307` The image bytes are in another format than the one the 50’s Image View Format Indicator names. 8. #### Unrecognised image format Warning `W308` The image data is not TIFF, JPEG, PNG, GIF or JPEG 2000. 9. #### Item without images Warning `W309` An item has no image views although its cash letter says it carries images (Cash Letter Record Type Indicator I or F). The cash letter says it carries images (Record Type Indicator I or F). 10. #### Front or back image missing Warning `W310` An item has image views, but no front or no back. ### Fields and other checks Field values in every record, plus the notes on MICR reads, test files and long issue lists (codes 401 to 501, and 900). 1. #### Mandatory field blank Error `E401` A mandatory field is blank. The viewer checks a set of the standard’s mandatory fields: routing numbers, dates, amounts, counts and the main indicators. 2. #### Non-numeric value in a numeric field Error Warning `E402 / W402` An amount, count, length or phone number holds something other than digits: an error in a field the viewer requires, a warning in others. 3. #### Invalid date Error Warning `E403 / W403` A date is not a real YYYYMMDD date: an error in a field the viewer requires, a warning in others. Dates are YYYYMMDD. 4. #### Invalid time Error Warning `E404 / W404` A time is not a valid hhmm time on a 24-hour clock: an error in a field the viewer requires, a warning in others. Times are hhmm on a 24-hour clock. 5. #### Invalid routing number Error Warning `E405 / W405` A routing number fails the ABA check digit or is not nine digits, an error in a required field (every payor bank routing number is one) and a warning elsewhere; or it holds unreadable MICR characters (\*) or starts with a prefix outside the Federal Reserve’s ranges, a warning. ABA check digit: 3·d1 + 7·d2 + d3 + 3·d4 + 7·d5 + d6 + 3·d7 + 7·d8 + d9 is a multiple of 10. 6. #### Value not in the code list Warning `W406` A coded field holds a value outside its list. Fields whose lists are open, such as return reasons from the 2008 edition on, are not checked this way. 7. #### MICR read problem reported Info `I407` A check’s MICR Valid Indicator reports a read problem: 2 (good read, missing field), 3 (read error) or 4 (both). 8. #### Test file Info `I501` The File Header marks the file as a test file (Test File Indicator T). 9. #### More issues not listed Info `I900` A rule found more than 1,000 issues of one severity. The first 1,000 are listed and the rest counted. ## Sources The layouts follow ANSI X9.100-187 (positions as the 2016 edition prints them) and the Federal Reserve’s documentation of DSTU X9.37-2003, and were checked against bank image cash letter specifications. ASC X9 publishes the standards through ANSI; the descriptions on this page are our own. Exchange partners agree on the details in their own specifications, so check the one that applies to your files. NACHA Navigator is independent and not affiliated with ASC X9, ANSI or the Federal Reserve. This page is for information only and is not legal or compliance advice. [X9.100-187-2021 at ANSI](https://webstore.ansi.org/standards/ascx9/ansix91001872021) [Federal Reserve DSTU guide (PDF)](https://www.frbservices.org/binaries/content/assets/crsocms/financial-services/check/setup/frb-x937-standards-reference.pdf) [Sample files](https://nacha-navigator.com/sample-files) --- URL: https://nacha-navigator.com/sample-files # Sample payment files Reference 10 sample files to download or open in the free viewers: NACHA (ACH) files, BAI2 bank reports and an X9.37 image cash letter. Names, account numbers and amounts in them are made up. Last updated October 30, 2026 ## NACHA (ACH) files Plain text, one 94-character record per line, for the [NACHA Viewer](https://nacha-navigator.com/). Every file but the validation demo passes every check. - NACHA sample-ppd.ach 1.9 KB ### PPD payroll (classic sample) The original NACHA Navigator sample — MY COMPANY USA prenoting its payroll accounts in two PPD batches, plus one $0.10 credit — corrected so that it passes every check. - Prenotes to checking (23) and savings (33), and a live checking credit (22) - Two PPD batches with balanced controls - Block fill to 20 records [Download sample-ppd.ach](https://nacha-navigator.com/samples/nacha/sample-ppd.ach) [Open in the NACHA Viewer (sample-ppd.ach)](https://nacha-navigator.com/?sample=ppd) - NACHA sample-ccd-addenda.ach 1.9 KB ### CCD vendor payments with remittance addenda A credits-only CCD batch paying vendors with one type 05 addenda each, and a debits-only CCD batch collecting invoices. - Service Class Codes 220 and 225 - Type 05 addenda with X12 RMR segments and plain text - A zero-dollar remittance entry (Transaction Code 24) [Download sample-ccd-addenda.ach](https://nacha-navigator.com/samples/nacha/sample-ccd-addenda.ach) [Open in the NACHA Viewer (sample-ccd-addenda.ach)](https://nacha-navigator.com/?sample=ccd-addenda) - NACHA sample-ctx.ach 1.9 KB ### CTX payments with EDI 820 remittance Two CTX payments whose ANSI X12 820 remittance advice spans several type 05 addenda records. - Number of Addenda Records (positions 55–58) - Addenda sequence numbers 0001–0004 - Receiving Company Name/ID Number layout [Download sample-ctx.ach](https://nacha-navigator.com/samples/nacha/sample-ctx.ach) [Open in the NACHA Viewer (sample-ctx.ach)](https://nacha-navigator.com/?sample=ctx) - NACHA sample-returns-noc.ach 2.8 KB ### Returns and Notifications of Change A file sent back by an RDFI: a PPD batch of returns (R01, R02, R03, R10, R15) and a COR batch of NOCs (C01, C02, C05). - Return Transaction Codes 21, 26 and 36 with type 99 addenda - Date of death on an R15 return - Type 98 addenda with corrected account, routing number and transaction code [Download sample-returns-noc.ach](https://nacha-navigator.com/samples/nacha/sample-returns-noc.ach) [Open in the NACHA Viewer (sample-returns-noc.ach)](https://nacha-navigator.com/?sample=returns-noc) - NACHA sample-with-errors.ach 1.1 KB ### Validation demo (deliberate errors) A small payroll file damaged on purpose so the validator has something to find. Every problem is listed below. - Control totals that do not add up - Routing, trace and addenda problems - A record with its trailing blanks stripped The 12 problems in it, on purpose: - Line 3: Routing number 065503349 fails the check-digit test (its first eight digits imply 8, not 9) [ED_RDFI_CHECK_DIGIT](https://nacha-navigator.com/nacha-file-errors#ed-rdfi-check-digit) - Line 4: Prenote (Transaction Code 23) for $10.00; prenotes must be zero [ED_PRENOTE_AMOUNT](https://nacha-navigator.com/nacha-file-errors#ed-prenote-amount) - Line 5: Trace number …0000002 follows …0000003 [ED_TRACE_ORDER](https://nacha-navigator.com/nacha-file-errors#ed-trace-order) - Line 6: Addenda Record Indicator 1, but no addenda record follows [ED_ADDENDA_INDICATOR](https://nacha-navigator.com/nacha-file-errors#ed-addenda-indicator) - Line 7: Entry Hash 0099999999; the RDFI numbers add up to 0066196257 [BC_ENTRY_HASH](https://nacha-navigator.com/nacha-file-errors#bc-entry-hash) - Line 7: Total credit $9,999.99; the credits add up to $4,340.00 [BC_TOTAL_CREDIT](https://nacha-navigator.com/nacha-file-errors#bc-total-credit) - Line 8: Effective Entry Date 261131 (November 31) [INVALID_DATE](https://nacha-navigator.com/nacha-file-errors#invalid-date) - Line 9: A debit (Transaction Code 27) in a credits-only batch (Service Class Code 220) [ED_SERVICE_CLASS_MISMATCH](https://nacha-navigator.com/nacha-file-errors#ed-service-class-mismatch) - Line 11: Batch Control Company Identification differs from the Batch Header [BC_COMPANY_ID](https://nacha-navigator.com/nacha-file-errors#bc-company-id) - Line 12: Batch Count 1; the file has 2 batches [FC_BATCH_COUNT](https://nacha-navigator.com/nacha-file-errors#fc-batch-count) - Line 12: File Control Record is 55 characters: its trailing blanks were stripped [RECORD_LENGTH](https://nacha-navigator.com/nacha-file-errors#record-length) - Line 12: 12 records and no block fill (warning) [BLOCK_FILL_MISSING](https://nacha-navigator.com/nacha-file-errors#block-fill-missing) [Download sample-with-errors.ach](https://nacha-navigator.com/samples/nacha/sample-with-errors.ach) [Open in the NACHA Viewer (sample-with-errors.ach)](https://nacha-navigator.com/?sample=with-errors) - NACHA sample-reversal-demo.ach 1.9 KB ### Reversal demo (payroll, memberships, vendor payment) The file behind the reversal demo, as generated for October 27, 2026: a payroll batch, a batch of membership debits and a vendor payment with a remittance addenda. - Credits and debits across three batches - A prenote that can’t be reversed - A CCD payment with a remittance addenda The demo link builds the same file in your browser for today’s date, so its five-banking-day reversal window is always open; the dates in this download stay as they were generated. [Download sample-reversal-demo.ach](https://nacha-navigator.com/samples/nacha/sample-reversal-demo.ach) [Open the reversal demo (sample-reversal-demo.ach)](https://nacha-navigator.com/?sample=reversal-demo#reverse) ### A NACHA file, line by line The first batch of [sample-ppd.ach](https://nacha-navigator.com/samples/nacha/sample-ppd.ach), its File Control and the first block-fill line. The [NACHA file format](https://nacha-navigator.com/nacha-file-format) reference lays out every field. | Line | Record | What it says | | --- | --- | --- | | 1 | `101 065503681 0655036811202170910A094101HANCOCK BANK MY COMPANY USA ` | File Header: from MY COMPANY USA to HANCOCK BANK, routing number 065503681, created February 17, 2012 at 09:10, File ID Modifier A. | | 2 | `5200MY COMPANY USA 9123456789PPDPAYROLL 120220120221 1065503680000001` | Company/Batch Header: Service Class 200, company ID 9123456789, SEC code PPD, description PAYROLL, effective February 21, 2012, batch 1. | | 3 | `6220655033481111111 0000000010000001309 JOHN M SMITH 0065503680000001` | Entry Detail: Transaction Code 22, a checking credit of $0.10 to routing number 065503348, account 1111111, JOHN M SMITH. | | 4 | `63326557758511122333 0000000000000001309 JOHN M SMITH 0065503680000002` | Entry Detail: Transaction Code 33, a prenote to a savings account: $0.00, checking the account before live payments. | | 5 | `6230655033481234567899 0000000000000001309 JOHN M SMITH 0065503680000003` | Entry Detail: Transaction Code 23, a prenote to a checking account. | | 6 | `623065503681111222111 0000000000000001309 JOHN M SMITH 0065503680000004` | Entry Detail: another checking prenote, trace number 065503680000004. | | 7 | `820000000400462087940000000000000000000000109123456789 065503680000001` | Company/Batch Control: 4 entries and addenda, Entry Hash 0046208794, debits $0.00, credits $0.10. | | 14 | `9000002000002000000080137163116000000000000000000000010 ` | File Control, after the second batch (lines 8–13): 2 batches, 2 blocks, 8 entries and addenda, Entry Hash 0137163116. | | 15 | `9999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999` | Block fill: lines 15–20 are 94 nines each, padding the file to 20 lines, two blocks of 10. | ## BAI2 files Bank balance and transaction reports for the [BAI2 Viewer](https://nacha-navigator.com/bai2-viewer): comma-separated records, each ending in a slash or continued on an 88 record. - BAI2 sample-multi-account.bai 1.8 KB ### Prior-day and same-day report, 5 accounts Two groups (final prior-day and interim same-day), five accounts in USD, EUR and JPY, balances and summaries continued on 88 records, funds types S, V, D and Z, a non-monetary 890 record, and long text with commas and slashes continued on 88 records. Every control total and record count is correct. [Download sample-multi-account.bai](https://nacha-navigator.com/samples/bai2/sample-multi-account.bai) [Open in the BAI2 Viewer (sample-multi-account.bai)](https://nacha-navigator.com/bai2-viewer?sample=multi-account) - BAI2 sample-simple.bai 346 bytes ### One account, two transactions The smallest useful report: one group, one account with opening and closing ledger balances, a check deposit and an ACH withdrawal whose text continues on two 88 records. [Download sample-simple.bai](https://nacha-navigator.com/samples/bai2/sample-simple.bai) [Open in the BAI2 Viewer (sample-simple.bai)](https://nacha-navigator.com/bai2-viewer?sample=simple) - BAI2 sample-with-errors.bai 591 bytes ### Report with deliberate errors Three accounts with fifteen problems placed on purpose to show what the validator reports. The 15 problems in it, on purpose: - Line 1: File Creation Time 2575 is not a valid time. - Line 2: As-of-Date Modifier 5 is not one of 1–4. - Line 4: Funds Type X is not a BAI2 funds type. - Line 5: A transaction amount is negative (16 amounts are unsigned). - Line 6: Status code 015 (Closing Ledger) is used as a transaction. - Line 7: The amount 1250.00 has a decimal point (BAI2 amounts use implied decimals). - Line 8: The Account Control Total does not match the account’s amounts. - Line 9: Currency code US is not an ISO 4217 code. - Line 10: Value date 261332 has month 13. - Line 11: Type code 850 is not in the BAI2 list (information only). - Line 12: A blank line (information only). - Line 13: The account that starts on line 9 has no Account Trailer (49). - Line 16: 88 used as the Group Trailer instead of 98 (read as a 98, with a "Did you mean 98?" warning). - Line 16: The group trailer says 2 accounts; the group has 3. - Line 17: The File Trailer says 99 records; the file has 16. [Download sample-with-errors.bai](https://nacha-navigator.com/samples/bai2/sample-with-errors.bai) [Open in the BAI2 Viewer (sample-with-errors.bai)](https://nacha-navigator.com/bai2-viewer?sample=with-errors) ### A BAI2 file, line by line All of [sample-simple.bai](https://nacha-navigator.com/samples/bai2/sample-simple.bai). Amounts have no decimal point: 250000 is $2,500.00 in a USD account. The [BAI2 file format](https://nacha-navigator.com/bai2-file-format) reference covers every record. | Line | Record | What it says | | --- | --- | --- | | 1 | `01,123456789,987654321,250407,1200,1,,,2/` | File Header: sender 123456789, receiver 987654321, created April 7, 2025 at 12:00, file 1, version 2. | | 2 | `02,987654321,123456789,1,250407,1200,USD,2/` | Group Header: status 1 (update), as of April 7, 2025 at 12:00, in USD, modifier 2 (final previous-day data). | | 3 | `03,1234567890,USD,010,1000000,,,015,1100000,,/` | Account Identifier: account 1234567890, opening ledger (type 010) $10,000.00, closing ledger (type 015) $11,000.00. | | 4 | `16,175,250000,0,CHKDEP001,12345,CHECK DEPOSIT, VENDOR PAYMENT 12345` | Transaction Detail: check deposit package (type 175), $2,500.00, available immediately (funds type 0), bank reference CHKDEP001. The text runs to the end of the line, commas included. | | 5 | `16,451,150000,0,ACH0001,PAYROLL,ACH WITHDRAWAL` | Transaction Detail: ACH debit received (type 451), $1,500.00. | | 6 | `88,PAYROLL PROCESSING` | Continuation: more text for the transaction on line 5. | | 7 | `88,TRANSACTION DETAIL LINE 2` | Continuation: a second line of text. | | 8 | `49,2500000,6/` | Account Trailer: control total 2500000 (the account’s amounts added up) and 6 records, lines 3–8. | | 9 | `98,2500000,1,8/` | Group Trailer: control total, 1 account, 8 records (lines 2–9). | | 10 | `99,2500000,1,10/` | File Trailer: control total, 1 group, 10 records in all. | ## X9.37 file An image cash letter for the [X9 Viewer](https://nacha-navigator.com/x9-viewer): binary records with the check images inside, so a text editor can’t show it. - X9.37 sample-cash-letter.x9 54.3 KB ### Image cash letter with six checks One cash letter of 2 bundles holding 6 checks for $5,216.50 in all, with the front and back image of every check. Business date October 26, 2026. - EBCDIC records with 4-byte length prefixes, Standard Level 35 (X9.100-187-2013 or later) - 12 image views: TIFF, CCITT Group 4, black and white - A Check Detail Addendum A (26) on every check and one Addendum C (28) - Marked as a test file (Test File Indicator T), which the viewer notes The X9 Viewer has no link that opens this file directly: open the viewer and use its sample button. [Download sample-cash-letter.x9](https://nacha-navigator.com/samples/x9/sample-cash-letter.x9) [Open the X9 Viewer (sample-cash-letter.x9)](https://nacha-navigator.com/x9-viewer) ### What the X9.37 file holds The records of [sample-cash-letter.x9](https://nacha-navigator.com/samples/x9/sample-cash-letter.x9), by type. Each check is a Check Detail (25) with its addenda, followed by an Image View Detail (50) and Image View Data (52) for the front and for the back. The [X9.37 file format](https://nacha-navigator.com/x9-file-format) reference describes each record type. | Type | Record | Count | | --- | --- | --- | | 01 | File Header | 1 | | 10 | Cash Letter Header | 1 | | 20 | Bundle Header | 2 | | 25 | Check Detail | 6 | | 26 | Check Detail Addendum A | 6 | | 28 | Check Detail Addendum C | 1 | | 50 | Image View Detail | 12 | | 52 | Image View Data | 12 | | 70 | Bundle Control | 2 | | 90 | Cash Letter Control | 1 | | 99 | File Control | 1 | ## Need a different file? The NACHA Generator builds a valid NACHA file from a form or from JSON, with the totals, entry hash and block fill worked out for you. Opening a sample or your own file uploads nothing: the viewers read files in your browser. [Open the NACHA Generator](https://nacha-navigator.com/nacha-generator) --- URL: https://nacha-navigator.com/use-cases # NACHA File Viewer & ACH Validation — Real-World Use Cases Use cases From payroll validation to reversal generation and compliance audits, here is how teams across banking, fintech, and finance use NACHA Navigator every day. Last updated October 30, 2026 100% in-browser processing — your file never leaves your device [Open the free NACHA file viewer](https://nacha-navigator.com/) No. 01 Payroll teams ## Payroll Teams: Validate ACH Payroll Files Before Submission ### The problem A payroll run that fails at the bank means employees do not get paid on time. Payroll teams often receive NACHA files from payroll software or third-party processors and have no easy way to verify them before submission. A single unbalanced batch, an invalid effective entry date, or a truncated record can cause the whole file to be rejected — sometimes discovered only after the submission window has closed. ### How NACHA Navigator helps Drop the payroll file into NACHA Navigator before you send it. The parser immediately shows every batch, entry, and control record with labeled fields, and the validator recomputes each batch and file total and the entry hash, flagging any that don’t match. You can confirm the effective entry date lands on the right pay date, verify the total debit and credit dollar amounts in the File Control record match your payroll register, and spot-check individual employee entries — account numbers, amounts, and individual names — without counting characters in a text editor. Key concepts [PPD entries](https://nacha-navigator.com/nacha-file-format#entry-ppd) [Effective entry date](https://nacha-navigator.com/nacha-file-format#batch-header-effective-entry-date) [Batch control totals](https://nacha-navigator.com/nacha-file-format#batch-control) [Entry hash](https://nacha-navigator.com/nacha-file-format#batch-control-entry-hash) No. 02 Banks & credit unions ## Banks & Credit Unions: Troubleshoot Rejected or Malformed NACHA Files ### The problem ACH operations staff at financial institutions regularly receive originated files that fail pre-processing edits: wrong record lengths, missing File Control records, invalid routing number check digits, or batches whose entry counts do not match their control records. The rejection notice usually cites a record position and an edit code — not much help when you are staring at thousands of 94-character lines. ### How NACHA Navigator helps NACHA Navigator turns the raw file into a color-coded, record-by-record breakdown. Each record type (1, 5, 6, 7, 8, 9) is labeled, and clicking any field shows its name, position, expected format, and purpose. Every failed check is listed with its line, columns and the value it expected, so it is fast to jump to the batch the edit report flagged, compare the Batch Control entry/addenda count against the actual entries, and verify the receiving DFI routing number check digit — all without exposing customer data to any external system. Key concepts [Record type codes](https://nacha-navigator.com/nacha-file-format#record-order) [Blocking factor and block count](https://nacha-navigator.com/nacha-file-format#file-control-block-count) [Entry hash](https://nacha-navigator.com/nacha-file-format#batch-control-entry-hash) [Trace numbers](https://nacha-navigator.com/nacha-file-format#entry-ppd-trace-number) [ABA check digit](https://nacha-navigator.com/nacha-file-format#entry-ppd-check-digit) No. 03 Treasury & finance ## Treasury & Finance: Audit Entry Details, Batch Totals, and Control Records ### The problem Treasury teams are accountable for every dollar that leaves the company through ACH origination. Reconciling a NACHA file against an AP run or a treasury workstation export means verifying that batch totals, entry counts, and company identification fields are exactly right — a tedious, error-prone process when done by hand. ### How NACHA Navigator helps With NACHA Navigator, an analyst can open the origination file and read the File Control record totals directly: total entry and addenda count, total debit dollars, total credit dollars. Batch Header records show the company name, company ID, and standard entry class for each batch, so it is easy to confirm the right originating entity and transaction type. Individual entries can be inspected for receiver names, amounts, and transaction codes (checking vs. savings, debit vs. credit). Key concepts [Transaction codes 22/27, 32/37](https://nacha-navigator.com/nacha-file-format#transaction-codes) [Company ID and batch number](https://nacha-navigator.com/nacha-file-format#batch-header-company-identification) [CCD vs. CTX entries](https://nacha-navigator.com/nacha-file-format#entry-detail-by-sec) [File vs. batch control totals](https://nacha-navigator.com/nacha-file-format#file-control) No. 04 Fintech developers ## Fintech Developers: Learn and Debug the NACHA File Format ### The problem If you are building ACH origination into a product, you have to produce byte-perfect NACHA files — and the specification is a fixed-width format where every field lives at an exact character position. Off-by-one padding errors, wrong justification (left vs. right), and missing filler characters are the classic bugs, and they are nearly invisible in a diff. ### How NACHA Navigator helps NACHA Navigator doubles as an interactive reference for the format. Load a known-good sample file (one is built in) and click through every field to see its exact position, length, and rules — then load your generated file next and compare. Because each field is individually selectable and labeled, you can pinpoint exactly which column your generator got wrong. It is a faster feedback loop than resubmitting to a bank sandbox. The [NACHA file format reference](https://nacha-navigator.com/nacha-file-format) lists every field of every record type, and the [NACHA Generator](https://nacha-navigator.com/nacha-generator) builds a valid file to compare against. Key concepts [94-character records](https://nacha-navigator.com/nacha-file-format#record-order) [Justification and padding](https://nacha-navigator.com/nacha-file-format#field-rules) [Addenda records and indicator](https://nacha-navigator.com/nacha-file-format#entry-ppd-addenda-record-indicator) [Trace number construction](https://nacha-navigator.com/nacha-file-format#entry-ppd-trace-number) [SEC codes](https://nacha-navigator.com/nacha-file-format#sec-codes) No. 05 Operations teams ## Operations Teams: Generate ACH Reversal Files for Erroneous Entries ### The problem Duplicate payment runs, wrong amounts, and payments to the wrong account happen. Nacha rules allow originators to reverse erroneous entries, but only within five banking days of settlement, and the reversing file must be formatted precisely: opposite transaction codes, full original amounts, and “REVERSAL” in the company entry description. Building that file by hand under time pressure is risky. ### How NACHA Navigator helps NACHA Navigator generates the reversal for you. Load the original file, select the entries that need reversing, choose the reason, and the tool produces a correctly balanced NACHA reversal file — transaction codes flipped, control totals recalculated, description set — ready to download and submit to your bank within the reversal window. [Try it on the demo file](https://nacha-navigator.com/?sample=reversal-demo#reverse). Key concepts Five-banking-day window Permissible reasons: duplicate, wrong Receiver, wrong amount, wrong date [Flipped transaction codes](https://nacha-navigator.com/nacha-file-format#transaction-codes)[“REVERSAL” entry description](https://nacha-navigator.com/nacha-file-format#batch-header-company-entry-description) No. 06 Compliance & audit ## Compliance & Audit: Review ACH Origination Files ### The problem Auditors and compliance officers reviewing ACH origination need to verify that files match approved payment instructions, that company identification fields are correct, and that no unauthorized entries slipped into a batch. Requesting screenshots from operations or opening raw files in a text editor makes evidence-gathering slow, and uploading sensitive files to third-party web tools may violate data-handling policy. ### How NACHA Navigator helps Because NACHA Navigator runs entirely in the browser, compliance teams can inspect origination files on their own machines without any data leaving the device — consistent with strict data-handling requirements. The structured view makes it straightforward to document batch composition, originating company IDs, effective dates, and dollar totals for workpapers, and to trace any individual entry by its trace number. Key concepts [Company ID and name](https://nacha-navigator.com/nacha-file-format#batch-header-company-name) [Immediate origin and destination](https://nacha-navigator.com/nacha-file-format#file-header-immediate-origin) [Trace number audit trail](https://nacha-navigator.com/nacha-file-format#entry-ppd-trace-number) [Batch segregation](https://nacha-navigator.com/nacha-file-format#batch-header) ## Privacy by design: your file never leaves your device Every use case above shares one property: NACHA Navigator parses your ACH file entirely in your browser with client-side JavaScript. Nothing is uploaded, stored, or transmitted. That makes it safe to inspect production payment files containing real account and routing numbers — even under strict bank and enterprise data-handling policies. You can check it: the viewer’s security policy only lets it talk to this site, and your browser’s developer tools (Network tab) show that opening a file sends nothing. [Read the privacy page](https://nacha-navigator.com/privacy). ## Try it with your own file Upload a NACHA file (or explore the built-in sample) and see a field-by-field breakdown in seconds. Need to undo an erroneous entry? Generate a compliant ACH reversal file in a few clicks. [Analyze a NACHA file](https://nacha-navigator.com/) [Generate an ACH reversal](https://nacha-navigator.com/?sample=reversal-demo#reverse) Related tools ## More free tools for payment files. The same private, in-browser approach for the other formats that land on an operations desk. - ACH · Reversals ### ACH Reversal Reverse a whole NACHA file or the entries you choose: transaction codes flipped, REVERSAL as the entry description and the control totals recalculated. .ach · .txt [Reverse an ACH file](https://nacha-navigator.com/ach-reversal) - New X9.37 · Image cash letter ### X9 Viewer Open X9.37 check image files in your browser: every item’s front and back images, its MICR line and the records behind it. .x9 · .x937 · .icl [Open X9 Viewer](https://nacha-navigator.com/x9-viewer) - BAI2 · Balance reporting ### BAI2 Viewer Turn BAI2 bank reports into readable account summaries and transaction detail, with every type code explained. .bai · .bai2 · .txt [Open BAI2 Viewer](https://nacha-navigator.com/bai2-viewer) - Build files · REST API ### NACHA Generator Build a valid NACHA file with a visual form, or from JSON with the REST API. Control totals, entry hash and block padding are done for you. [Read the API docs](https://nacha-navigator.com/nacha-generator/api) [Open the generator](https://nacha-navigator.com/nacha-generator) FAQ ## Frequently Asked Questions Something else? [Email us](mailto:davidkaylor95+nachanav@gmail.com) or read the [NACHA file format reference](https://nacha-navigator.com/nacha-file-format). ### What is a NACHA file? A NACHA file is a [fixed-width text file format](https://nacha-navigator.com/nacha-file-format) defined by Nacha (the National Automated Clearing House Association) for submitting ACH payments in the United States. Every line is exactly 94 characters and represents a record: a File Header (type 1), Batch Headers (type 5), Entry Details (type 6), optional Addenda (type 7), Batch Controls (type 8), and a File Control (type 9). Banks and payment processors use this format to originate direct deposits, vendor payments, debits, and other electronic transfers. ### What is the record length of a NACHA file? 94 characters. Every record in a NACHA file is exactly 94 characters long, and the File Header says so in its [Record Size field](https://nacha-navigator.com/nacha-file-format#file-header-record-size) (094). Records come in blocks of ten (the Blocking Factor, 10), so when the record count isn’t a multiple of ten, the file ends with [filler records](https://nacha-navigator.com/nacha-file-format#block-fill) made of 94 nines; the File Control’s Block Count gives the number of blocks. The line break after each record isn’t part of the 94 characters. ### How do I read or open a NACHA file? Because a NACHA file is plain text with fixed-width fields, it is technically readable in any text editor — but interpreting it by counting character positions is slow and error-prone. A NACHA file viewer like [NACHA Navigator](https://nacha-navigator.com/) parses each record type automatically, labels every field (routing numbers, amounts, trace numbers, effective dates), and lets you click any field to see its meaning, position, and validation rules. ### How can I validate an ACH file without uploading it? Open it in the [NACHA Viewer](https://nacha-navigator.com/) on this site. The page’s JavaScript reads and checks the file on your own device: record lengths, control totals, entry hashes, routing check digits, dates, codes and block padding, with each problem pinned to its line and column. The file is never uploaded. The page’s Content Security Policy (connect-src 'self') lets it connect only to this site, and the only requests it sends are anonymous counters, which you can see in your browser’s developer tools. The [NACHA file errors page](https://nacha-navigator.com/nacha-file-errors) explains every check. ### Why was my NACHA file rejected by my bank? Common rejection causes include incorrect record lengths (lines must be exactly 94 characters), unbalanced batch or file control totals, invalid routing number check digits, bad effective entry dates, missing blocking-factor padding (files must contain a multiple of 10 records), and malformed Standard Entry Class (SEC) codes. Loading the file into a viewer that labels every field makes these problems visible in seconds instead of hours, and NACHA Navigator [checks for each of them automatically](https://nacha-navigator.com/nacha-file-errors). ### How do ACH reversals work? Under Nacha rules, an originator may reverse an erroneous entry (duplicate, wrong amount, wrong account, or wrong date) by submitting a reversing entry within five banking days of the settlement date of the original entry. The reversal must be for the full amount, flow in the opposite direction, and include "REVERSAL" in the company entry description. NACHA Navigator can [generate a properly formatted reversal file](https://nacha-navigator.com/ach-reversal) from your original entries, with the transaction codes flipped, the control totals recalculated and the REVERSAL description set. ### How do I create an ACH reversal file? Use the [ACH Reversal tool](https://nacha-navigator.com/ach-reversal). Open the original NACHA file, choose what to reverse (single entries, whole batches or the entire file) and why, confirm that you’ll notify each receiver, and download the reversal file. It keeps the original Company Name, Company Identification, SEC code and amounts; each transaction code is flipped between credit and debit, the Company Entry Description becomes REVERSAL, and the control totals, entry hash and block padding are recalculated. The reversal has to reach the receiver’s bank within five banking days after the original settlement date, and the tool shows that deadline. Prenotes, returns, notifications of change and IAT entries can’t be reversed with it. ### Is my ACH file data secure when I use NACHA Navigator? Yes. NACHA Navigator parses your file entirely in your browser using client-side JavaScript. The file is never uploaded to a server, never stored, and never transmitted over the network. Your account numbers, routing numbers, and payment data stay on your device the whole time. ### Is there a free NACHA file API? Yes. The NACHA Generator’s [REST API](https://nacha-navigator.com/nacha-generator/api) is free and needs no API key or account. POST your batches and entries as JSON to /api/v1/nacha/generate and the response is the NACHA file, with the control totals, entry hash and block padding worked out; /api/v1/nacha/validate checks the same JSON without building a file. It allows about 30 requests a minute per IP address and 128 KB of JSON per request (about 500 entries). It builds files from JSON: to check a NACHA file you already have, open it in the [NACHA Viewer](https://nacha-navigator.com/) instead. An OpenAPI description is at [/openapi.json](https://nacha-navigator.com/openapi.json), and AI assistants can use the same generator through the [NACHA Navigator MCP server](https://nacha-navigator.com/mcp-server). ### Can AI assistants use NACHA Navigator? Yes. AI assistants that support the Model Context Protocol (MCP) can connect to the [NACHA Navigator MCP server](https://nacha-navigator.com/mcp-server) at https://nacha-navigator.com/mcp. Its tools look up NACHA, BAI2 and X9.37 record layouts and codes, explain a single NACHA record or validation rule, and check or build a NACHA file from JSON. It needs no account or key, and inputs are processed in memory and never stored. To read the site itself, [/llms.txt](https://nacha-navigator.com/llms.txt) lists its main pages, each with a Markdown version at its address plus .md (the home page’s is [/index.md](https://nacha-navigator.com/index.md)). The MCP server has no tool that takes a whole file: to check a real file privately, open it in [the viewer](https://nacha-navigator.com/), which reads it in your browser. ### Does NACHA Navigator cost anything? No. NACHA Navigator is free to use for viewing, validating, and generating reversal files, and so are the X9 Viewer, the BAI2 Viewer and the NACHA Generator. If it saves you time, donations are welcome but never required. --- URL: https://nacha-navigator.com/about # About NACHA Navigator About Free tools and references for U.S. payment files: NACHA (ACH) files, X9.37 image cash letters and BAI2 balance reports. The files you open are read in your browser and never uploaded. Last updated October 30, 2026 ## What NACHA Navigator is NACHA Navigator is built for the people who handle payment files: bank and credit union operations staff, payroll and treasury teams, and the developers who build and debug payment integrations. It shows what is in a file field by field, checks it against the format’s rules, and explains the formats in plain language. | Tool | What it does | | --- | --- | | [NACHA Viewer](https://nacha-navigator.com/) | Parse, validate and reverse ACH files | | [ACH Reversal](https://nacha-navigator.com/ach-reversal) | Reverse entries or a whole ACH file | | [X9 Viewer](https://nacha-navigator.com/x9-viewer) | X9.37 check images and MICR data | | [BAI2 Viewer](https://nacha-navigator.com/bai2-viewer) | Bank balance and transaction reports | | [NACHA Generator](https://nacha-navigator.com/nacha-generator) | Build NACHA files with a form or the REST API | | [Reference pages](https://nacha-navigator.com/reference) | Record layouts, codes, validation rules and sample files | | [REST API](https://nacha-navigator.com/nacha-generator/api) | Generate and validate NACHA files from JSON, with no API key | | [MCP server](https://nacha-navigator.com/mcp-server) | The reference data and the generator, for AI apps | ## How your files stay on your device The viewers read files with JavaScript in your browser. A file you open is decoded and checked on your device. It is never uploaded, stored or logged, and it isn’t written to browser storage either: close or reload the tab and it is gone. Your browser enforces this. Every page with a viewer is served with a Content Security Policy whose `connect-src 'self'` directive lets the page connect only to nacha-navigator.com, so it can’t send your file to any other site, even by mistake. You can check both in your browser’s developer tools. In the Network tab, reload and select the page itself: its response headers include the Content-Security-Policy. Then open a file and watch the requests: the only ones are for the site’s own code and an anonymous counter that says a file was opened. ## What the server receives Like any website, the site’s host, Cloudflare, sees each connection, including your IP address, to deliver the pages and block abuse. NACHA Navigator’s own code receives only this: - **Anonymous counters.** When you open a page or use a tool, the page sends the name of the event, such as `page:home`, and nothing else. The totals are public on the [analytics page](https://nacha-navigator.com/analytics). - **API and MCP requests.** What you send to the [REST API](https://nacha-navigator.com/nacha-generator/api) or the [MCP server](https://nacha-navigator.com/mcp-server) is processed in memory to build the answer, and is never stored or logged. Rate limits use the caller’s IP address briefly; it isn’t kept. - **Donations.** They go through Stripe. Card and bank details go from Stripe’s payment form straight to Stripe and never reach our server. When a request fails, the server logs the error with the request’s method and path, and the log is kept for up to seven days. The [privacy policy](https://nacha-navigator.com/privacy) has the details, including every counter by name. ## Independence NACHA Navigator is an independent site. It is not affiliated with or endorsed by Nacha, the Accredited Standards Committee X9 or BAI, which publish the rules and specifications its tools follow. “NACHA” in its name refers to the file format. Nothing on the site is legal or compliance advice. The Nacha Operating Rules and the published standards are authoritative, and your financial institution’s requirements govern the files you send it. ## Sources and editorial policy The record layouts, codes and checks come from primary sources: | Format | Sources | | --- | --- | | NACHA (ACH) files | The [Nacha Operating Rules (opens in a new tab)](https://www.nacha.org/rules), Nacha’s public rule pages and its [ACH developer guide (opens in a new tab)](https://achdevguide.nacha.org/ach-file-overview); the Federal Reserve’s FedACH documentation; and the Treasury’s Green Book for federal government payments. | | BAI2 files | BAI’s [Cash Management Balance Reporting Specifications, Version 2 (opens in a new tab)](https://cdn.bai.org/migrated-from-www/docs/default-source/libraries/site-general-downloads/cash_management_2005.pdf) (2005, PDF). The type-code list was ported from the open-source [ministryofjustice/bai2 (opens in a new tab)](https://github.com/ministryofjustice/bai2) project (MIT License) and checked against that specification. | | X9.37 files | [ANSI X9.100-187 (opens in a new tab)](https://webstore.ansi.org/standards/ascx9/ansix91001872016) (the 2008 to 2016 editions) and the older DSTU X9.37-2003, checked against the [Federal Reserve’s DSTU X9.37-2003 customer documentation (opens in a new tab)](https://www.frbservices.org/binaries/content/assets/crsocms/financial-services/check/setup/frb-x937-standards-reference.pdf) and banks’ published image cash letter specifications (Regions, Truist). The [current edition, X9.100-187-2021 (opens in a new tab)](https://webstore.ansi.org/standards/ascx9/ansix91001872021), has not been reviewed yet. | - Rules are described in our own words. The rules and standards are copyrighted, so the site cites and links them and never copies their text. - Every reference page shows a “Last updated” date. It changes when the content does, never just to make a page look fresh, and pages are revised when a rule change takes effect. - If you find a mistake, email [davidkaylor95+nachanav@gmail.com](mailto:davidkaylor95+nachanav@gmail.com) with the page and what’s wrong. Confirmed corrections go on the page, and its date changes with them. ## How the tools are tested Each tool’s parsing and validation code is checked by an automated suite of more than 2,000 tests. Among them: - **Sample files.** The clean samples that come with the viewers must pass with no errors or warnings, and each sample with planted mistakes must report exactly the problems it documents. - **The NACHA Generator.** Files it builds, including randomly generated ones, are checked by the NACHA Viewer’s validator: the generator must never pass a file the viewer fails. - **The API documentation.** Its example requests are run through the API’s own code, and the responses on the page are the ones that code returns. - **The MCP server.** The official MCP TypeScript SDK client connects to it and calls every tool, checking each answer against the protocol’s schemas. ## Funding NACHA Navigator is free, with no account, no ads and no cookies. Donations pay for hosting and development. If the tools save you time, you can [support the project](https://nacha-navigator.com/donate). ## Sister sites Two free sister sites cover nearby work: - [ISO 20022 Navigator (opens in a new tab)](https://iso20022-navigator.com/) — camt.053, pain.001 and MT940 viewers - [PayOps Kit (opens in a new tab)](https://payopskit.com/) — Routing number, IBAN, BIC and ACH date tools ## Contact Questions, corrections and suggestions: email [davidkaylor95+nachanav@gmail.com](mailto:davidkaylor95+nachanav@gmail.com). ## Changelog | Date | What changed | | --- | --- | | October 30, 2026 | Added the [reference pages](https://nacha-navigator.com/reference), the [MCP server](https://nacha-navigator.com/mcp-server), Markdown versions of the pages, and [/llms.txt](https://nacha-navigator.com/llms.txt). | | October 28, 2026 | Rebuilt on Cloudflare, with the same tools at the same addresses. | --- URL: https://nacha-navigator.com/terms # Terms and Conditions Legal The terms for using NACHA Navigator and its free tools: the NACHA Viewer, the X9 and BAI2 viewers, the NACHA Generator and its REST API, the reference pages and the MCP server. Last updated October 30, 2026 ## 1. Disclaimer of Liability NACHA Navigator (“the Service”) is provided “as is” and “as available” without any warranties of any kind. The owner of this website expressly disclaims all liability for how users choose to use this Service. By accessing or using the Service, you acknowledge and agree that you are solely responsible for your use of the Service and any decisions made based on the analysis or information provided. The owner does not guarantee the accuracy, completeness, or reliability of any data or information provided through the Service. ## 2. No Professional Advice The information provided by the Service is for general informational purposes only and should not be construed as professional financial, banking, or legal advice. Users should consult with qualified professionals before making any financial, banking, or business decisions based on information obtained from the Service. This applies equally to the reference pages, the NACHA Generator REST API and the MCP server, and to anything an AI application tells you based on them. They describe file formats, codes and rules for information only; they are not legal or compliance advice. The Nacha Operating Rules and the relevant standards and specifications (such as ANSI X9.100-187 for X9.37 files and BAI’s specification for BAI2 files) are authoritative, and your financial institution’s requirements govern the files you send it. They are provided without warranty, as section 1 says. NACHA Navigator is independent and is not affiliated with or endorsed by Nacha, X9 or BAI. ## 3. Security and Privacy All file processing is performed locally in your browser. The files you open are not transmitted to our servers. However, the owner does not accept any responsibility for any loss, disruption, or damage to your data or computer system that may occur while using the Service. The Service is hosted on Cloudflare. Its servers deliver the pages and keep anonymous usage counters (for example, how many times a page was viewed); they never receive the contents of your files. Donations are processed by Stripe: your payment details go directly to Stripe and are never stored on our servers. If you use the REST API or the MCP server, the data sent to them is processed in memory on our servers to produce a response and is never stored or logged. The [privacy page](https://nacha-navigator.com/privacy) describes exactly what is collected. ## 4. Limitation of Liability In no event shall the owner, its officers, directors, employees, or agents be liable for any indirect, punitive, incidental, special, consequential, or exemplary damages, including without limitation damages for loss of profits, goodwill, use, data, or other intangible losses, that result from the use of, or inability to use, the Service. To the maximum extent permitted by applicable law, the owner assumes no liability or responsibility for any: - Errors, mistakes, or inaccuracies in content; - Personal injury or property damage resulting from your access to or use of the Service; - Any unauthorized access to or use of our servers and/or any personal information stored therein; - Any interruption or cessation of transmission to or from the Service; - Any bugs, viruses, trojan horses, or the like that may be transmitted to or through the Service; - Any errors or omissions in any content or for any loss or damage incurred as a result of the use of any content posted, emailed, transmitted, or otherwise made available through the Service. ## 5. Indemnification You agree to defend, indemnify, and hold harmless the owner, its officers, directors, employees, and agents, from and against any and all claims, damages, obligations, losses, liabilities, costs or debt, and expenses (including but not limited to attorney’s fees) arising from your use of the Service. ## 6. Governing Law These Terms shall be governed by and construed in accordance with the laws of the United States, without regard to its conflict of law provisions. --- *By using this Service, you acknowledge that you have read these Terms and Conditions, understand them, and agree to be bound by them. If you do not agree to these Terms, you must not access or use the Service.* Questions about these terms? Email [davidkaylor95+nachanav@gmail.com](mailto:davidkaylor95+nachanav@gmail.com). [Return to Home](https://nacha-navigator.com/) --- URL: https://nacha-navigator.com/privacy # Your files never leave your browser Privacy policy NACHA Navigator reads ACH, X9 and BAI2 files with JavaScript on your own device. This page lists everything the site’s server does receive: anonymous counters, what you send to its API or MCP server, and, if you donate, a request to Stripe. Last updated October 30, 2026 ## What happens in your browser - Files you open in the NACHA, X9 and BAI2 viewers are read, decoded and checked by JavaScript on the page. They are not uploaded, stored or logged anywhere. - Files you build with the NACHA Generator or the reversal tool are created in your browser too, and download straight to your device. - File contents are never written to browser storage. Close or reload the tab and they are gone. - The pages’ security policy only allows connections back to this site (`connect-src 'self'`), so a page couldn’t send your file anywhere else even by mistake. To check, open your browser’s developer tools, choose the Network tab and open a file. ## What our server receives The site runs on Cloudflare. Like any website, Cloudflare handles the connection, including your IP address, to deliver the pages and block abuse, under [Cloudflare’s privacy policy](https://www.cloudflare.com/privacypolicy/). Our own code receives only the following. ### Anonymous usage counters When you open a page or use a tool, the page sends the name of the event, such as `page:home`, and nothing else. The server adds one to that counter and to the same counter for the current day. No cookie, IP address, browser details, file name or file content is stored with it. These are all of the counters: | Counted when | Counter names | | --- | --- | | **Page views.** A page is opened (one counter per page). | `page:home` `page:use_cases` `page:terms` `page:privacy` `page:donate` `page:donation_success` `page:analytics` `page:x9_viewer` `page:bai2_viewer` `page:nacha_generator` `page:nacha_generator_api` `page:nacha_file_format` `page:reference` `page:nacha_file_errors` `page:ach_transaction_codes` `page:bai2_type_codes` `page:bai2_file_format` `page:x9_file_format` `page:sample_files` `page:ach_reversal` `page:about` `page:mcp_server` `page:not_found` | | **Files opened.** A file or a built-in sample is opened in one of the viewers. Only the count is sent; the file stays on your device. | `file:nacha:upload` `file:nacha:sample` `file:x9:upload` `file:x9:sample` `file:bai2:upload` `file:bai2:sample` | | **Reversals.** A reversal file is built in the NACHA Viewer. | `reversal:generated` | | **NACHA Generator.** The generator builds a file in your browser, or its REST API returns a file. | `generator:generated` `generator:api` | | **Downloads.** A result is downloaded: CSV, JSON, check images or a NACHA file. | `export:nacha:csv` `export:nacha:json` `export:nacha:reversal` `export:x9:images` `export:x9:csv` `export:x9:json` `export:bai2:csv` `export:bai2:json` `export:generator:ach` `export:generator:json` | | **AI agents.** An AI agent or other program fetches /llms.txt, /llms-full.txt, the Markdown version of a page, the OpenAPI description or the API catalog, connects to the MCP server, or calls one of its tools. Our server counts these itself as it answers. It keeps only the count: never the request’s contents, the user agent or the IP address. | `agent:llms_txt` `agent:llms_full_txt` `agent:markdown` `agent:markdown_negotiated` `agent:openapi` `agent:api_catalog` `mcp:connect` `mcp:get_nacha_record_layout` `mcp:explain_nacha_record` `mcp:lookup_nacha_code` `mcp:explain_nacha_validation_rule` `mcp:validate_nacha_file_request` `mcp:generate_nacha_file` `mcp:lookup_bai2_type_code` `mcp:get_bai2_record_layout` `mcp:get_x9_record_layout` | The totals are public on the [analytics page](https://nacha-navigator.com/analytics): you see the same numbers we do. ### Donations On the [donate page](https://nacha-navigator.com/donate), the amount you choose is sent to our server, which asks Stripe to create a payment for exactly that amount. Your card or bank details go from Stripe’s payment form straight to Stripe and never reach our server. Stripe processes the payment under the [Stripe privacy policy](https://stripe.com/privacy). Stripe’s code loads only on the donate and thank-you pages. ### The generator API If you call the NACHA Generator REST API from your own software, the JSON you send is processed in memory to build the file and is never stored or logged. Each successful call adds one to `generator:api`. Rate limits use the caller’s IP address briefly to stop abuse; it isn’t kept. ### The MCP server AI apps connected to the [MCP server](https://nacha-navigator.com/mcp-server) at `/mcp` send the arguments of each tool call: a code to look up, one record of a NACHA file to explain, or the JSON for a file to check or generate. They are processed in memory to compute the answer, which goes back to the app, and are never stored or logged. A connection adds one to `mcp:connect`, and each successful tool call one to that tool’s counter, such as `mcp:lookup_nacha_code`. Rate limits use the caller’s IP address briefly to stop abuse; it isn’t kept. The AI app you use handles what you share with it under its own privacy policy. ### Files for AI agents The site publishes files for AI agents and other programs: `/llms.txt`, `/llms-full.txt`, the Markdown versions of these pages, the OpenAPI description (`/openapi.json`) and the API catalog. Fetching one adds one to its counter in the table above, such as `agent:llms_txt`; nothing else about the request is kept. ### Error logs When any request fails, our server logs the error with the request’s method and path, such as `POST /mcp`, and Cloudflare keeps that log line for up to seven days. ## Cookies and storage - NACHA Navigator sets no cookies. - Display preferences, like your choice of light or dark theme, are saved in your browser’s local storage. They never leave your device. - On the donate and thank-you pages, Stripe’s payment form may set its own cookies to prevent fraud, as its privacy policy describes. ## Questions Email [davidkaylor95+nachanav@gmail.com](mailto:davidkaylor95+nachanav@gmail.com). The [terms and conditions](https://nacha-navigator.com/terms) cover the rest. --- URL: https://nacha-navigator.com/donate # Support NACHA Navigator Support the project Your donation helps us maintain and improve NACHA Navigator, keeping it free and accessible to all financial professionals. - ## Processed by Stripe Your card details go straight to Stripe. They never reach our servers, and we never store them. - ## Every tool stays free Donations pay for hosting and new features. Nothing is locked behind them, and they are never required. - ## One payment, no account A single payment in US dollars, from $1 to $10,000. No sign-up and no subscription. Questions about a donation? [Email us](mailto:davidkaylor95+nachanav@gmail.com?subject=NACHA%20Navigator%20donation). ## Make a Donation All donations go toward hosting costs and future development. **Donation amount** Any amount from $1 to $10,000. Payment details One-time payment in US dollars, secured by Stripe Payments are securely processed through Stripe. Your card information is never stored on our servers. NACHA Navigator is not affiliated with NACHA (The National Automated Clearing House Association).