How to Create a NACHA File in Excel (and When Not To)

You can create a NACHA file in Excel, but Excel does not produce one for you. A NACHA file is a plain text file where every line is exactly 94 characters, fields are padded to fixed widths, amounts carry two implied decimals with no decimal point, and several control fields have to be calculated from the entries themselves. Excel can lay out and concatenate those lines, then you save the result as a .txt file. What Excel cannot do is validate the result, and an invalid file gets rejected by the bank.

That is the honest short answer. Below is the full method for the people who genuinely need it, plus the point at which a spreadsheet stops being the right tool.

What a NACHA file has to contain

An ACH file is a nest of six record types, each identified by the digit in position 1. Every header has a matching control record, and the file is padded at the end so the total line count is a multiple of ten.

Two formatting rules govern every field. Alphanumeric fields are left justified and padded on the right with spaces. Numeric fields are unsigned, right justified, and padded on the left with zeros. Get either backwards and the line is still 94 characters long, so nothing looks wrong until the bank rejects it.

How to build the file in Excel, step by step

Work in three sheets: one for the payment data you actually maintain, one that builds each record type, and one that stacks the finished lines in order.

1. Set up the payment sheet. One row per payment with receiver name, routing number as text, account number as text, amount as a number, and transaction code. Format routing and account columns as Text before you paste anything, or Excel will strip leading zeros and turn long account numbers into scientific notation.
2. Write padding helpers. For an alphanumeric field of width n use =LEFT(A2&REPT(" ",n),n). For a numeric field use =RIGHT(REPT("0",n)&A2,n). For the amount field, ten digits with two implied decimals, use =TEXT(ROUND(A2*100,0),"0000000000"), so 123.45 becomes 0000012345.
3. Build the entry detail line. Concatenate in field order: record type 6, two digit transaction code, the first eight routing digits, the check digit, the 17 character account, the ten digit amount, the 15 character individual ID, the 22 character individual name, two characters of discretionary data, the addenda indicator, and the 15 digit trace number. Check the result with =LEN(cell). It must be 94 for every row, with no exceptions.
4. Calculate the trace numbers. The trace number is your originating bank routing prefix, normally its first eight digits, followed by a seven digit sequence that ascends within the batch. It has to be unique, and the entry detail sequence numbers must be in ascending order.
5. Calculate the control totals. The batch control record needs the entry and addenda count, the entry hash, the total debit amount, and the total credit amount. The entry hash is the sum of the eight digit routing fields of every entry in the batch, keeping only the rightmost ten digits if the sum overflows. The file control record repeats the same figures for the whole file plus the batch count and the block count.
6. Block the file. Count your lines. If the total is not a multiple of ten, append lines of 94 nines until it is. Files that are not blocked to ten get rejected on receipt.
7. Export as text. Copy the finished lines into a single column, save the sheet as Text (Tab delimited) or Formatted Text (Space delimited), then open the result in a plain text editor and confirm there are no stray tabs, no quotation marks, and no trailing spaces beyond position 94.

The fields people get wrong

Four errors account for most rejected files built in a spreadsheet.

• The amount. There is no decimal point anywhere in an ACH file. Writing 123.45 instead of 0000012345 makes the line the wrong length and the amount unreadable.
• The entry hash. It is not a checksum of the file, it is the sum of the routing number fields. If it does not match the entries, the batch fails validation even though every payment in it is correct.
• The effective entry date. It is a six digit YYMMDD banking day, and it must respect your bank's cutoff. A date that has already passed or falls on a weekend gets the batch reprocessed or rejected.
• The company entry description. As of March 20, 2026, Nacha requires PAYROLL in that field on PPD credits paying wages or salaries, and PURCHASE on WEB debits for ecommerce purchases. It is no longer free text for those entry types.

When Excel is the wrong tool

A spreadsheet origination process works when the payment list is short, stable, and reviewed by someone who understands the layout. It stops working quickly. Excel gives you no schema validation, no duplicate detection, no audit trail of who changed an account number, and no protection against the file being edited between approval and upload. Since an ACH file contains live routing and account numbers and moves real money, that last point is the one your auditor will ask about.

Practical alternatives, roughly in order of how many businesses use them: originate through your bank's cash management portal, which builds and validates the file for you; let your payroll or accounting system generate it, which most can; or move to accounts payable software that handles approvals and payment file generation together. Teams paying more than a handful of vendors a month usually find that automating the payables approval and payment run removes the spreadsheet step entirely, along with the risk that comes with it.

Whichever route you take, your bank has to approve you as an originator first. Expect an ACH origination agreement, exposure limits, and a test file before you are allowed to send anything live.

Reading a NACHA file is the more common job

Most people searching for NACHA and Excel in the same sentence do not want to create a file. They have received one and need to check it. That is the opposite problem, and it is much easier to solve. A received ACH file opens in Excel as one long column because there are no delimiters, the amounts are off by a factor of 100, and the leading zeros in the routing and account numbers disappear on import.

The NACHA file to Excel converter handles that directly: upload the file and every type 6 entry becomes a row with its transaction code, routing number, account, amount, name, and trace number, with the batch company and effective date carried down from the batch header. If you would rather do it by hand, our walkthrough on how to open a NACHA ACH file in Excel or convert it to CSV covers the fixed width import and the Power Query route.

Frequently asked questions

Can Excel create a NACHA file?

Excel can assemble the 94 character lines using concatenation and padding formulas, and you save the result as a plain text file. It cannot validate the file, calculate the entry hash for you, or confirm your bank will accept it. Treat Excel as a text builder, not as an ACH tool.

What is the NACHA file format in Excel terms?

It is a fixed width layout: six record types, each exactly 94 characters, with fields at defined positions. In a spreadsheet you model it as one column per field with a fixed width, then concatenate the columns into a single 94 character string per row. There are no commas, tabs, or delimiters of any kind.

How do I calculate the entry hash?

Sum the eight digit receiving routing number field, positions 4 to 11, of every entry detail record in the batch. If the total is longer than ten digits, keep the rightmost ten. The batch control record carries the batch total and the file control record carries the sum across all batches.

Why do I need 9-filler lines at the end?

ACH files use a blocking factor of 10, so the total number of lines must be a multiple of ten. After the file control record, add lines of 94 nines until the count divides evenly. Without them the receiving system reads the file as truncated.

Do I need my bank's permission to send an ACH file?

Yes. You need an ACH origination agreement with your bank, agreed exposure limits, and normally a successful test file before live processing. Banks also apply their own file specifications on top of the Nacha rules, so ask for their spec sheet before you build anything.

What is the difference between a NACHA file and an ACH file?

Nothing practical. ACH is the payment network, Nacha is the association whose operating rules define the file format used on it. People use NACHA file, ACH file, and NACHA formatted file interchangeably for the same 94 character fixed width payment file.