How to Create a NACHA File: Format, Records, and Tools

To create a NACHA file you need three things from your bank (approval to originate ACH, a company ID, and the bank's file requirements), the routing and account numbers of everyone you are paying or collecting from, and something that writes the 94-character records in the right order: a file header, one or more batches of entries, and the control totals that close them. You can build it in a spreadsheet, in your bank's portal, or with software made for it. This guide covers all three.

What a NACHA file is

A NACHA file is a plain text file that tells your bank which accounts to credit or debit, for how much, and when. The format is set by Nacha, the body that runs the ACH network, and every US bank reads the same layout. One file can carry payroll, vendor payments, customer collections or all three.

If you are new to the format, What Is a NACHA File? shows a complete five-record example. This post goes a level deeper: what each record holds, where the values come from, and how to produce the file.

What your bank gives you before you start

You cannot send ACH files to a bank that has not set you up to originate them. Setup usually involves an application, a credit review and an origination agreement. When it is done, the bank gives you:

• Approval to originate, often with limits on how much you can send per file or per day.
• A company ID. Ten characters that identify your business in every batch. Most banks use a 1 followed by your nine-digit EIN, but the bank decides. Use exactly what they give you.
• An immediate origin value for the file header. Often the same as the company ID, sometimes a bank-assigned number. Again, use what they give you.
• The bank's routing number, which goes in the file header as the immediate destination.
• File requirements. How they want the file delivered (portal upload or SFTP), how far in advance of the effective date, and whether they want a prenote (a zero-dollar test entry) before the first live payment to a new account.

Keep this information together. Every file you ever build starts with it.

The six record types

Every line in a NACHA file is exactly 94 characters, and the first character of each line says what kind of record it is.

File header (record 1)

The first line of the file. Besides the fixed values that never change (priority code 01, record size 094, blocking factor 10, format code 1), it carries your bank's routing number as the immediate destination, your immediate origin value, the creation date and time, a file ID modifier (a letter that makes each file sent on the same day unique), and the names of the bank and your business.

Batch header (record 5)

A batch groups entries that share the same company information, SEC code, entry description and effective date. Its header carries:

• Service class code. 200 for a batch that mixes debits and credits, 220 for credits only, 225 for debits only.
• Company name, up to 16 characters. This is what shows on the other party's bank statement.
• Company ID, the ten characters your bank gave you.
• SEC code. PPD for payments to or from a person, CCD for a business, CTX for a business payment with invoice detail, WEB for debits authorized online, TEL for debits authorized by phone. See the SEC code reference for the full list.
• Company entry description, up to 10 characters, such as PAYROLL or RENT. This also shows on the statement.
• Effective entry date, the date you want the money to move, as YYMMDD.
• Your bank's routing number (the first eight digits) and a batch number.

Entry detail (record 6)

One line per payment. The positions matter, because the bank reads by column, not by separator:

• Transaction code (columns 2-3). 22 credits a checking account, 27 debits one. 32 and 37 do the same for savings accounts. 23, 28, 33 and 38 are the prenote versions.
• Receiving routing number (columns 4-11) and its check digit (column 12).
• Account number (columns 13-29), left-justified.
• Amount (columns 30-39) in cents, right-justified with leading zeros and no decimal point. $1,250.00 is written 0000125000.
• Individual ID (columns 40-54), anything that helps the other party recognise the payment, such as an employee number or customer ID.
• Name (columns 55-76), up to 22 characters.
• Addenda indicator (column 79). 1 if an addenda record follows, otherwise 0.
• Trace number (columns 80-94). Your bank's routing number (eight digits) followed by a sequence number, unique within the file.

Addenda (record 7)

An optional line that follows an entry and carries up to 80 characters of payment-related information. The classic use is an invoice or purchase order number on a vendor payment so the vendor's bank can pass it through. CTX batches require an addenda on every entry. CCD batches treat it as optional. Never put full account numbers or Social Security numbers here; the banks that handle the file can read it.

Batch control (record 8)

Closes the batch and lets the bank check that nothing was lost or altered on the way:

• The entry and addenda count for the batch.
• The entry hash: add up the eight-digit routing numbers (without the check digit) of every entry in the batch, then keep the rightmost ten digits.
• Total debit and total credit amounts, in cents.
• The company ID, your bank's routing number and the batch number again, which must match the batch header.

File control (record 9)

The last real line. It repeats the batch count, the entry and addenda count, the entry hash and the dollar totals for the whole file, plus the block count. NACHA files are written in blocks of ten lines. If the file does not end on a multiple of ten, it is padded with lines of 94 nines until it does, and the block count is the total number of lines divided by ten.

The fields people get wrong

Every one of these produces a rejected file or a rejected payment:

• An amount with a decimal point, or not padded to ten digits.
• A routing number whose check digit does not match.
• A batch control total that does not equal the sum of the entries, usually because a row was added after the totals were calculated.
• An entry hash that includes the check digit, or that was not truncated to ten digits.
• A line that is 93 or 95 characters because of a trailing space or a missing one.
• An effective date on a weekend or bank holiday, or earlier than your bank's lead time allows.
• A SEC code that does not match the authorization you hold (a WEB debit without an online authorization, for example).
• Missing padding lines, so the block count does not match.

Common ACH File Errors explains each of these in more detail, with what the bank's rejection message usually says.

Three ways to build the file

1. A spreadsheet template

Put one entry per row, use formulas to pad each field to its width, concatenate the fields into a 94-character line, and calculate the hash and totals. This works for a handful of payments to the same people every month, and it costs nothing.

Where it goes wrong: a formula that is overwritten by a typed value, a copied row that keeps an old trace number, a text editor that adds a byte-order mark or Windows line endings the bank does not expect, and the hash and block-padding rules, which are easy to get almost right. Each rejected file costs a day, because you find out after the cutoff. For the full picture of what goes wrong and what it costs, see Manual NACHA File Creation vs Software.

2. Your bank's portal

Most business banking portals let you key in payments and build the file on the bank's side, or upload a file you built elsewhere. Keying payments in the portal is the simplest option when you pay a few people a month and nothing changes. It is also the most manual: there is usually no import from a spreadsheet, no reusable batch, and the recipient list lives inside one bank.

Many banks charge a monthly fee for the origination module and a per-item fee on top. Ask for the fee schedule when you set up origination.

3. Purpose-built software

ACH file software keeps your company information, bank accounts and recipients, builds the records from them, runs the NACHA checks before you download anything, and sends the file to the bank.

ACH Drafter works this way. You enter your company ID, immediate origin and bank details once. Recipients can be added one at a time or imported from a CSV. Each draft is one or more batches with an SEC code, an effective date and a list of entries; CCD and CTX entries can carry the invoice number as an addenda. Every file is checked against the NACHA formatting rules before it is generated. Then you download it and upload it through your bank's portal, or send it to the bank over SFTP without leaving FiSTWorks. A draft you send every month can be saved as a template.

FiSTWorks creates and checks the file. It never holds or moves money, and your bank makes the final decision on every file and every payment.

Validate, then send

Whichever way you build the file, validate it before it goes to the bank. Checking record lengths, routing check digits, control totals and the hash by hand takes an hour per file; the free ACH Validator does it in seconds and tells you which line and field is wrong. How to Validate a NACHA File walks through the full checklist.

Then deliver the file the way your bank asked: upload it in the portal or send it over SFTP, at least one business day before the effective date unless your bank told you otherwise. For a worked example of the whole process, with debits instead of credits, read How to Create a NACHA File for Rent Collection.

See how ACH Drafter builds the file →