How NACHA Files Work

The National Automated Clearing House Association (NACHA) manages and governs the Automated Clearing House (ACH) network in the United States. To facilitate ACH transactions, they use NACHA files, which are specially formatted .txt files holding information about each transaction. These files are sent between financial institutions, who then move funds from one account to another.

Secure Payments specifically uses unbalanced NACHA files, which show one-way transactions from your customers.

Sample NACHA File

Here's a sample of a NACHA file.

101 12400297111234567892106222214A094101WELLS FARGO BANK NA    LendPro                 000000000
5225LendPro                             1123456789PPDPMT0001202210623210623    1124002970000000
6270311001607777666655554444 000001130019650921       Ron P. McKernan    0124002979650921
6271119042159874456798764567 000013585519650922       Bill Kreutzmann           0124002979650922
6273222700550000999988887777 000004560019650923       Robert Hunter             0124002979650923
6270214091698888777766667777 000013090019650924       Phil Lesh                 0124002979650924
6271250085474444333322221111 000013433419650925       Bob Weir              0124002979650925
6273222717791111222233334444 000011650019650926       Jerry Garcia          0124002979650926
822500000600744017820000005744890000000000001123456789                           124002970000000
9000001000001000000060074401782000000574489000000000000

At first glance it might seem like just a bunch of numbers, but with a closer look you'll notice the names your company, the bank you're sending the file to, and each of your customers. Each NACHA file has a two-line header with info about your company, the bank, and the file itself; a list of transactions with customer names; and a footer that totals the transactions and gives some additional info.

In this image, the different parts are highlighted. The two red lines at the top are the header, the yellow line is a single transaction record, and the two blue lines at the end are the footer.

The rest of this article explores what specific parts of the file indicate, but you won't need to manually input any of this information. Secure Payments will automatically create the NACHA file, pulling from your company settings, transactions, and payment profiles.

Header, Line 1

Let's break down the first line of the file.

Here's what each part means:

Field

Example

Description

First digit

1

A one shows that this row is the first line of the header

Priority Code

01

A two-digit number showing the processing priority.

Routing sNumber

124002971

The routing number for the bank you're sending this NACHA file to.

Company ID

1123456789

A ten-digit code indicating your company.

Date

210622

The date the file was batched on, YYMMDD. This date would be June 22, 2021.

Timestamp

2214

These four digits show the time when the file was batched, shown in 24-hour time. This time would be 10:14pm.

File Data

A094101

Info about the file itself.

  • File Modifier (A): f there are enough transactions that the system generates multiple NACHA files, it will use these numbers to distinguish them, starting with A and continuing in alphabetical order.
  • Record Size: (094): Number of characters in a line.
  • Blocking Factor (10): The NACHA file is 'blocked' in groups of ten lines, so the total number of lines in the file will be a multiple of ten. If the number of transactions doesn't square off neatly, the file will round up with a bunch of 9s at the end.
  • Format Code (1): This number will always be a 1.

Bank Name

WELLS FARGO BANK NA

The name of the bank you're sending the NACHA file to.

Company Name

LENDPRO

The name of your company. (Technically this is just the name of whoever is sending the NACHA file, but the files Secure Payments generates will always have your company here.)

Reference Code

00000000

This field is optional, and usually used for accounting purposes.

Header, Line 2

Here's what each part means:

Field

Example

Description

First digit

5

A five shows that this row is the second line of the header.

Service Class Code

225

Identifies the type of transactions in the file. 220 means credit only, 225 means debit only, and 200 means a mix.

Company Name

LendPro

Your company's name.

Company ID

1123456789

A ten-digit code indicating your company.

Entry Class

PPD

Shows the type of transactions in the file, such as PPD, CCD, CTX, WEB, TEL, etc.

Entry Description

PMT0001202

A description of the transactions in this file.

Descriptive Date

210623

The date the transactions took place, YYMMDD.

Effective Date

210623

The date when the transactions will be posted, YYMMDD.

Routing Number

12400297

The bank's routing number without the Check Digit (the last digit in the routing number).

Batch Number

0000000

The number of the batch in this file.

Transaction Records

Here's two transaction records so you can compare and contrast them:

And here's what each part means

Field

Example

