Loans can be categorized with one payment method. Our system allows seven possible payment method codes. Payment method codes determine how interest is calculated, payment rules, and other rules to follow in processing the loan account. Payment methods are established when loans are originated and should not be changed after the loan has been funded and opened.

This guide will describe conventional loans, which are payment method 0. Conventional loans are usually for mortgages, second mortgages, properties, second properties, business properties, large equipment, etc. This guide will explain some of the major fields for this payment method.

**Note:** This description is more of an overview. Details of each loan may vary. This is for the purpose of learning about conventional loans on GPS’ system, and not a binding document in court.

**P/I Constant and Interest Calculation**

Conventional loans charge interest on a monthly basis based on the following factors:

**Interest Rate**(LNRATE)**Principal Balance**(LNPBAL) as of the last payment date (or**Date Opened**if no payments have been made)- Days difference from last
**Due Date**to current**Due Date** **Interest Calculation Method**(LNIBAS)

Conventional loans are originated with an unvarying **P/I Constant** due each month, which includes principal and interest amount. The interest amount of the **P/I Constant** (also known as P/I payment or contractual payment) is calculated slightly differently based on the Interest Calculation Method (LNIBAS). If the **Interest Calculation Method** is set to “1 – 365/365”, interest is calculated each month based on the following calculation:

**Principal Balance** amount as of last payment X **Interest Rate** = N

N ÷ 365 X days difference from last **Due Date** to current **Due Date** = the amount of payment that goes towards interest. The rest of the P/I Constant, after paying interest, goes to principal.

This calculation will be slightly different if you have something other than “1 – 365/365” selected in the **Interest Calculation Method** field, as will be discussed in the Interest Calculation Method section later in this document.

Example:

**P/I Constant** is $200.

**Principal Balance** as of last payment date = $25,000

**Interest Rate** = 5.75%

Last **Due Date** to this **Due Date** = 31 days

**Interest Calculation Method** = 1 – 365/365

**Interest calculation:**

25,000 X .0575 ÷ 365 X 31 = $122.09 ← This is the amount of interest paid from the **P/I Constant.**

200.00 – 122.09 = $77.91 ← This is the amount applied to principal from the P/I Constant.

**Loan Term and Payment Frequency**

Payment method 0 loans tend to have longer terms than interest-bearing (payment method 6) or precomputed loans (payment method 3). It’s not unusual for terms to be 360 months (30 years).

The only** Payment Frequency** allowed is “1 – Monthly” and you cannot change the **Frequency** on the Loans > Account Information > Payment Information screen.

**Payment Amounts for More Than Next Payment Due**

It’s common for your customers to make a larger payment than what is required by the **Next Payment Due**. The **Next Payment Due** is a calculated field that adds together the **P/I Constant** with the **Reserve 1/2 Constant**, should the loan include reserves. This is the amount of payment due each month.

If the loan does not include reserve payments, it’s not uncommon for the **P/I Constant** to be the same as the** Next Payment Due**, as shown below on the Loans > Account Information > Account Detail screen:

When a payment is made for equal to or greater than the **Next Payment Due**, the **Due Date** rolls ahead one month.

How does the system apply any extra funds when making a payment larger than the **Next Payment Due**? And does the system roll the **Due Date** for each met **P/I Constant**?

First, the system applies the payment according to the **Payment Application**, which is usually set up as follows:

- Pay interest from P/I Constant (2)
- Pay principal from P/I Constant (1)
- Pay any outstanding late charges (4)
- Pay any remaining miscellaneous fees (7)
- Should loans include reserve payments (3 and 6), they can also be added to the
**Payment Application**in the order required by your institution. - Maintenance fees (P/I Fees – 8) are
*not*allowed on payment method 0 loans.

There may be local, state, or federal regulations regarding the **Payment Application** order. Verify with your protocols the order required for payments. With most mortgage loans, interest and principal* must* be applied first. The **Payment Application** *can *be changed on the Loans > Account Information > Account Detail screen, but just because it *can* be changed doesn’t mean it *should *be changed. In fact, this should never be changed once an account is opened (unless, of course, you understand all the consequences and have security to do so).

