How to Create a NACHA File: Structure, Submission, and 2026 Fraud Rules

To create a NACHA file, you set up an originator agreement with your bank, collect your company identifiers and each recipient’s routing and account numbers, and generate a fixed-width plain-text file where every line is exactly 94 characters and the record types nest in a strict order. Most businesses produce the file through accounting or dedicated ACH software rather than by hand, then transmit it to their bank through an online portal or over SFTP before the daily cutoff. The mechanics are unforgiving on formatting, but the harder work happens before you write a single line: getting the bank relationship, the authorizations, and the transaction classification right.

Get Set Up as an ACH Originator First

You cannot submit a NACHA file until your bank has approved you to originate ACH transactions. In ACH terminology, your bank is the Originating Depository Financial Institution (ODFI), and you are the Originator. The ODFI underwrites your ACH activity the way a lender underwrites a loan. They evaluate your creditworthiness, set exposure limits on how much you can move per day or per batch, and may require a reserve account or collateral to cover potential returns. This step catches many first-time originators off guard. It can take days or weeks, and the bank may decline the arrangement if your return rates or fraud risk look too high.

The agreement also spells out your responsibilities under the Nacha Operating Rules. Chief among them is authorization: before you debit anyone’s account, you need their permission. For consumer debits, the authorization must include specific information identifying the transaction and be readily identifiable as an authorization with clear terms.¹ The Nacha Rules don’t prescribe one exact format, but written authorization is standard practice, especially for payroll. Originating debits without proper authorization exposes you to returns, fines, and potential termination of your ACH privileges.

Gather the Data Your File Will Contain

Each file mixes your company data with your recipients’ banking details. On your side you need your legal company name and a ten-digit Company Identification number. That number is commonly your federal Employer Identification Number preceded by a “1,” though some banks accept a DUNS number preceded by a “3” or other configurations. Your bank will tell you exactly which format they expect, and changing it later requires advance notice. You also need the nine-digit routing number for your own bank and the routing number and account number for every recipient.

Accuracy on routing and account numbers is non-negotiable. A wrong routing number triggers return code R03 (“No Account/Unable to Locate Account”), and a wrong account number triggers R04 (“Invalid Account Number”).² Returns typically carry bank-imposed fees per item, and high return rates can jeopardize your originator status. Getting the data right up front is the single most effective way to keep costs down.

Choose the Right SEC Code

Every batch in a NACHA file must carry a Standard Entry Class (SEC) code that describes the type of transaction. The code affects authorization requirements, fraud screening obligations, and how the receiving bank handles the entry. The common codes:

PPD (Prearranged Payment and Deposit): consumer transactions like payroll direct deposits and recurring bill payments from personal accounts.
CCD (Cash Concentration or Disbursement): business-to-business payments, including vendor disbursements and corporate cash transfers.
WEB (Internet-Initiated Entries): debits authorized online or through a mobile device. Originators must validate the account number on first use as part of a commercially reasonable fraud detection system.³
TEL (Telephone-Initiated Entries): the consumer authorizes a debit over the phone. Single entries require a recorded oral authorization or written confirmation.
IAT (International ACH Transaction): required when any part of the payment involves a financial institution outside the United States.

Using the wrong SEC code is a compliance violation, not just a labeling error. Coding an internet-authorized debit as PPD instead of WEB, for example, means you skip the mandatory account validation step, which creates regulatory exposure and higher fraud risk.⁴ The U.S. Treasury’s own payment systems limit SEC code options to PPD, CCD, and IAT depending on the payment type.⁵

Build the File Structure

The file is a plain ASCII text document. Every line is exactly 94 characters, padded with spaces where needed. Lines follow a strict hierarchy, and the first digit of each line identifies its record type. The structure nests: the file wraps around batches, and each batch wraps around individual entries.

The Six Record Types

