Making NACHAs: Part II
When we last met, we took a first glance at the NACHA file format and discussed a few terms that you'll see in NACHA file specifications. In this installment, we'll be diving into creating the file by looking into the first record of the file: the file header.
Standard NACHA files are composed of a series of fixed-length 94-byte records where the first character of each record defines the type of record. To recap, these types are:
- 1: File header
- 5: Batch header
- 6: Detail
- 7: Addenda
- 8: Batch footer
- 9: File footer
Each record has a very specific format. But as you'll see shortly the format supports a wide variety of financial situations. Each file can contain up to one million batches, though some receivers may impose smaller limits. Also be aware that banks may charge based on the number of files and/or batches you send, so you'll want to know those details when planning your implementation strategy.
The type 1 (file header) record is basically an envelope that defines you and your trading partner. Note that I didn't say "sender" and receiver" because you may be sending and receiving money in the same file. Instead, your trading partner is the person to whom you will submit your file, or from whom you will receive a file. By reading this first record a recipient can identify the sender and also verify that they are the proper recipient.
The first three characters of the type 1 record are always '101'. The first '1' signifies the record type of being a file header, and the subsequent '01' is called the "priority code". Maybe there are other values for priority code, but every NACHA file I've ever built requires this to be '01'.
Following the priority code is a field known as the "immediate destination". This is the ABA# (routing/transit number) for either you (as a recipient) or the external financial institution (if you are the sender). This is commonly retrieved from a file that holds details for a specific bank account. This field is right-justified in a field of 10 spaces.
Next is the "immediate origin". As the sender, this represents your account number with the destination. As the receiver, it represents the sender's account number with your organization. This field is right-justified in a field of 10 zeroes. (Actually, in every NACHA file I've created, this value is always exactly 10 characters so the fill character hardly matters in that situation.)
After these fields comes the date and time. The date is a six digit field with two digits for year, two digits for month, and two digits for day. The time is a four digit field with two digits for hour (on a 24-hour clock) and two digits for the minute.
Next is the 1-character "file modifier". If you send multiple files per day, the first file should be sent with a '0' in this field. Subsequent files should increment this by 1. You may only use 0-9, and A-Z in this field, yielding a maximum of thrity-six files per day. Considering that some financial institutions charge based on the number of files received, you'll probably want to restrict yourself to only one per day unless absolutely necessary due to high transaction volume.
The next field is the record length, 3 digits, right-justified in a field of spaces, and ALWAYS sent as '094'. This says that every record in the file must be exactly ninety-four characters long. I always found it interesting that the record length for the file is embedded in the first record. Even more unusual, it's near the middle of the record so to know how many characters there are in a block, you have to … read a block. (Maybe this is why the NACHA format has never had an upgrade?)
Following the record length is the block size. Theoretically this defines the number of records that the ACH processor will read in at a time. In my experience, this is always '10'. What makes this unusual is that in the final analysis, your file will need to have enough rows so that the count of rows in your file divided by the blocking factor must be zero. In other words, with a blocking factor of 10, if you have 1 actual transaction, your file must have at least 10 total records. The next legal size is 20 records, 30 records, and so on. Filler blocks — to be discussed later — are used for padding the file to fit the block size.
I cannot stress this enough; with a block size of 10, you will not be allowed to send a 36 record file. It must be rounded to 40. But again, these are issues that are addressed later at the end of the file.
The next field is called a "format code" and I've never seen anything other than '1' here.
Following the format code is the name of the financial institution processing your file. This one has regularly given me fits. When transmitting a file to a bank, you might think you could just put the bank name here in this twenty-three character, space-filled, left-justified field. For some, that's okay. For others, however, the bank will prescribe EXACTLY what you are to put here and will reject your entire file if the value is not exactly what they require.
Making this even more strange, following this field is a field for your company name. This field, like the former, is twenty-three characters in length, space-filled, and left-justified. To date, I've never known a financial institution that cared a lick about what is included here.
The final eight characters of this 94 byte block is called a reference code. If you want to put a batch number or something here for your purposes (as the sender), go for it. Your trading partner is instructed to ignore this value. If you don't have anything to put here, fill the eight characters with spaces.
At first glance, this looks very straightforward. In fact, at this point the file is very pedestrian. As we get into the next records, you'll see things begin to grow in complexity. Also consider that this is just a rough overview of the file format; while NACHA is a standard, you should always consult the documentation from your trading partner for specifics that they may require.
