What Is the Effective Entry Date in an ACH File?
Jul 21, 2026
Convert your bank statement to Excel now
PDF, JPG, PNG, BMP, HEIC, TIFF, MT940
Upload your bank statement
Drop file here or click to upload
PDF, JPG, PNG, BMP, HEIC, TIFF, MT940
Uploading...
Last updated July 2026.
The effective entry date in an ACH file is the date on which the originator intends the entry to settle. It sits at positions 70 to 75 of the batch header record, written as YYMMDD. It is a request, not a guarantee: the ACH operator assigns the actual settlement date, and the receiving bank is entitled to rely on that settlement date regardless of what the effective entry date says.
Nearly every question people have about ACH timing comes back to that distinction. You control one date. The network controls the other. Payroll landing a day late is almost always a story about the gap between them.
Effective entry date vs settlement date
| Effective entry date | Settlement date | |
|---|---|---|
| Who sets it | You, the originator | The ACH operator |
| Where it lives | Batch header, positions 70-75, YYMMDD | Batch header, positions 76-78, Julian day |
| What it means | The date you want the money to move | The date the money actually moves |
| When it is written | When you build the file | Inserted by the operator after you send it |
That Julian settlement date field is worth knowing about, because it is the field that answers what actually happened. It is blank in the file you build and populated in the file that comes back, which is a fast way to tell an originated file from a returned one. The rest of the batch header, field by field, is on the NACHA file format reference.
What happens if the effective entry date is in the past?
The entry does not fail. It gets processed at the earliest opportunity instead. Under the Nacha rules, an entry with a stale or invalid effective entry date is still eligible for same day processing if the ODFI transmits it by the operator's same day deadline and it otherwise qualifies. In other words, a date in the past does not stop the payment, it removes your control over when it lands.
This is a real problem for payroll. A file built on Friday for a Monday effective date, then held and transmitted on Tuesday, will not sit and wait for the following Monday. It goes as soon as it arrives, and employees see money on a day nobody planned for. The fix is procedural rather than technical: rebuild the file if the transmission slips, rather than sending yesterday's file today.
How far in the future can the effective entry date be?
Banks generally accept an effective entry date a few banking days out, and most ODFIs publish their own window, commonly somewhere between one and thirty days depending on the institution and the SEC code. Warehousing a file well in advance is normal for payroll. What matters is that the date has to be a banking day: weekends and federal holidays are not settlement days, so an effective entry date of Saturday settles on the following business day instead.
Two consequences follow from that, and both cause support calls every quarter. A payday falling on a holiday needs the file dated to the prior banking day if you want the money there before the holiday. And the credit needs to be transmitted early enough that its normal one to two banking day processing window still lands on the date you want, which is a separate question from what you typed into the date field.
Same day ACH and the effective entry date
A same day entry is one where the effective entry date is the same banking day the ODFI transmits it to the ACH operator, and it is transmitted by the operator's same day deadline. There are several settlement windows through the day, each with its own cutoff.
The dollar limit changed recently and it is worth knowing the current figure. Effective January 1, 2026, the per entry limit for same day ACH rose from $1 million to $10 million. If your treasury policy or your software still enforces a million dollar ceiling on same day entries, that is now a self imposed limit rather than a network one.
The practical catch with same day is that the cutoff is your bank's, not the network's. ODFIs set their own deadlines ahead of the operator windows to leave themselves processing time, so the useful number is the one on your bank's treasury schedule rather than the published operator cutoff.
Where does the effective entry date sit in the file?
Positions 70 to 75 of the batch header, the type 5 record. Six characters, YYMMDD, no separators. It applies to the whole batch, which is the single most useful thing to understand about it: every entry inside a batch shares one effective entry date.
So if you are paying forty vendors and eight of them are on different terms, you cannot give them different dates inside one batch. You build separate batches, each with its own type 5 header carrying its own date, and each closed by its own batch control record. A file with four different payment dates has four batches in it. That is why real vendor files carry more batches than people expect, and why a batch count of one in the file control record is a hint that somebody flattened dates they should not have. Teams running that kind of split across dozens of suppliers every week usually end up letting accounts payable automation group the payment runs by due date instead of maintaining the batching by hand.
Does the effective entry date decide which bank statement the payment appears on?
No. The settlement date does. Your statement shows activity by the date the bank posted it, so a payment with an effective entry date of the 31st that settles on the 1st falls into the next statement period, and no amount of correspondence changes that.
This is the single most common source of month end confusion in ACH reconciliation. The accrual sits in the old month because that is the date you intended, and the cash moves in the new month because that is when it settled. Both are correct. The reconciliation just has to carry the item as in transit. Matching a whole batch against the statement is covered in reconciling an ACH file against your bank statement, and the wider point that a batch usually lands as one summarized statement line rather than one line per payment is worth reading before you start.
What about the company descriptive date next to it?
Positions 64 to 69, immediately before the effective entry date, hold the company descriptive date. It is free text for the originator's own purposes and it has no effect on when anything settles. Payroll originators often put the pay period end date there so it shows up as a reference. Nothing in the network reads it.
Confusing the two fields is easy because they sit side by side in the same YYMMDD shape. If your payments are settling on the wrong day and the effective entry date looks right, check that the two values were not swapped when the file was generated. The companion field on the other side, the company entry description, has its own conventions and they are covered in what to put in the NACHA company entry description.
Quick reference
| Question | Answer |
|---|---|
| Format | YYMMDD, six characters, no separators |
| Position | Batch header (type 5), positions 70-75 |
| Scope | The entire batch, not the individual entry |
| Must be | A banking day, or it moves to the next one |
| If in the past | Processed at the earliest opportunity, potentially same day |
| Decides statement period | No, the settlement date does |
If you are working from an ACH file and need these fields as columns rather than character offsets, the NACHA file to Excel converter reads each record type on its own layout, and the full record layout reference documents every field position in the file.
Ready to convert your bank statement?
Upload a PDF and get clean Excel or CSV in seconds. Works with statements from any bank.
Convert to Excel nowFree to try, no credit card required