File Header (Record Type 1): always the first line. Identifies the ODFI’s routing number (the “Immediate Destination”) and your company (the “Immediate Origin”), plus the file creation date. The priority code is always “01.”⁴
Batch Header (Record Type 5): opens each batch of related transactions. Contains the SEC code, company name, company ID, effective entry date, and a Service Class Code indicating whether the batch contains credits only (220), debits only (225), or a mix (200).⁶
Entry Detail (Record Type 6): one line per payment instruction. Contains the recipient’s routing number, account number, dollar amount, recipient name, and a transaction code indicating whether the entry is a credit or debit to a checking or savings account.
Addenda (Record Type 7): optional. Attaches up to 80 characters of freeform payment-related information to a Type 6 entry, used for invoice numbers, remittance details, or other context.⁴
Batch Control (Record Type 8): closes each batch. Contains the total dollar amounts for debits and credits in the batch, a count of entries, and the entry hash total.
File Control (Record Type 9): always the last functional line. Summarizes all batches: total batch count, total entry count, cumulative hash, and total dollar amounts across the file.

Entry Hash and Block Padding

The entry hash is a built-in error check. Your software adds up the first eight digits of every recipient routing number in the file. If the total exceeds ten digits, you keep only the rightmost ten. The bank’s system recalculates this on receipt, and any mismatch means something in the entry detail records is wrong. It won’t tell you which entry has the error, only that one exists.

After the File Control record, the total number of lines in the file must be a multiple of ten. If it isn’t, you add padding lines made entirely of nines (94 nines per line) until you reach the next multiple. A file with 23 lines of real data needs seven padding lines to reach 30. Failing to meet the 94-character line length or the ten-line block requirement causes the bank’s system to reject the entire file on upload.⁶

Generate the File

Most businesses never build a NACHA file by hand. Accounting platforms like QuickBooks and Xero include ACH modules that export ledger data directly into the correct format. These tools handle character alignment, hash calculations, and padding automatically, which eliminates the most common formatting failures. For organizations with custom ERP systems or unusual batch workflows, dedicated ACH file generation software provides a more flexible interface for mapping raw banking data to the record types.

Some smaller operations use Excel templates with macros that map spreadsheet columns to NACHA field positions. This works, but it’s fragile. A stray hidden character, a column that shifts by one position, or a formula that rounds a dollar amount to three decimal places instead of two will produce a file the bank rejects. If you go this route, run the output through a validation tool before every submission.

Whatever method you use, the output must be a clean plain-text file with no hidden formatting, no Unicode characters, and no byte-order marks. Modern tools usually include a pre-validation step that flags errors before you save. Regulation E requires financial institutions involved in electronic fund transfers to retain evidence of compliance for at least two years.⁷ As the originator, you should maintain your own records of every file generated, including timestamps and confirmation receipts, to match that standard.

Submit the File to Your Bank

You have two main ways to get the file to your ODFI. The first is a manual upload through the bank’s online cash management portal: you log in, navigate to the ACH or file transfer section, browse for the file, and submit. The second is automated transmission over SFTP (Secure File Transfer Protocol), which lets your system push files directly to the bank on a schedule without anyone logging into a browser. SFTP supports the same fraud and risk controls as the portal, including notifications, approvals, and two-factor authentication. Organizations running payroll weekly or processing hundreds of vendor payments a month generally graduate to SFTP quickly.

Either way, the bank’s system runs an immediate structural validation on receipt. It checks line lengths, record type sequencing, hash totals, and whether total debits and credits balance. If the file passes, the portal displays a summary of the transaction count and total dollar amount for you to confirm against your internal records. After you authorize the submission, the bank issues a confirmation number or receipt.

Cutoffs and Effective Dates

The ACH network processes files through the Federal Reserve’s FedACH system or The Clearing House’s EPN on defined schedules. For standard next-day ACH, the last ODFI submission window is generally around 5:00 PM ET, with settlement occurring the following banking day.⁸ Your bank’s own cutoff is typically earlier than the network deadline to leave room for processing, so confirm the specific window with your ODFI. Missing the cutoff pushes settlement out by at least one business day, which can mean late payroll or missed vendor payment terms.

