NACHA file format

Learn the 94-character record structure, hierarchy, SEC codes and control totals. Free, no signup, and your file is processed locally in your browser.

Primary topic: NACHA file format

By Updated Contact

The format in one minute

A NACHA file is plain text. Every physical record is exactly 94 characters. Records form a hierarchy: one file contains batches; each batch contains entries; entries may contain addenda. Type 9 padding records bring the physical record count to a multiple of ten.

TypeRecordPurpose
1File HeaderOrigin/destination, creation timestamp and file-level transmission settings.
5Batch HeaderCompany, SEC code, description, effective date and ODFI.
6Entry DetailReceiver routing/account, transaction code, amount, name and trace number.
7AddendaOptional payment information or specialized Return/NOC data.
8Batch ControlBatch entry count, routing hash, debit/credit totals and identifiers.
9File ControlFile-wide batch/block counts, entry count, hash and totals.

SEC codes

PPD generally represents consumer entries; CCD generally represents corporate entries. Other SEC codes have their own authorization, data and addenda requirements. This first version authors PPD and CCD and can inspect other codes.

Transaction codes

The transaction code identifies credit vs debit and account type. Common examples are 22 checking credit, 27 checking debit, 32 savings credit and 37 savings debit.

Control values

Batch and file controls reconcile entry/addenda counts, routing-number hashes, total debits and total credits. The hash uses the first eight routing digits and retains the low-order ten digits.

Operational caution

NACHA conformance and bank acceptance are different. An ODFI may require specific identifiers, lead times, balanced files or validation rules. Confirm production settings with the financial institution.

What can this NACHA file format help you do?

The NACHA file format explains how 94-character ACH records are organized into files, batches, entries, addenda and controls. Use this NACHA file format as a practical first step, then review its results carefully. the guide is educational and does not replace the current operating rules or your ODFI’s specifications.

When should you use the NACHA file format?

A reliable NACHA file format workflow starts by confirming the business purpose before changing or exporting any data. This page is designed for explains how 94-character ACH records are organized into files, batches, entries, addenda and controls. It performs the supported work locally, so the source does not need to be sent to a conversion service. Use the NACHA file format with an approved source and a clearly defined expected result.

How do you use the NACHA file format?

  1. 1

    Prepare input for the NACHA file format

    Start with no upload is required; use the guide while reading or troubleshooting an ACH file. Work from a copy, preserve leading zeros and remove unrelated report headings or totals that could be mistaken for transaction data.

  2. 2

    Run and review the NACHA file format

    Use the on-page controls, then compare the displayed batch count, entry count, total debits and total credits with the source expectation. Investigate warnings instead of assuming that a downloadable result is correct.

  3. 3

    Validate before operational use

    The expected result is a practical reference for record types, SEC codes, transaction codes, hierarchy, hashes, totals and padding. Before transmission or downstream import, review record positions, required fields, entry-to-addenda relationships, control reconciliation and bank-specific requirements, save the source separately and follow your organization’s approval process.

What common NACHA file format problems should you check?

The input is not recognized

Confirm that the selected input really contains no upload is required; use the guide while reading or troubleshooting an ACH file. A renamed extension does not convert a spreadsheet, PDF or binary export into a valid ACH-related source.

The NACHA file format reports unexpected totals

Compare entries one batch at a time. Missing rows, duplicated rows, amount scaling, debit-versus-credit selection and malformed addenda can all change counts or monetary totals.

The file validates but the bank rejects it

Format validation does not verify enrollment or bank policy. the guide is educational and does not replace the current operating rules or your ODFI’s specifications. Ask the ODFI for the rejection code and compare it with the company profile, identifiers and processing date.

What belongs on a NACHA file format review checklist?

  • Routing numbers, account numbers and identifiers retain required leading zeros.
  • Debit and credit totals, entry counts and addenda counts reconcile.
  • Effective dates, SEC codes, service classes and transaction codes are appropriate.
  • A second reviewer has checked record positions, required fields, entry-to-addenda relationships, control reconciliation and bank-specific requirements before production use.

Frequently asked questions about the NACHA file format

What does the NACHA file format do?

It explains how 94-character ACH records are organized into files, batches, entries, addenda and controls. The NACHA file format processes the data locally in your browser and does not require an account.

What input does this tool need?

It needs no upload is required; use the guide while reading or troubleshooting an ACH file. Files remain on your device during processing.

What will I get from the tool?

You will get a practical reference for record types, SEC codes, transaction codes, hierarchy, hashes, totals and padding. Review the result before using it in an operational workflow.

What should I verify before using the result?

Check record positions, required fields, entry-to-addenda relationships, control reconciliation and bank-specific requirements. Also remember that the guide is educational and does not replace the current operating rules or your ODFI’s specifications.

How should I use this NACHA file format reference?

Use it alongside a real or fictitious example, compare one field at a time and then confirm the complete file with a validator. Fixed-width positions are easier to understand when viewed in context.

Does this replace the current Nacha Operating Rules?

No. This page is a practical technical guide, not the complete operating rules, legal advice or an ODFI implementation specification. Use authoritative requirements for production decisions.

Why can a technically valid value still fail?

A checksum, field length or record layout only proves limited structural validity. Banks can apply enrollment, account-status, processing-window and risk controls beyond the file format.

Where should I start when troubleshooting?

Begin with record positions, required fields, entry-to-addenda relationships, control reconciliation and bank-specific requirements. Work from file-level structure toward batches and entries so one early formatting error does not create misleading downstream symptoms.

Which authoritative sources support this page?

Technical explanations are checked against these primary sources. Bank-specific requirements can be narrower than general format guidance.

  1. Nacha ACH File DetailsOfficial record-field guidance, including Batch Header SEC codes and addenda capabilities.
  2. Nacha ACH File OverviewOfficial explanation of files, batches, entries, controls, and batch grouping.
  3. Nacha: How ACH WorksOfficial overview of ACH participants, consumer and corporate payments, and authorization responsibilities.
  4. Nacha Operating Rules TopicsCurrent rule changes and implementation topics published by Nacha.

Sources reviewed August 20, 2026. Nacha owns and maintains the linked materials.

What should you know about ACH/NACHA files?

ACH files use the NACHA fixed-width format: every record is 94 characters, files contain one or more batches, and control records reconcile entry counts, routing-number hashes, debits and credits. Always confirm bank-specific settings with your financial institution before uploading a production file.