NACHA File Format: How the ACH File AP Sends to the Bank Is Built

The NACHA file format is the fixed-width text layout banks accept for ACH payments. Each line is exactly 94 characters long, and the records inside tell the bank who to pay, how much, and when.

Most AP teams meet the format indirectly. The ERP runs a payment batch, exports a file, and someone uploads it to the bank portal. Nobody thinks about the layout until the bank rejects a file on payment day and the person who built the export has moved on. Underneath the format question sits a control question that matters more. A payment file on a shared drive is plain text, and plain text can be edited after the payments in it were approved.

Key Takeaways

• A NACHA file is a fixed-width ASCII file in which every line, or record, is exactly 94 characters long.

• Every file follows the same record structure, from file header to batch header, entry detail, optional addenda, batch control, and file control.

• Vendor payments usually travel as CCD or CCD+ entries, or as CTX entries when the payment carries detailed remittance data.

• Banks reject files most often for broken control totals, bad record lengths, wrong dates, and company IDs the bank doesn't recognize.

• A payment file that sits outside the approval trail is a fraud risk, which is a strong reason to stop building files by hand.

What is a NACHA file?

A NACHA file is the text file a company sends to its bank to originate ACH payments, laid out in the format the Nacha Operating Rules specify. The bank reads it, combines it with other customers' files, and sends the entries into the ACH Network for settlement.

The name comes from Nacha, the organization that writes the rules governing the ACH Network. You'll also hear the same thing called an ACH file. For AP, the file usually holds ACH credits, meaning payments pushed out to vendors, though the same format carries ACH debits pulled from other accounts.

The file doesn't go straight into the network. Your bank, known in the rules as the originating depository financial institution or ODFI, receives it first. Nacha's developer guide explains that banks process customer files "to create larger ACH files to be sent to the ACH Network that contain many originators' batches." That's why your file has to meet both Nacha's structure and your bank's own intake requirements, and why the bank, not the network, is usually the one that rejects it.

The format matters because of the volume riding on it. According to Nacha's ACH Payments Fact Sheet, the ACH Network carried 35.2 billion payments worth $93 trillion in 2025, including 8.1 billion B2B payments, up 9.9% from 2024.

What is the difference between ACH and NACHA?

ACH is the payment network, and Nacha writes the rules for it. ACH stands for Automated Clearing House, and the term describes both the network and the payments that travel through it. Nacha is the rule-making body, and the NACHA file format is one of the things its rules define.

So when a bank asks for a "NACHA file," it means a file built to Nacha's specification. When it talks about "ACH payments," it means the payments themselves. If you want the plain-English version of how those payments move, the guide to what an ACH payment is covers the basics.

What does a NACHA file look like?

A NACHA file is a stack of 94-character text lines, each starting with a single digit that identifies the record type. Nacha's ACH Developer Guide describes it as "a fixed-width, ASCII file, with each line exactly 94 characters in length."

Each line is called a record, and each record is divided into fields at fixed positions. The records always appear in the same order, which is why a single misplaced character can break the whole file.

Record structure from Nacha's ACH Developer Guide.

A file can hold many batches. Nacha's guide notes that any change in the batch header information, such as a different description, effective date, or company ID, calls for a separate batch. The guide also says "ACH files have a blocking factor of 10," and files are padded with lines of 9s until the line count is a multiple of 10.

Read top to bottom, a simple file with one batch of two vendor payments runs in this order:

1. One file header line beginning "101," followed by the bank's routing number, the date, and the time.

2. One batch header line beginning "5," naming your company, the CCD code, a description such as "vendor pay," and the effective date.

3. Two entry detail lines beginning "6," one for each vendor, carrying the routing number, account number, amount, and vendor name.

4. One batch control line beginning "8," with the entry count, the hash total, and the debit and credit totals.

5. One file control line beginning "9," with the same kinds of totals for the whole file.

6. Enough padding lines of 9s to bring the line count up to 10.

That's ten lines, each exactly 94 characters, to move two payments. Real files simply repeat the pattern with more entries and more batches.

Which SEC codes do vendor payments use?

Vendor payments almost always use CCD, CCD+, or CTX. The Standard Entry Class code sits in the batch header and tells every bank in the chain what kind of payment the batch holds and what authorization stands behind it.

These are the codes AP is most likely to see.

• CCD and CCD+ cover most vendor payments. Nacha's guide defines CCD as "a single or a recurring ACH credit or debit originated to a corporate account." A CCD+ entry adds one addenda record for remittance information.

• CTX, or Corporate Trade Exchange, entries also go to corporate accounts, but they support up to 9,999 addenda records, which suits payments that settle many invoices at once.

• PPD entries go to consumer accounts, such as payroll direct deposit.

• WEB and TEL entries are consumer debits authorized over the internet or a wireless network, or by phone.