If you need faster settlement, Same Day ACH processes eligible entries on the same business day they’re submitted. The network runs three daily processing windows with ODFI submission deadlines at approximately 10:30 AM, 1:00 PM, and 4:00 PM ET.⁸ The per-transaction limit is $1 million.⁹ Same Day ACH also carries a per-item fee of 5.2 cents paid from the ODFI to the receiving bank, which your bank will likely pass through on top of any standard transmission fees.¹⁰

The effective entry date in the Batch Header controls whether an entry goes same-day or next-day. If the date is the current business day and you submit before the same-day cutoff, the entry is eligible for same-day settlement. If the date is in the future, the entry settles on that date. A stale date (one already passed) settles at the next available opportunity.

When Something Goes Wrong After Submission

Not every entry clears. The receiving bank generally has two banking days after settlement to return an entry for reasons like insufficient funds (R01), a closed account (R02), or an invalid account number (R04). For unauthorized debits to consumer accounts, the return window extends to 60 calendar days, and the receiving bank can require a written statement from the consumer. This is why proper authorization before originating matters: an unauthorized return months later creates both a financial hit and a compliance problem.

Notifications of Change (NOCs) are different from returns. Instead of bouncing the payment, the receiving bank processes the entry but sends back a correction notice telling you to update your records. Common NOC codes include C01 (incorrect account number), C02 (incorrect routing number, usually from a bank merger), C03 (both routing and account number wrong), and C05 (incorrect transaction code, for example coding an entry as checking when the account is savings). Under the Nacha Operating Rules, you must apply NOC corrections before sending the next entry to that recipient. Ignoring an NOC and resubmitting with the old data is a rules violation and will eventually produce a hard return.¹¹

If you submit a file with errors like duplicate payments, wrong amounts, or entries sent to the wrong accounts, you can initiate a reversal. The clock is tight. You must transmit the reversing file within 24 hours of discovering the error, and no later than five banking days after the settlement date of the original entry.¹² Any corrected entries must also go out within that five-day window. A reversal is not a guaranteed clawback. It’s an instruction to the receiving bank to return the funds, but the recipient’s account may already be empty or closed. The Nacha Rules limit reversals to specific circumstances (erroneous data, duplicate files, or files sent on the wrong date), not buyer’s remorse.

New Fraud Monitoring Requirements in 2026

Nacha has been tightening fraud prevention requirements, and 2026 brings significant new obligations that affect how you build and control your ACH process. Starting March 20, 2026, large originators and third-party service providers must implement fraud monitoring systems for ACH transactions. By June 22, 2026, all other originators must do the same.¹³ The rules require risk-based procedures to detect fraudulent transactions, including measures like multifactor authentication, dual-control processes for initiating and approving transactions, and IP address restrictions. You’ll also need to review your fraud monitoring procedures annually.

Also effective in March 2026, Nacha introduces two new standard Company Entry Descriptions: “PAYROLL” and “PURCHASE.” These don’t change how the file is structured, but they give receiving banks and consumers clearer information about what a transaction is for.¹³

For WEB debit entries specifically, account validation has been mandatory since 2021. You must verify that the account number is a valid, open account at the receiving bank before originating the first WEB debit to it, and again whenever the account number changes.³ Nacha doesn’t consider a fraud detection system that skips this step to be commercially reasonable, no matter what other controls you have in place.

1
Nacha. The Importance of Compliant ACH Authorizations
2
Nacha. Nacha ISO 20022 Guide to Mapping US ACH Return Items and Notifications of Change
3
Nacha. Account Validation Frequently Asked Questions
4
NACHA Developer Guide. ACH File Details
5
Fiscal.Treasury.gov. Standard Entry Class Code (SEC)
6
Nacha. ACH File Overview
7
eCFR. 12 CFR Part 205 – Electronic Fund Transfers (Regulation E) – Section: 205.13 Administrative Enforcement; Record Retention
8
Nacha. SDA Schedules and Funds Availability
9
Federal Reserve Financial Services. Same Day ACH Frequently Asked Questions
10
Nacha. Same Day ACH Moving Payments Faster (Phase 1)
11
U.S. Treasury Financial Experience. Notification of Change
12
Nacha. Same Day ACH Moving Payments Faster (Phase 2)
13
Nacha. Summary of Upcoming Rule Changes