If the payment includes funds for more than the **Next Payment Due** + late charges + fees + reserves, extra funds go towards paying down the **Principal Balance** on the loan.

**Note:** You may be familiar with the **Entire Payment Rolls Due Date** option on the Account Detail screen. This option isn’t needed if the **Payment Application** order is 2 (interest), then 1 (principal) first in the order, because the principal and interest will always be required first anyway, and payment method 0 loans require a full payment (see Payment Amount for Less Than Next Payment Due below).

**Due Date Only Rolls Once per Transaction**

Once the **Next Payment Due** has been met for a payment transaction, the **Due Date** rolls, but only once per payment transaction. So, if there were enough funds to add up two or three **Next Payment Dues** in one transaction, for example, the **Due Date** would still only roll *once*, and additional funds (after **P/I Constant**, fees, late charges, reserves) go toward principal.

However, if a customer were to make a payment for greater than or equal to the **Next Payment Due** one day, then later that day (or the next day and so forth), they make another payment for an amount greater than or equal to the **Next Payment Due**, the **Due Date** will roll again, but only once for *that* transaction. In other words, the **Payment Application** starts over with each payment. Does the payment meet **P/I Constant**? Are there any late charges or fees? Apply amounts to each **Payment Application**, and then apply extra funds to the **Principal Balance**.

You may want to train your tellers on this important distinction. If a customer wants to make three payments’ worth at one time, and the customer expects the **Due Date** to roll ahead three months, tellers should be careful to run three *separate *payment transactions and not one lump-sum transaction, or the **Due Date** will not roll more than once.

Additionally, the **Roll Due Date Within** option is ignored with payment method 0 loans as discussed in the Payment Amount for Less Than Next Payment Due below.

**Note:** If **Partial Payments** (which can occur as described in the Payment Amount for Less Than Next Payment Due section below) add up to a full payment, the system will roll the **Due Date** forward one frequency. There are some important setup requirements for this to happen, as will be discussed in the next section.

**First Example:**

**Next Payment Due** = $200.00

**Payment Application** = 2 (interest), 1 (principal), 4 (late charges), 7 (fees)

Outstanding Late Charges = $35.00 (one month’s worth)

Outstanding Miscellaneous Fees = $45

Borrower makes a $300 payment.

- $200 goes to principal and interest requirement;
**Due Date**rolls once. - $35.00 goes to reducing
**Late Charges Due**(LNLATE) to zero. - $45 goes to reducing
**Miscellaneous Fees**to zero. - $20 extra goes to reducing the
**Principal Balance**.

**Second Example:**

**P/I Constant** = $200.00

**Payment Application** = 2 (interest), 1 (principal), 4 (late charges), 7 (fees)

Outstanding Late Charges = $70.00 (two months’ worth of late charges)

Outstanding Miscellaneous Fees = $45

Borrower makes a $300 payment.

- $200 goes to principal and interest requirement;
**Due Date**rolls once. - $70.00 goes to reducing
**Late Charges Due**(LNLATE) to zero. - $30 goes to reducing
**Miscellaneous Fees**to $15.

**Third Example:**

**P/I Constant** = $200.00

**Payment Application** = 2 (interest), 1 (principal), 4 (late charges), 7 (fees)

Outstanding Late Charges = $70.00 (two months’ worth of late charges)

Borrower makes a $1,000 payment.

- $200 goes to principal and interest requirement;
**Due Date**rolls once. - $70.00 goes to reducing
**Late Charges Due**(LNLATE) to zero. - $730 extra goes to reducing the
**Principal Balance**.

**Fourth Example:**

**P/I Constant** = $200.00

**Payment Application** = 2 (interest), 1 (principal), 4 (late charges), 7 (fees)

Outstanding Late Charges = $70.00 (two months’ worth of late charges)

