Nacha
This article explains how to configure and use Nacha files for U.S. transactions within LoanPro. Secure Payments specifically uses unbalanced Nacha files, which display one-way transactions from your customers.
Adding a Nacha processor
A processor can be added through either LMS or Secure Payments. Some advanced settings relating to batching days and times are only found in Secure Payments.
- For LMS:
- Navigate within LMS to Settings > Company > Merchant > Secure Payments > BANK ACCOUNT/ACH (USA) > Add Processor. Select ‘NACHA’ from the ‘Processor Type’ dropdown menu.
- Enter the following information in the new window.
- Processor name: The name you give to this Nacha processor to distinguish it from other Nacha processors.
- Company name: Your company name in the way your bank has it on file.
- Bank name: Name of your bank.
- Bank routing/transit number: Routing or transit number for your bank.
- Company EIN/Tax ID: Company’s Employer Identification Number or Tax Identification Number.
- Company discretionary data: Allows your company to include codes significant only to you (e.g., a batch number for a specific Nacha file).
- Cut off time: Hour of the day and the 15 minute increment when the batch will run, in Coordinated Universal Time (UTC).
- Merge similar transaction: If two transactions are made on this Nacha processor with the same account number and routing number, they will merge into a single transaction.
- Choose the settings you want for this processor.
- Auto reversal: Select “Yes” if you want payments that are returned to be automatically reversed in LoanPro.
- Default processor: Select “Yes” if you want this processor to be the default for new AutoPays.
- Once you've finished entering in the correct information, click the ‘Save’ button.
- For Secure Payments:
- Navigate to Secure Payments and then go to Processors > Bank Account/ACH (USA) > Natcha Batch Submission. Click the plus sign button at the top right.
- Enter the needed information in the new window. Many of the settings on this page are the same as the ones in the LMS UI with only a few exceptions:
- Export type: Choose whether the output file is a Nacha or CSV file.
- Time zone: Select a time zone for the cutoff time. Time Zones will be updated automatically to reflect daylight savings time shifts.
- Batching days: Choose what days the Nacha batch will generate by checking the correlating box.
- Exclude banking holidays: Checking this box will tell Secure Payments not to batch on banking holidays. The calendar icon allows you to customize dates to match your bank's holidays.
- Click the ‘Save’ button when you're finished entering the information.
NACHA Version 2 (V2)
NACHA file V2 is now available in Secure Payments. You can select your preferred file when you are configuring your processor settings. To select V2, navigate to Secure Payments > Processors > Bank Account/ACH > NACHA Batch Submission. From here, you can either set up a new processor or edit an existing one. Scroll down to the “File Version” drop down menu where you will be able to select V1 or V2.
To complete your selection, click “Save”.
Please note that V2 will automatically assign IDs starting with number 1 while V1 starts at 0.
Automated Nacha file delivery
To enhance your operational efficiency, you can automatically generate encrypted Nacha files and deliver them to your bank’s SFTP site. When banks send return files, LoanPro can automatically update accounts and take servicing actions based on your business logic (like disabling AutoPays and contacting a borrower when payments fail).
Since each bank formats their return files differently, this process will require additional configuration time for each bank you submit files to. Reach out to your normal LoanPro contact to get started. You’ll need to provide us with some information:
- Your bank’s SFTP site, where the file will be delivered.
- The encryption credentials or PGP Key your bank will use.
- An email address where LoanPro can send notifications when the Nacha file has been delivered.
From there, we can set up the automation to send encrypted Nacha files one whatever cadence you prefer. When banks send their return files (either in a .csv or .txt format), LoanPro can automatically update accounts.
Manually generating a Nacha file
If you prefer to manually generate and send Nacha files, you can download them in Secure Payments. On the ‘NACHA Files and History’ page, you can view your account's Nacha file history and generate new files. To generate a file, click the document icon in the top right of the page.
A window will display and allow you to select a processor from the ‘Processor’ dropdown. Once you have chosen the processor you want to generate a Nacha file for, click 'Generate'. This will generate a file that includes all recorded transactions for the processor since the last Nacha file was created. At this point, you are responsible to send the generated Nacha file to your bank so that transactions can be processed. If you don’t do anything with the file, no money will actually be deposited or withdrawn from your bank account.
If the export type of the processor for which you are trying to generate a file has been set to ‘None’, no file will be generated. To change the ‘Export Type’ field, navigate to Processors > Bank Account/ACH (USA) > NACHA BATCH SUBMISSION in your Secure Payments account and select the edit icon next to the processor.
When Nacha files are generated, any special character names will be scrubbed out. Accepted characters are numbers, letters (uppercase and lowercase) and the characters "-", "&", and ",".
“On Us” Processing
LoanPro also offers “On Us” Nacha processing. This feature will automatically identify any transactions that have the same routing number as the destination bank (i.e. your bank) and will split the transactions into two files. This eliminates the need to remove funds from borrowers who use your bank only to route them back to the same bank. To enable this feature navigate to Secure Payments > Processors > Bank Account/ACH (USA) > NACHA Batch Submission. From there you can add a new processor or edit an existing one. On the Add/Edit NACHA page, scroll down to ‘"On Us" Processing’ and use the drop down to enable.
Next, you'll enter the routing number(s) you want to classify as “On Us”. Select your Export Type and then click ‘Save’.
Nacha returns
Nacha's standards contain specific codes for returned payments, called "R-Codes" for short. To help make your automatic payment process as easy as possible, LoanPro lets you choose an action that the system should take depending on the R-Code.
Return codes
The table below lists all possible return codes.
Automated transaction status updates
Since there are no bank integrations that provide information on if Nacha transactions have settled, Secure Payments cannot receive this information. To counteract this issue, Secure Payments provides a setting that lets users specify the number of days a Nacha transaction should remain in the ‘Processing’ status before it is automatically moved to the ‘Settled Successfully’ status. If payments are reversed or otherwise taken out of the ‘Processing’ status, they will not be moved to the ‘Settled Successfully’ status automatically.
To use this setting,
- Navigate to ‘Actions’ on the left navigation bar in Secure Payments.
- Click the settings icon for Nacha Payment Updates in the table.
- This will open a popup window that shows the following explanation about when transaction statuses will be changed based on when the transactions are processed. Note when the explanation talks about a transaction being processed, this means that they are moved to a batch, which puts them in ‘Processing’ status.
- Set the number of days that should elapse between the batching and the change of status to ‘Settled Successfully’. You can also choose whether the number of days is calendar days or banking days.
- Once you have entered the information, click ‘Save’. The transaction status update will now automatically occur.
Download past files
The search field provides the ability to find and download Nacha files that you have created in the past. With the search functionality, you can either search by keywords or by date.
Select the download button to download a generated Nacha file.
Build and submit Nacha files outside of Secure Payments
Some clients want to create and submit Nacha files to their banks themselves, instead of using Nacha files provided by Secure Payments. The reasons for doing this will vary, but they include retaining control of payment processing in-house, settling transactions to different bank accounts, or the need for specific information in the Nacha file that is not included in the file provided by Secure Payments. If you have a need to create your own Nacha files, it is still highly recommended to use Secure Payments' batching process to manage Nacha payments within LoanPro.
If you would like to process Nacha payments entirely from LoanPro, you may use the following process.
To make the process clear, it will be broken down into the following steps:
- Create a payment custom field
- Pull a payment history report from LoanPro
- Create your Nacha file
- Mark payments included in the Nacha file as submitted in LoanPro
Create a Payment Custom Field
To learn how to create a custom field associated with payments, see our payment custom fields article.
The selection options for your custom field will be:
- Not Submitted
- Nacha Submitted
- Completed
Pull payments report
Send a POST request to this endpoint:
https://loanpro.simnang.com/api/public/api/1/Autopal.PaymentReport
When you pull the payments report, you will want only results where the payment custom field you created has a value of 1. Here is an example of a query you would use to get the correct results. To use this correctly, replace {customFieldId}
with the ID of the custom field you created.
{
"query": null,
"reportOptions": {
"method": "all",
"type": "all",
"status": "all",
"reversereason": "all",
"chargeOff": "all",
"period": "other",
"dateFrom": "",
"dateTo": "",
"changedPeriod": "tw",
"changedDateFrom": "2017-11-12T00:00:01",
"changedDateTo": "2017-11-15T23:59:59",
"sourceCompanies": [
{
"id": ""
}
],
"portfoliosCriteria": "all",
"splitPayments": "all",
"dateEnteredPeriod": "other",
"dateEnteredTo": "",
"dateEnteredFrom": "",
"customFields": {
"{customFieldId}": "1"
},
"chargeOffRecovery": "all",
"selectedPortfolios": [
},
{
"category": "",
"portfolio": "",
"subportfolio": ""
}
]
}
}
Create a Nacha File
Creating a Nacha file is a complex process, as they have to be formatted in a very specific style. For that reason, we recommend using a software that specializes in building them; ask your success specialist and they can give you some options.
Mark payments as submitted
To make the payments as submitted, you’ll need to update the value of the custom field for all payments that were included in the Nacha file. To do this, you’ll first need to get the IDs for the custom field values that you want to update. This is best done using the following GET request. To use it, change {PaymentID}
to the ID of the first payment for which you want to change a custom field value and {customFieldId}
to the ID of the custom field you created.
GET https://loanpro.simnang.com/api/public/api/1/odata.svc/CustomFieldValues?$filter=entityType eq ‘Entity.Payment’ and entityId eq {PaymentID} and customFieldId eq {customFieldId}
This will retrieve the data for a single payment and will return something like this:
{
"d": {
"results": [
{
"__metadata": {
"uri": "https://local.fandora.com/api/public/api/1/odata.svc/CustomFieldValues(id=111)",
"type": "Entity.CustomFieldValue"
},
"CustomField": {
"__deferred": {
"uri": "CustomFieldValues(id=111)/CustomField"
}
},
"id": 111,
"entityId": 100,
"entityType": "Entity.Payment",
"customFieldId": 25,
"customFieldValue": 1
}
],
"summary": {
"start": 0,
"pageSize": 50,
"total": 1
}
}
}
The id for the custom field value is labeled “id” in the response. To change the value, use the following request.
PUT https://loanpro.simnang.com/api/public/api/1/odata.svc/CustomFieldValues({customFieldId})
{
"customFieldValue": "2"
}
This will update the custom field value to a value of “2” or Nacha Submitted, on the custom field for this payment. You will need to repeat this process for each payment that was included in the Nacha file.
Sample Nacha file
If your bank finds any errors in your Nacha file, you can use this sample file with line-by-line explanations to see what’s wrong and how to fix it.
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
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. 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 Number | 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.
|
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. Typically, your bank will tell you to use your nine-digit EIN, preceded by a 1. |
Standard Entry Class Codes (SEC Codes) | PPD | Shows the type of transactions in the file, such as PPD, CCD, CTX, WEB, TEL, etc. |
Entry Description | PMT0001202 | This data is hard-coded from LoanPro, and will always be PMT0001202. |
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 borrower's bank. The first eight digits help the Federal Reserve and American Banking Association (ABA) identify the bank. The ninth digit is called a Check Digit, and it helps prevent errors. |
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
Footer, Line 1
Here's the 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 | 000006 | The number of addenda (plural for addendum) for the entire file. |
Entry Hash | 0074401782 | A sum of all the routing numbers for each transactions. (Note that this is the sum of the first eight digits of each number; it does not include the Check Digit.) |
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. |
Footer, Line 2
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 | Same as the Entry Hash in the first line of the footer—a sum of all the routing numbers for each transactions. (Just the first eight digits; not the Check Digit.) |
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 achieve a valid block 10 format, the system adds four lines of filler.
Was this article helpful?