• ARC, BOC, and POP codes convert an eligible paper check into an ACH debit.

A vendor that receives one CCD payment covering dozens of invoices with no remittance detail will call AP to ask what it covers. CTX, or CCD+ with a clear addenda record, saves that call and speeds up payment reconciliation on both sides.

Where does a prenote fit in the file?

A prenote is a zero-dollar entry detail record sent ahead of the first live payment to a new account. It sits in a batch like any other entry, with the same account details the live payment will carry, and confirms the account number is valid and open.

Nacha's developer guide states, "It is recommended that pre-notifications are sent at least three business days prior to initiating a live authorized Entry." It also recommends a new prenote whenever an account number changes. A prenote doesn't confirm who owns the account, which is why vendor verification and bank validation still matter.

Protect cash flow with modern AP

Modernize AP to cut costs, speed approvals, and mitigate payment risk — gaining the real-time visibility to protect cash flow and scale with confidence.

Download the whitepaper

How do you create a NACHA file?

Most companies create NACHA files by exporting them from an ERP or accounting system's payment run. Others build them in a bank portal, in dedicated file-building software, or in a spreadsheet. Some never build one, because a payments provider handles the bank side for them.

Four routes cover most companies.

1. With an ERP payment-run export, AP approves invoices, runs a payment batch, and the system writes the file. Most mid-market ERPs can do this, though setup usually needs the bank's specific requirements for the file header.

2. With a bank portal template, AP keys payments into the bank's online platform, which produces the file behind the scenes. That works for low volume and becomes tedious quickly.

3. Standalone file-building software converts a spreadsheet or ERP report into a formatted file. They fix the formatting problem without fixing the control problem.

4. With a payments provider, AP sends approved invoices or payment instructions, and the provider pays the vendor by the right method. No one on the team handles a file.

Nacha's guide also points out that banks can have their own formatting requirements, often in the file header. That's why a file that worked at one bank may fail at another, and why "the format" is a standard with local variations. Corpay's ERP integrations include NetSuite and Sage Intacct, so payment instructions come from approved bills rather than a hand-built file.

Can you create a NACHA file in Excel?

Yes, you can build a NACHA file in Excel, but it's a poor control. A spreadsheet that produces a payment file puts vendor account numbers and amounts in an editable document outside the system where payments were approved.

The mechanics aren't the hard part. A formula can pad fields to fixed widths and a macro can export text. The problem is what happens between approval and upload. Anyone with access to the spreadsheet or the exported file can change an account number, add a payment, or adjust an amount, and nothing in the ERP will show it. The bank sees a correctly formatted file and pays it.

If a spreadsheet build is unavoidable for now, a few safeguards reduce the exposure:

• Lock the file location so only the person uploading can open it.

• Compare file totals to the approved payment batch before upload, with a second person signing off.

• Pull vendor bank details only from the vendor master, never from a pasted list.

• Keep each uploaded file and the approval record together for audit.

Those steps are basic segregation of duties in AP. They help, but they rely on people following them every payment run.

Why does the bank reject a NACHA file?

Banks usually reject NACHA files for structural errors, such as wrong record lengths, control totals that don't add up, invalid dates, or a company ID the bank doesn't recognize. Most rejects trace back to a change in the export, the bank's requirements, or a manual edit.

The rejects below are the ones AP teams run into most, each with its usual fix.

• Record length errors come from a line that isn't exactly 94 characters, often because a vendor name or field ran long or a trailing space got trimmed when someone opened and saved the file in a text editor or spreadsheet. Regenerate the file from the source rather than repairing it by hand.

• Control totals and hash mismatches are next. The batch control and file control records carry entry counts, dollar totals, and a hash total built from the receiving routing numbers. If anyone added, removed, or changed an entry without updating the totals, the file fails. That's a useful alarm, since it can mean someone edited the file after export.

• Effective date problems come from a date in the past, a weekend or holiday, or a date outside the bank's processing window. Check the payment run's date logic and the bank's cutoff times.

• Company ID errors come from a company identification number that doesn't match what the bank has on file, common after a bank change or ERP migration. Confirm the value with the bank and update the export template.

• Blocking errors mean a line count that isn't a multiple of 10 because padding lines are missing. Most exports handle this automatically, so a blocking error usually means the file was edited.

• Bank-specific header problems mean a file header that doesn't match the bank's spec. Get the bank's current requirements in writing and test any template change with a small file first.

A pattern runs through that list. Most rejects come from someone touching the file between export and upload, and every one of those touches is also a chance for an unauthorized change. A file that fails the bank's checks is annoying. A file that someone edited carefully enough to pass them is far worse, because it goes through.

What happens after the bank accepts the file?