Borrower makes a $600 payment, but they want the **Due Date** to roll two times, and any remaining amount they want to go to **Partial Payments** instead of paying down the **Principal Balance** (curtailment).

- Teller would need to make the first payment for $270.00 (tran code 600). The teller can make that payment from EZPay, Make Loan Payment screen, or one of the payment transactions in GOLDTeller.
- $200 goes to
**P/I Constant**. - $70 goes to late charges.
**Due Date**rolls once.- Teller makes another payment for $200.
- $200 goes to
**P/I Constant**. **Due Date**rolls once again.- Teller makes a Partial Payment Increase (tran code 510-33) for the remaining amount.
- $130 goes to
**Partial Payments**. **Due Date**does*not*roll.- The amount in Partial Payments stays there until a full payment can be made, as described below.

**Payment Amounts for Less Than Next Payment Due**

A full payment (amount in **Next Payment Due**) is required if running a regular payment transaction (either through EZPay, CIM GOLDTeller, or the Make Loan Payment screen). If you attempt to run a payment transaction (tran code 600) for less than the **Next Payment Due** amount, the following error message will be displayed:

“AMT TOO LOW—PMT IS NNN.NN”

where NNN.NN is the **Next Payment Due** amount.

You may be wondering: surely your system allows payments for less than the **Next Payment Due**?

Yes, we do, but you need to run a special transaction to allow it.

The reason behind this is due to the way payment method 0 loans calculate interest due. Interest is calculated after a full payment is made as discussed above in the P/I Constant and Interest Calculation section above. So, any amount less than the **Next Payment Due** must go into the **Partial Payments** field, where afterhours functions and institution options designate what happens to the amount in **Partial Payments**.

In cases where a borrower wants to make a payment for less than the **Next Payment Due**, you must run a Partial Payment Increase transaction (tran code 510-33) for the amount of the payment, as shown below:

After this transaction is processed, the system will credit the amount of the transaction to the **Partial Payments** field on the Loans > Account Information > Account Detail screen, as shown below:

*Loans > Account Information > Account Detail Screen*

**Interest Due**, **Date Last Accrued**, **Date Interest Paid To**, and **Due Date** are not affected by a Partial Payment. Once there are enough funds in **Partial Payments**, then the system will apply that amount as a *full payment *in afterhours, debit the **Partial Payments** field, and advance the **Due Date** ahead one month.

What would happen if another Partial Payment were never made on the account? Would the amount in **Partial Payments** stay there indefinitely? And what happens if **Partial Payments** are for more than the **Next Payment Due**? What happens to the extra funds? The next section will answer these questions.

**What happens to Partial Payments?**

First, your institution needs Update Function 84 set up to direct funds from the **Partial Payments** field to the **P/I Constant** field or **Principal Balance** field, as described below. Your GOLDPoint Systems account manager should have set the Update Function 84 for you when you first acquired payment method 0 loans.

The Update Function runs a tran code 2600-08 to move funds from **Partial Payments** to making a payment. Tran code 2600-08 requires that the loan have a **Due Date** equal to or less than the date Update Function 84 runs. When Update Function 84 runs, a 600 payment transaction is run for the regular payment amount and a Partial Payment Decrease (tran code 500-33) is run for the same amount to decrease the **Partial Payments**.

**Note:** Tran code 2600-08 is a system transaction and cannot be found in your teller transactions in GOLDTeller.

Update Function 84 can be run daily, weekly, or monthly.

To qualify for this function, the loan must meet the following conditions:

- The loan must be a payment method 0, 4, or 7.
- The loan cannot have any holds that cannot be overridden. (For instance, the loan cannot have a hold code 7—legal hold/foreclosure.)
- The loan cannot be “locked in” for a payoff or payment reversal.
- There must be enough funds in the
**Partial Payments**field to post at least a full payment (**Next Payment Due**). - The
**Due Date**must be equal to or less than the run date (the date Update Function 84 runs). (Refer to option OPPP PPPA below.)

This process functions as follows:

With Update Function 84 set, but none of the institution options set (see details below), during the afterhours process, the system will compare the loan payment (**Next Payment Due**) with the amount in **Partial Payments**. If there is enough money in **Partial Payments** to post a full payment, it will post a loan payment (tran code 2600-08, which shows as a tran code 600 in History) and then debit **Partial Payments** by the **Next Payment Due** amount (tran code 500-33).

If the **Partial Payments** add up to more than the **Next Payment Due**, the system will subtract the amount of the full payment from the **Partial Payments** amount when the afterhours Update 84 function runs, and the remainder of funds will stay in the **Partial Payments** field, unless institution PPPC is set, as described below. In which case, extra funds will go toward reducing the Principal Balance (curtailment).

If **Partial Payments** do *not* add up to enough for a full payment, the amount will remain in **Partial Payments** until payoff or your institution manually handles those funds. You should use this field as a collection device to encourage the borrower to make a full payment, or enough of a payment to clear out **Partial Payments**. In fact, a message will appear in GOLDTeller any time an account has **Partial Payments**, as shown below:

When tellers see that message, it’s a prompt for them to ask the borrower, “You still have funds from a previous payment. Would you like to pay the remainder to make a full payment?”

If the borrower does want to make a payment for the remaining amount owed that month, the teller could do either of the following:

- The teller could calculate what the remainder of funds would be to make a full payment (subtract the current
**Partial Payments**amount from the**Next Payment Due**, and that will be the amount needed for a full payment). Then the teller could run another Partial Payment Increase (tran code 510-33) for the remaining amount (either**Check In**or**Cash In**) and let the afterhours apply the full payment (assuming the**Due Date**is less than today’s date and Update Function 84 is set to daily). - The second way tellers could process these partial payments isn’t recommended, as it takes balancing journals and the
**Due Date**does*not*advance. However, if the customer wants to apply that**Partial Payment**today to the**Principal Balance**, this option is available. You should only allow this method if the loan is current (**Due Date**is in the future).

- The teller should run a Partial Payment transaction for the remaining amount of the loan payment (subtract the current
**Partial Payments**amount from the**Next Payment Due**). You can only use GOLDTeller to process this payment, because you need to balance the account with the next two journal transactions, and ACH and debit/credit cards wouldn’t work (because the system would require a full payment amount). - Then run a Partial Payment Decrease by Journal (tran code 500-34) for the amount in
**Partial Payments**. See below:

C. Then run a Principal Decrease by Journal (tran code 510-48) for the amount in **Partial Payments**. See below:

These transactions will show on the Loans > History screen.

**Note:** The hard news is, partial payments are just not allowed for ACH, credit card, or debit card payments. Only a full payment would be allowed for those, because they require a transmission to the ACH or credit/debit card. And there’s no way currently in our system to send only a partial payment through those transmissions using payment method 0. Now you could do some minor manipulation with the **P/I Constant** if you have security and reduce it by the amount the borrower wants to pay. Then after the payment, you would change the **P/I Constant** back. But we wouldn’t recommend doing that, as you may miss out on some interest.

**Example:**

Let’s say the **Next Payment Due** on the loan is $500. A collector calls the borrower about a missed payment. The borrower says they could make a $300 payment now but don’t have enough for the full $500. The collector takes the $300 payment (via **Check In**) and runs a tran code 510-33 that puts the $300 in the **Partial Payments** field.

Later that month or next month, a full payment still has not been made. A collector talks to the borrower and encourages the borrower to make at least a $200 payment to avoid late charges for that month. The borrower makes the $200 payment, and the teller runs another tran code 510-33 for the $200 amount. In the afterhours, the system will move the $500 amount in the **Partial Payments** and apply it as a payment. The **Due Date** will move ahead one month.

**Holiday Payment Example:**