Description

First Digit

6

A six indicates that this row is a transaction.

Transaction Code

27

Indicates the customer's account type. A 27 means you're pulling from a checking account; a 37 means you're pulling from a savings account.

Routing Number

125008547

322271779

The routing number for the bank, shown in the header and in each transaction line. Since the file is being sent to a single bank, this number will be the same on each transaction.

Account Number

4444333322221111

1111222233334444

The customer's account number with the bank. The number of digits can vary.

Amount

0000134334

0000116500

The amount of the transaction. The last two digits are cents, with the decimal implied. These two, for instance, are $1,343.34 and $1,165.00

ID Number

19650925

19650926

A number identifying the individual customer. This isn't the customer ID or display ID normally used in LMS or Secure Payments; the system generates this number when it creates a NACHA file.

Customer name

Bob Weir

Jerry Garcia

The customers' names.

Addenda Record Indicator

0

If there is no addenda (plural for addendum) accompanying this transaction, it will be a “0”. If addenda do accompany the transaction, it'll be a “1”.

Trace Number

124002979650925

124002979650926

The system assigns this number so that we can trace the specific transaction if any questions arise. The number is assigned sequentially.

And that "S"?

Some transaction records will contain an s between the customer name and the addenda record indicator. This is a Payment Type Code, which indicates whether the payment is recurring or single. This field only shows up on WEB or TEL payment records, and in Secure Payments, it'll always be an s for 'single'.

5220Red Star                            1123456789TELPMT0001202210914210914   1111000020000030
63211100002523987879 000000033012072589 Alan Vega S 0111000020000034
63211100002582389782 000000028012072590 Martin Rev S 0111000020000035
822000000200222000040000000000000000000006101123456789 111000020000030

Here's first line of the footer:

And here's what each part means:

Field

Example

Description

First Digit

8

An eight here indicates that this row is the first line of the footer.

Service Class Code

225

Identifies the type of transactions in the file. 220 means credit only, 225 means debit only, and 200 means a mix.

Entry Addenda count

00006

The number of addenda (plural for addendum) for the entire file.

Entry Hash

0074401782

Total of the routing numbers in all the transactions in this file.

Total Debit

000000574489

The total of all debit transactions on this NACHA file. The last two digits are cents, with the decimal implied. This number, for instance, is $5,744.89

Total Credit

000000000000

Total of all credit transactions in the file; this should be all zeroes.

Company ID

1123456789

A ten-digit code indicating your company.

Routing Number

12400297

The bank's routing number

Batch Number

0000000

The batch number for this file.

And here's what each part means:

Field

Example

Description

First Digit

9

A 9 shows that this row is the second line of the footer.

Batch Count

000001

Total number of batches in the file.

Block Count

000001

Total number of records in the file, divided by 10.

Entry/Addenda Count

00000006

Total number of entry detail and addenda records on the file.

Entry Hash

0074401782

A sum of all the routing numbers for each transactions.

Total Debit

000000574489

The total of all debit transactions on this NACHA file. The last two digits are cents, with decimal implied. This number, for instance, is $5,744.89

Total Credit

000000000000

The total of all credit transactions on this file.

And what about all those 9s at the end of the file?

Often, you'll see a NACHA file like this, with several lines of the number nine:

101 12400297111234567892106222057A094101WELLS FARGO BANK NA    LendPro                00000000
5225LendPro 1123456789PPDPMT0001202210623210623 1124002970000000
6273220791335545778799693323 000000330019649024 Ron Mael 0124002979649024
6273220791339898656532322121 000001210019649025 Russell Mael 0124002979649025
822500000100124002970000000033000000000000001123456789 124002970000000
9000001000001000000010012400297000000003300000000000000
9999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999
9999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999
9999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999
9999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999

These numbers have no meaning, but are just there as filler. NACHA files are in block 10, meaning that the total number of rows should be divisible by ten. In the earlier example file, for instance, there were two lines of headers, six transaction records, and two footers, ten in total. In that file, there was no need for extra filler lines.

This file, however, only has six real lines (two headers, two transaction records, and two footers). To get in in valid block 10 format, the system adds four lines of filler.


How did we do?


Powered by HelpDocs (opens in a new tab)