The ACH company ID, in Nacha's terms the Company Identification, is a ten-character field in every batch header of an ACH file that identifies the originator of the payments in that batch; Nacha's developer guide says it is "used to identify the Originator" and "assigned by the ODFI", the originating bank. It matters far beyond the file because other systems recognize the originator by it: receiving businesses' debit blocks and ACH positive pay filters, the originating bank's own monitoring, and in some cases the Federal Reserve's. The difficulty in treasury onboarding is that a client moving banks brings the old bank's ID with it, set in its accounting software and registered in its counterparties' filters. Botminds' Treasury Management Onboarding compares the ID in every test file with the one on the client's signed origination agreement, and explains a mismatch to the client in plain words.
The example is a fictional sample client, Halvorsen Freight Systems, whose first test file to a fictional bank carried its previous bank's company ID. The file layout comes from Nacha, the non-profit that writes the ACH rules; the filters from public pages of the Federal Reserve Banks and two state tax departments.
What does ACH company ID mean?
The ACH company ID is the originator's identifier in the ACH network: a value the originating bank assigns so that each batch can be tied to one originator. Every payment in a batch shares it, because "all payments within a single batch represent transactions for a single company or originator" (Nacha, ACH File Overview). The company name travels beside it, defined as the "name of the Originator known and recognized by the Receiver."
Three features of the field explain most of the trouble it causes. It is alphanumeric, ten characters, so it can hold digits, letters and spaces. It is assigned by the bank, so it belongs to the banking relationship as much as to the company. And one company can hold several, one per line of business, account or payment type, which is why searches for "ach company id lookup" so rarely end in a single answer.
Where the company ID sits in a Nacha file
The company ID appears in at least two records per batch and often a third: the batch header, the batch control record that closes the batch, and, at many banks, the file header. Nacha's guide notes that for the file header's Immediate Origin field, "Often your ODFI will have you insert your company ID in this field."
Three places the company ID appears in one ACH file
| Record | Field and positions | What Nacha says it holds | In the sample's first test file |
|---|---|---|---|
| File header (type 1) | Immediate Origin, positions 14–23 | The sending institution's routing number, though "often your ODFI will have you insert your company ID" | 1742900183, the previous bank's value |
| Batch header (type 5) | Company Identification, positions 41–50 | "Used to identify the Originator. Assigned by the ODFI." | 1742900183 in both batch headers |
| Batch control (type 8) | Company Identification, positions 45–54 | "Contains the value of the Company Identification field 5 in the Company/Batch Header record." | Repeats the header |
The batch header also explains why the ID splits batches. Nacha's guide says entries are batched together where "the Standard Entry Class (SEC) Code, effective entry date, company ID, and Batch descriptor are identical", and that a different company ID "would call for a separate batch" (Nacha, ACH File Overview). A client with two IDs, say one for payroll and one for collections, will always produce at least two batches.
The client's file, with the company ID marked where it failed
Company ID for ACH debit block and ACH positive pay
A debit block or ACH positive pay filter on a business account lets ACH debits through only from originators the account holder has authorized, and the authorization is written in company IDs. The FFIEC's 2021 authentication guidance counts positive pay and debit blocks among the tools banks offer business customers to watch and control activity on their accounts (FFIEC, Authentication and Access, 2021); how positive pay works follows an ACH exception from the filter to the client's decision. Government payees publish their IDs so that taxpayers can authorize them.
If you don't provide the ACH company ID and name, your bank may reject the payment and the Tax Department may send you a bill for the amount due, including penalty and interest.
New York State Department of Taxation and Finance, ACH debit block information
New Jersey's Division of Revenue gives the same instruction in fewer words: "add the ACH Company ID as an exception to the bank account debit block filter. The ID for ACH is 7216000928" (New Jersey Treasury, EFT payments). New York's chart shows how varied the values are: one department uses "E146013200" for bill payments and "146013200E", "146013200F" and others for individual taxes, the same digits with a letter moved or changed.
That has two consequences for a treasury implementation, one on each side of the client's accounts. As an originator of debits, the client's new company ID must be recognized by the filters of every business it collects from. As a receiver, the client's own debit block at the new bank must be rebuilt with every originator it pays by debit, the tax departments first among them.
What the bank's own monitoring keys on
The originating bank recognizes clients by company ID too, sometimes through the Federal Reserve. The FedACH Risk Origination Monitoring Service lets an ODFI set "cumulative debit and credit caps (processing limits) by RTN and/or Company IDs." Under one option, the service "will pend all batches containing Company IDs not defined by the ODFI", and the match is strict: "The defined Company ID(s) must match exactly to the Company ID(s) in a batch's header record. This includes leading and trailing spaces and upper/lower case sensitivity" (Federal Reserve Financial Services, FedACH Risk Origination Monitoring).
A bank's own file intake can apply the same test without FedACH: the company ID is how an incoming file is tied to the client's origination agreement and exposure limit, so a value the bank never assigned has nothing to attach to. The sample bank rejects a file whole when the ID does not match the agreement. A carried-over ID is therefore not cosmetic. It can stop a payroll.
Five places a company ID is read after the client presses send
| Where | Who reads it | What a wrong ID does |
|---|---|---|
| The client's accounting or payroll software | Builds the file from its ACH profile | Writes the old bank's ID into every batch until someone changes the profile |
| The bank's file intake | Ties the file to the client's agreement and limit | At the sample bank, rejects the file whole |
| Origination monitoring | The bank, or FedACH Risk for subscribing banks | An undefined ID can pend the batch under the "pend all" option |
| The receiver's debit block or ACH positive pay | The receiving business's bank | An unrecognized originator's debit may be rejected |
| The receiver's statement and reconciliation | The receiving business | An unfamiliar ID and name raise questions and calls |
Can a business use the same company ID at a new bank?
Sometimes, but it is the new bank's decision, not the client's. Nacha's guide describes the company ID as "assigned by the ODFI", so the value a client used at its previous bank has no standing at the new one until the new bank assigns it. Whether a bank will reissue a client's existing value, or insists on its own numbering, is a matter of that bank's policy and systems; the public file guidance takes no position.
Keeping the old value has an obvious appeal: the receivers' filters and the client's software need no change. Assigning a new one has the advantage of a clean break, and it makes the cutover visible. Either way, the onboarding question is the same, and it belongs in the setup review rather than in the first failed file: which IDs does the client use today, for what, and which value will each carry at the new bank?
Why did my ACH debits get blocked after switching banks?
ACH debits that worked at the old bank and are blocked after a switch have often met a filter that still lists the old company ID or name. The filters belong to the payers' banks, so the bank originating the debits cannot see them; it can only ask. When the company ID changes, every trading partner or customer that has authorized the client's debits by ID has to update its filter, exactly as New York tells taxpayers to give their bank its IDs.
The mirror image is easier to prevent. A client that moves its operating account brings no filter with it: its debit block at the new bank starts empty or closed. The list of originators it authorizes, from tax departments to equipment lessors, has to be rebuilt before the first debit arrives. That list is part of the treasury management checklist before go-live for any client taking ACH positive pay.
Is the ACH company ID the IRS number?
Not necessarily, and it cannot be derived from one. Nacha's public guide defines the field only as ten alphanumeric characters assigned by the ODFI. Values vary widely: New York's are one nine-digit string with a letter added at the front or the end, while New Jersey's revenue ID, 7216000928, is a plain ten-digit number. The reliable way to find an originator's company ID is to ask the originator, or to read it from a debit it has already sent, not to construct it from a tax number.
For the client's own ID the answer is simpler. It is on the ACH origination agreement or schedule the client signed, because the bank assigned it there. In the sample, page 2 of the ACH Origination Schedule gives 1000045512; the client's file said 1742900183.
The cutover list: old bank against new
The fix for a carried-over company ID is not a resend; it is a list, worked through before the first live file. Each line has an owner, and most of the owners are outside the bank.
What the client used at the old bank, and what has to change at the new one
At the old bank: The old bank's value, set in the ACH profile.
At the new bank, before the first live file: The value on the signed schedule, in the file header where the bank asks, both batch headers and every batch control.
At the old bank: Perhaps one for payroll, one for vendor payments, one for collections.
At the new bank, before the first live file: Each mapped to a new value, or confirmed as reissued, line by line.
At the old bank: Customers and partners authorized the old ID for the client's debits.
At the new bank, before the first live file: Each told the new ID and name, with a date, before debits move.
At the old bank: A list of authorized originators at the old bank.
At the new bank, before the first live file: Rebuilt at the new bank, starting with tax departments' published IDs.
At the old bank: The name receivers recognize on their statements.
At the new bank, before the first live file: Kept the same where possible, so receivers recognize the payer.
How Treasury Management Onboarding catches a carried-over ID
In Treasury Management Onboarding, the Setup agent drafts the company identification from the signed ACH Origination Schedule and cites the page; the File agent compares the ID in every test file, in every place it appears, with that value. In the sample, the first test file of 212 payments for $412,860.00 carried 1742900183 in the file header and both batch headers where the agreement says 1000045512. The agent marked all three places on the records, and the same file carried a second error, a vendor batch coded PPD instead of CCD.
Every setup field drafted from the signed schedules, with the page it came from
The Client agent then drafted the controller one instruction to act on: open the ACH profile in the accounting system and change the Company ID to 1000045512. A specialist sent it at 10:38 under their own name, the corrected file arrived at 11:40, and it passed at 11:52. The agents never edit a client's file; they say what to change and where. Why that distinction matters is set out in the guide to Nacha file validation tools, and the solution is at Treasury Management Onboarding.
Questions people ask
Where do I find my ACH company ID?
On the ACH origination agreement or schedule your bank gave you, since the bank assigns it, and in your accounting or payroll software's ACH settings. In the file itself it sits in positions 41 to 50 of each batch header.
Is there an ACH company ID lookup?
There is no public directory in the Nacha guidance. Some payees, such as state tax departments, publish the IDs they debit under; New Jersey's revenue ID is 7216000928. Otherwise the originator is the source, or a debit it has already sent.
What is the company ID for ACH positive pay?
It is the originator's company ID, the same ten-character value from its batch headers. ACH positive pay and debit block filters let a business authorize debits from specific originators by that ID, so a payee's ID and name must be given to the business's own bank before the first debit.
Can one company have more than one ACH company ID?
Yes. New York's tax department uses a different ID for bills and for each type of tax, built from the same digits with letters added. A business may likewise hold separate IDs for payroll, vendor payments and collections, and each must be mapped when it changes banks.
What happens if the company ID in my file is wrong?
It depends on where it is caught. The originating bank may reject or hold the file because the ID does not match the client's agreement, a monitoring service may pend the batch, or a receiver's debit block may refuse the debits. In testing, it costs one message and a resend.