You could use **Partial Payments** to skip a payment in December during the holiday season. To do this, customers would need to pay a small additional amount each month. But tellers shouldn’t run the full amount of the payment through a regular payment transaction. Instead, they would run a payment for the full amount (**Next Payment Due**), but then any extra funds they would use the Partial Payments Increase transaction (tran code 510-33) to apply the extra amount to **Partial Payments**. They would do that each month with the payment. Then when **Partial Payments** has enough funds to make a full payment, the system will run Update Function 84, apply the payment, and roll the **Due Date**, allowing the customer to essentially skip a payment.

**Partial Payment Options**

Three institution options pertaining to paying late charges and miscellaneous fees, allowing the loan to be paid in the future, and processing excess funds as a curtailment are also available regarding Partial Payments. They are as follows.

**Important:** The process of automatically moving Partial Payment funds to a payment transaction when the amount reaches a full payment requires the **Due Date** to be equal to or later than the run date (the date Update Function 84 runs), even with these options set.

**OPPP PPLF—Partial Payments–Pay Late Charge/Fees?**

If there are more funds in **Partial Payments** than **Next Payment Due**, any excess funds will post next to late charges and last to miscellaneous fees.

**OPPP PPPA—Partial Payments–Pay Ahead?**

If the Partial Payment amount is enough to post two or more payments, the system will post as many payments as there are funds (**P/I Constant**) and roll the **Due Date** for each of those payments. If this option is *not *set, additional funds once the account is caught up (**Due Date** is in the future), will reduce the **Principal Balance** or remain in **Partial Payments** (depending on if option PPPC is set below).

For example, a borrower is behind one payment. A collector calls the borrower, and the borrower makes a payment large enough to cover three payments. The collector should run a tran code 510-33 (Partial Payments Increase) for the full amount of the payment (all three payments). In the afterhours, the system will roll the **Due Date** three times, bringing the borrower current and even ahead by two months. If this option was *not* set in this example, the system would apply one payment (**P/I Constant**); roll the **Due Date** once to keep the account current; and leave the remaining amount in **Partial Payments** or pay down the **Principal Balance **(if PPPC is set).

**OPPP PPPC—Partial Payments–Pay Curtailment?**

After paying all full payments (and fees and late charges if the options above are set), any excess funds will be posted as a principal decrease (only on loans not sold to an investor (**Percent Sold** equal to zero)). After bringing the loan current, paying the late charges and fees (according to the option), and paying the loan ahead (according to the option), any remaining funds in Partial Payments will be posted to the **Principal Balance**. (Current means the **Due Date** is greater than or equal to today (the run date).)

**Note:** None of the options will function without **Partial Payments** being equal to or greater than the **P/I Constant**.

Any or all these options can be set.

All transactions are posted with a TORC 61 (partial payments). They are identified in Loan History as a payment from partial payments (tran code 600), except if any loan miscellaneous fees are involved with the Partial Payment transaction. Those are recorded separately in History. See example below:

All transactions will appear on the Transaction Journal by Tran Origination Code Report (FPSRP041). Any transactions that fail will appear on the Afterhours Processing Exceptions Listing (FPSRP013).

If **Partial Payments** never add up to a full payment amount, they will remain in that field until Payoff, when the system will balance the totals and apply the payment.

The Partial Payments Report (FPSRP198) shows all loans that have funds in the **Partial Payments** field.

**WARNING**

Prior to using this function, please contact the GOLDPoint Systems financial team as your Autopost may need to be adjusted for TORC 61.

**Interest Calculation Methods**

As mentioned earlier, the interest amount on conventional loans is calculated each month according to the **Principal Balance**, **Interest Rate**, and **Interest Calculation Method**. The **Interest Calculation Method** basically determines the number of days used in calculating that month’s interest. Once the **Interest Calculation Method** is set up on the loan, you should *not* be changing it. Loan disclosures require you to inform the borrower the method in which interest is calculated.

The **Date Last Accrued** (LNDLAC) will be exactly one month of payment behind the **Due Date**. Interest for a payment is calculated from the **Date Last Accrued** to the **Due Date**.

The **Date Interest Paid To** (LNPDTO) is the date up to which interest has been paid on the loan. It is not used for interest calculation purposes, but it is shown on the Account Detail screen for loan servicing convenience. This field is updated when a payment is made. It is usually the same date as the **Date Last Accrued**.