Acceptance means the file passed the bank's format checks, not that every payment landed. Individual entries can still come back as returns, such as for a closed or invalid account, or as notifications of change asking you to update an account detail. Those arrive after the file has been processed, often a day or more later.

Someone has to own that loop. Returns need the vendor contacted at a known phone number and corrected details verified before the payment goes out again. Notifications of change need the vendor master updated so the next file carries the right data. When returns and change notices land in a shared inbox, they're easy to miss, and the same vendor fails on the next run.

Who should be able to touch the file?

Decide four things in writing before any file goes to the bank:

1. Who generates the file, ideally a system rather than a person.

2. Who, if anyone, can open or edit it after export.

3. How it reaches the bank, whether by automated transfer or by someone uploading it.

4. Who receives returns and change notices, and who updates vendor records.

If one person can do all four, the file is a single point of failure.

When should AP stop building NACHA files?

AP should stop building NACHA files when the volume of payments, the number of people touching the file, or the fraud risk outgrows the controls around it. For most mid-market teams, that point comes earlier than they expect.

ACH is now the main way businesses pay each other. The Federal Reserve Bank of Cleveland's September 2026 brief on B2B payments found checks fell from 32% of B2B payments by number in 2015 to 13% in 2024, while ACH rose from 25% to 41%. More ACH payments means more files, more vendor bank details, and more chances to divert a payment.

Fraud pressure is rising at the same time. AFP's 2026 Payments Fraud and Control Survey Report found 76% of U.S. organizations experienced attempted or actual payments fraud in 2025, and 74% were affected by business email compromise. Nacha's fraud-monitoring rules now reach all non-consumer originators. Phase 2, with a rule date of June 19, 2026, which fell on a federal holiday, so June 22 in practice, applies "regardless of origination or transmission volume," according to Nacha's Phase 2 fraud monitoring page. The rules call for processes to spot entries "authorized under False Pretenses," which includes vendor impersonation and business email compromise.

Watch for these signs that file building has outgrown your controls:

• More than one person regularly opens or edits payment files before upload.

• Bank rejects happen often enough that fixing files by hand feels routine.

• Vendor bank changes arrive by email and get entered by the same person who runs payments.

• Nobody on the team can read a rejected record and explain what went wrong.

• Moving to a new ERP or a new bank would mean rebuilding the export from scratch.

Manual work is a big part of why these risks persist. Yooz's 2025 Leaders vs. Ledger survey of 600 U.S. finance professionals found the share naming manual data entry as a barrier rose from 57% to 63% year over year. According to The Hackett Group's 2025 Digital World Class Matrix for Accounts Payable, the 15 AP providers it evaluated averaged 60% touchless invoice processing, and companies where at least three in ten invoices were touchless averaged 3.5 times higher AP productivity. Removing the payment file from AP's hands is one of the simplest ways to cut manual touches. Corpay's fully managed AP pays vendors by virtual card, ACH, or check from one approval flow, with no file for AP to build.

How Corpay pays vendors without file builds

With Corpay's fully managed AP, your team doesn't build, edit, or upload NACHA files. Approved invoices flow from your ERP, and Corpay pays each supplier by virtual card, ACH, or check, so payments never sit in an editable file between approval and the bank.

Corpay payments automation handles supplier enrollment, payment method, and remittance as part of the service. Card payments use single-use virtual cards, and Corpay returns more than $800M in rebates to customers each year. Customers see about 40% time saved on AP work.

Corpay connects through 100+ ERP integrations, including NetSuite, Sage Intacct, Business Central, and Acumatica, so there's no custom export to maintain when a bank's requirements change. If you run NetSuite or Business Central, the guides to NetSuite AP automation and Business Central AP automation show how the connection works. Most customers are live in weeks.

Frequently Asked Questions

What does NACHA stand for?

NACHA is the name of the organization that governs the ACH Network, which today writes its name as Nacha. In payments, "NACHA" most often refers to the file format its rules define, the one banks accept for ACH payments.

How long is each record in a NACHA file?

Every record in a NACHA file is exactly 94 characters long. Files also follow a blocking factor of 10, so they're padded with lines of 9s until the total line count is a multiple of 10.

Can QuickBooks or NetSuite create a NACHA file?

Many ERP and accounting systems can export a NACHA file from a payment run, though the capability often depends on your edition, add-ons, and setup. Check with your system provider and your bank, since banks often have their own header requirements.

Does every bank use the same NACHA format?

Every bank works from the same Nacha record structure, but many add their own requirements, usually in the file header. A file that works at one bank may need changes before another bank will accept it, so get each bank's specification before setting up an export.

David Luther

Product Marketing Program Manager

David Luther, MBA is a product marketing program manager with years of experience in commercial banking, finance, and technology sectors, with research and writing appearing in financial publications.

Payments Automation

AP Automation