The **Interest Due** field shows the amount of calculated interest due each month.

See the following example of these fields on the Loans > Account Information > Account Detail screen:

For conventional loans, the five possible calculation codes are:

- 1 - 365/365 days per year
- 2 - 360/360 days per year
- 3 - 365/360 days per year
- 4 - 360/365 days per year
- 5*- 366/366 days in a leap year

* Note that for a leap year, if the interest period includes crosses over from a leap year to a non-leap year (or vice versa), such as 12/15/19 to 01/15/20, the period from 12/15/19 (the non-leap year) to 01/15/20 will use the 365-day basis and the period from 01/15/20 to 02/15/20 (leap year) will use the 366-day basis.

A brief description of the codes follows.

**Code 1 – 365/365 days per year**

If the **Interest Calculation Method** is set to “1 – 365/365”, monthly interest for the **P/I Constant** is calculated as follows:

**Principal Balance** amount as of last payment X **Interest Rate** = N

N ÷ 365 X days difference from last **Due Date** to current **Due Date** = the amount of payment that goes towards interest. The rest of the **P/I Constant**, after paying interest, goes to principal.

Example:

**P/I Constant** is $200.

**Principal Balance** as of last payment date = $25,000

**Interest Rate **= 5.75%

Last **Due Date** to this **Due Date** = 30 days

**Interest Calculation Method** = 1 – 365/365

**Interest calculation: **

25,000 X .0575 ÷ 365 X 31 = $122.09 ← This is the amount of interest paid from the **P/I Constant.**

200.00 – 122.09 = $77.97 ← This is the amount applied to principal from the **P/I Constant.**

**Code 2 – 360/360 days per year**

Code 2 considers every month as having 30 days. February and all the months with 31 days are considered 30-day months. This makes it an easy calculation, as follows:

**Principal Balance X Interest Rate** ÷ 365 X 30 = the amount of **P/I Constant** that goes towards interest

Example:

**P/I Constant** is $200.

**Principal Balance** as of last payment date = $25,000

**Due Date** to **Due Date** = 31 (but the calculation will use 30)

**Interest Rate** = 5.75%

**Interest calculation: **

25,000 X .0575 ÷ 360 X 30 = $119.79 ← This is the amount of interest paid from the **P/I Constant.**

200.00 – 119.79 = $80.21 ← This is the amount applied to principal from the **P/I Constant.**

**Code 3 – 365/360 days per year**

When using Code 3, the annual interest rate is divided by 360 to get the daily interest rate, and then multiplied by the days in the month.

**Principal Balance** amount as of last payment X **Interest Rate** = N

N ÷ 360 X days difference from last **Due Date** to current **Due Date** = the amount of payment that goes towards interest. The rest of the **P/I Constant**, after paying interest, goes to principal.

Example:

**P/I Constant** is $200.

**Principal Balance** as of last payment date = $25,000

**Interest Rate** = 5.75%

**Due Date** to current **Due Date** = 31 days

**Interest calculation:**

25,000 X .0575 ÷ 360 X 31 = 123.78 ← This is the amount of interest paid from the **P/I Constant.**

200.00 – 123.78 = $76.22 ← This is the amount applied to principal from the **P/I Constant.**

**Code 4 – 360/365 days per year**

Simply put, Code 4 is like a 365-day simple daily calculation (Code 1) but looks like a 360-day calculation (Code 2) where each month has 30 days. Like Code 1, this method calculates interest accruals every day using a daily per diem interest amount. But instead of using 365 or 366 days when figuring the daily interest amount, the rate is always divided by 360 days.

**Principal Balance** amount as of last payment X **Interest Rate** = N

N ÷ 360 X 30 (because every month is considered 30 days) = the amount of payment that goes towards interest. The rest of the **P/I Constant**, after paying interest, goes to principal.

Example:

**P/I Constant** is $200.

**Principal Balance** as of last payment date = $25,000

**Interest Rate** = 5.75%

Every month is considered 30 days of interest (even though **Due Date** to **Due Date** is 31)

**Interest calculation:**

25,000 X .0575 ÷ 365 X 30 = 118.15 ← This is the amount of interest paid from the **P/I Constant.**

200.00 – 118.15 = $81.85 ← This is the amount applied to principal from the **P/I Constant**

**Code 5 – 366/366 days in a leap year**

Code 5 is like a 365-day simple daily calculation (Code 1) but it also considers leap years. So, when there is a leap year, it calculates using 366, and when there isn’t a leap year, it calculates using 365.

**Principal Balance** amount as of last payment X **Interest Rate** = N

N ÷ 366 (if leap year/365 if non-leap year) X number of days from **Due Date** to **Due Date** = the amount of payment that goes towards interest. The rest of the **P/I Constant**, after paying interest, goes to principal.

Example:

**P/I Constant** is $200.

**Principal Balance** as of last payment date = $25,000

**Interest Rate** = 5.75%

**Last Due Date** is 02/15/2020 and next **Due Date** is 03/15/2020 (a leap year) = 29 days

**Interest calculation:**

25,000 X .0575 ÷ 366 X 29 = 113.90 ← This is the amount of interest paid from the **P/I Constant.**

200.00 – 113.90 = $86.10 ← This is the amount applied to principal from the **P/I Constant.**

**Changing the Due Date**

Generally speaking, the **Due Date** (LNDUDT) cannot be changed with conventional loans once the loan has been originated. However, your institution’s policies may allow for slight **Due Date** changes, such as a borrower needing the payment due to be three more days in the future.

Again, loan documents should clarify if and when **Due Date** changes are possible. For example, some institutions may allow one **Due Date** change, but only within the same month of payment, such as moving from a **Due Date** at the beginning of the month to the end of the month. Another requirement might be that the loan is current (**Due Date** is today or in the future).

If you do allow slight **Due Date** changes, the way to change the **Due Date** is a little different from other payment methods. You should only change the **Due Date** within a given payment period (**Date Last Accrued **to **Due Date**). Because interest is accrued monthly, changing the **Due Date** should not affect the amount of interest due as long as the **Due Date** is changed within the payment period.

You would first need to change the **Interest Due To** field (LNDLAC) to the new day of the month you want the **Due Date**. This field is both on the Account tab and Interest tab of the Loans > Account Information > Account Detail screen, but it’s only file maintainable on the Interest Detail tab. After changing that field, you can change the **Due Date** to correspond appropriately using the **Due Date** field on the Account tab of the Account Detail screen.

**Note:** This is assuming you have security to make changes to those fields. Those fields can have field-level security.

For example, if the **Date Last Accrued** (this field is named **Interest Due To** on the Interest Detail tab) is 06/02/2020, and the borrower would like the **Due Date** on the 15^{th}, because that’s when they get their paycheck, you would change the **Interest Paid To** to 06/15/2020, as well as the **Due Date** to 07/15/2020, then click <Save Changes>.

If you attempt to change either field without changing the other field, and you click <Save Changes>, the following error message will be displayed:

**Payoffs**

When the loan is nearing payoff, you will want to consider creating an event letter to send to borrowers with details of the payoff. You can also print a quote from the Loans > Payoff screen. For more information on the payoff event letter, payoffs, and payoff quotes, see these topics in DocsOnWeb:

You may also want to consider whether a payment method 0 loan can be paid off with a recurring payment or through your institution’s website. Certain options must be set up to allow payoffs through recurring payments or your website. See the Important Payoff Options You Should Know About topic.

Once the loan has been locked and paid off, the loan is closed. It remains on the system as a closed loan until designated by your archive options, and then it is archived.

Accounts are archived according to the **Last Transaction Date** (LNTRAN), which is usually the same as the **Date Closed** (LNDCLSD). If accounts have a **Last Transaction Date** older than the number of months entered in institution option ARCM, the account’s history is archived for that number of months.