Understanding Payment Terms

This chapter provides overviews of payments terms, standard payment terms, advanced payment terms, and examples of advanced payment terms and due date rules.

Payment Terms

Payment terms are used by the JD Edwards EnterpriseOne Accounts Payable and Accounts Receivable systems to specify a payment due date and, optionally, a discount percent and discount due date. Payment terms enable you to enter invoices and vouchers more efficiently because the system calculates the due dates and discounts for you. You can specify a default payment term on the customer and supplier records. Then, when you enter a voucher or invoice for that customer or supplier, you can either accept the default value or override it with a different payment term.

Payment term codes can range from simple to complex, depending on your organization's policies. You define a payment term by using a one-, two-, or three-character combination of these types of characters:

• Alphabetic (A–ZZZ)

• Numeric (0–999)

• Special characters (including blank)

For example, you might use A1%, which combines all three types of characters, for a percentage payment term code.

The JD Edwards EnterpriseOne Accounts Payable and Accounts Receivable systems use the same payment terms; payment terms are not system specific.

Commonly Used Payment Terms

You can use a blank payment term code for the most commonly used payment term, but you should also set up that payment term with a code to use as an override, especially if you use a nonblank default payment term on the customer or supplier record. For example, if the supplier master record is set up to use 001 as the payment term code, and you want to override it on the voucher to the blank payment term code, the system will continue to supply the default (001) from the supplier record every time you clear the field.

Types of Payment Terms

Two types of payment terms are available:

Standard Payment Terms

You set up standard payment terms using the Payment Terms Revisions program (P0014). The system uses the information for the payment term code to calculate the values for the due date, discount available, and discount due date on the invoice and voucher entry forms. Unlike advanced payment terms, you do not set up due date rules for standard payment terms.

Standard Payment Term Codes

Standard payment terms enable you to set up these basic payment due dates:

• Due upon receipt

• Fixed

• Net

• Proximate date

• Split

The system stores standard payment terms in the Payment Terms table (F0014).

Due Upon Receipt Payment Terms

Use due upon receipt payment terms when you want the due date to equal the invoice date. You set up the payment term without specifying any additional information.

Fixed Payment Terms

Use fixed payment terms when you want to specify a due date instead of having the system calculate the due date. For example, if you want all transactions due at the end of the year regardless of when they were entered, enter a due date of December 31, 2006.

Net Payment Terms

Use net payment terms to specify the due date of the transaction by adding some number of days to the invoice date of the transaction. Assume that you specify net 30 days to pay and you enter a transaction with an invoice date of June 14. The system calculates the due date as July 14.

In addition to specifying the net days to pay (or due date), you can specify the discount percent and the discount days. The system multiplies the gross amount by the discount percent to calculate the discount available. It then adds the discount days to the invoice date to determine the discount due date.

Assume that you set up a payment term code for:

• Discount of 1 percent.

• Discount days of 10.

• Net days to pay of 30.

You enter a transaction with an invoice date of June 14. The system calculates the discount due date as June 24 and the net due date as July 14. The customer has until July 14 to remit their payment to receive a 1 percent discount; otherwise, the payment is due June 24.

Proximate Date Payment Terms

Use proximate date payment terms when you want the transaction due date to be on the same date of the month regardless of the invoice date. You specify the number of months to add to the invoice date and the date in that month on which the transaction is due.

Assume that you set up a payment term code for:

• Proximate month of 1.

• Proximate day of 10.

You enter a transaction with an invoice date of May 20. The system calculates the due date as June 10. To specify a due date for the last day of the month, use a proximate month of 0 and proximate days of 31. The system uses the last day of the month regardless of the number of days in the month.

In addition to specifying the proximate month and day, you can specify the discount percent and the discount days. The system multiplies the gross amount by the discount percent to calculate the discount available, and adds the discount days to the invoice date to calculate the discount due date.

Assume that you set up a payment term code for:

• Discount of 1 percent.

• Discount days of 10.

• Proximate month of 1.

• Proximate days of 10.

You enter a transaction with an invoice date of June 14. The system calculates a discount due date of June 24 and a net due date of July 10. The customer has until June 24 to remit their payment to receive a 1 percent discount; otherwise, the payment is due July 10.

Split Payment Terms

Use split payment terms when you want the system to divide the transaction evenly into multiple payments with different due dates and the number of days between the second and subsequent payments is constant.

You specify the net days to pay, the number by which you want to divide the transaction, and the days to pay aging. The system uses the net days to pay to calculate the due date of the first payment, and the days to pay aging to calculate the due dates for the second and subsequent payments.

Assume that you set up a payment term code for:

• Net days to pay of 20.

• Split payments of 4.

• Days to pay aging of 30.

You enter a voucher with an invoice date June 14. The system divides the voucher into four payments and calculates these due dates:

• For the first payment, the due date is July 4 (20 days from the invoice date).

• For the second payment, the due date is August 3 (30 days from the due date of the first payment).

• For the third payment, the due date is September 2 (30 days from the due date of the second payment).

• For the fourth payment, the due date is October 2 (30 days from the due date of the third payment).

  Note. You do not see the effects of the split until you complete the entry process for the transaction and then re-inquire on it.

  In addition to specifying the split payment term, you can specify the discount percent and the discount days. The system calculates the discount available for each payment. You specify the information for the split payment term, as well as the discount percent and the number of days to add to the invoice date to calculate the discount due date.

Assume that you set up a payment term code for:

• Discount of 1 percent.

• Discount days of 10.

• Net days to pay of 20.

• Split payments of 3.

• Days to pay aging of 30.

You enter a transaction for 3,000 USD with an invoice date of June 1. The system calculates these dates for each payment:

The system performs soft rounding on amounts that do not divide equally.

Advanced Payment Terms

Advanced payment terms enable you to customize payment due dates by setting up due date rules. Due date rules enable you to set up more complex and diverse payment terms because you can:

• Specify a work day calendar and work day rule.

  Specify which days of the month are work days and which are weekends and holidays. Additionally, if due dates fall on a weekend or holiday, you can specify whether to use that date or have the system automatically change the due date to the previous or following working day.

• Specify the based-on date.

  Unlike the due dates for standard payment terms, which are always based on the invoice date, advanced payment terms enable you to specify whether to use the invoice date, GL date, or service/tax date.

• Specify the number of days and months to add to or subtract from the based-on date based on a range of transaction dates, or specify the months to add and a fixed date based on a date range.

• Specify unique rules for net and discount due dates.

  You could have net due dates that use a date range and are based on the GL date and discount due dates that have a fixed date based on the invoice date.

The system stores advanced payment term information in these tables:

• Advanced Payment Terms (F00141).

• Due Date Rules (F00142).

• Due Date Rules Day Range (F00143).

• Installment Payment Terms (F00144).

• Multitiered Payment Terms (F00147).

Work Day Calendars and Rules

Before you set up due date rules, set up work day calendars using the Work Day Calendar program (P00071). Calendars enable you to specify actual work days, weekends, holidays, and other user-defined types of days for your organization. You can set up multiple calendars and reference one of them in a due date rule.

After you set up a work day calendar, you specify how the system calculates the due date on a nonworking day. You specify the work day rule for a due date rule using the Due Date Rule Revisions program (P00146). By using a work day rule, you can adjust the payment's due date to correspond to your work days, as well as prevent unintended grace periods that might occur if the due date falls on a Saturday and your business is closed.

For example, you can instruct the system to:

• Use work days only when counting the days to calculate the due date and not allow the due date to occur on a nonwork day.

• Use the work day after the calculated due date as the due date. For example, if the calculated due date occurs on the weekend, the system moves it to the following Monday.

• Use the work day before the calculated due date as the due date. For example, if the calculated due date falls on the weekend, the system moves it to the previous Friday.

Work day calendars are stored in the Workday Calendar table (F0007).

Due Date Rules

Before you set up advanced payment term codes, you must define the rules that the system uses to calculate due dates for invoices and vouchers. You can set up as many due date rules as necessary.

You can set up a due date rule for either a discount due date or a net due date. After you set up due date rules, you set up the advanced payment term code that uses the rule and you specify a discount percentage, if desired. Thus, the due date rule is linked to the advanced payment term code and discount percentage to define:

• Default payment term code for a customer or supplier.

• Payment term code for a specific invoice or voucher.

• Payment term code for a specific invoice or voucher pay item.

You can verify that the due date rules that you set up are correct by using the Simulator program, which is available from the Due Date Rules Revisions program (P00146). The Simulator program enables you to perform multiple tests on due date rules without entering transactions.

Due Date Rule Components

Using a combination of due date components enables you to set up unlimited payment terms to meet your business needs. A due date rule can consist of any of the components listed in this table.

Date Ranges

You set up date ranges at the time that you set up due date rules. If you specify a date range for a due date rule, the system uses the last day in the range in conjunction with the months to add, the days to add, or a fixed date. If you do not specify a month to add, days to add, or a fixed date, the system assigns the last day of the range as the due date.

For example, if you set up a date range from the 10^th to the 25^th of June and you do not specify a fixed date or months and days to add, the due date of the payment is June 25^th.

The ranges cannot overlap, and they must include a full month (the 1^st through the 31^st). The system always uses the last day of the month, regardless of the number of days in the month, when you specify fixed days as 31.

When you set up a date range, you can specify the number of months to add along with the number of days to add or the fixed date. However, you cannot specify both the number of days to add and a fixed date. The types of date ranges that you can specify are:

• Months to add.

• Days to add.

• Fixed date.

• Months to add and days to add.

• Months to add and fixed date.

When a due date rule contains a date range, the system first calculates the due date based on the components within the rule, such as the months to add or fixed days. Then the system uses the date range to complete the calculation. For example, the system reads these components to calculate the due date on an invoice:

• Based-on date: invoice date of January 10.

• Months to add: 1.

• Fixed days: 1.

• Date ranges:

  • From day 1 to day 1 with days to add of 30.

  • From day 2 to day 31.

The system adds one month to the invoice date and uses the fixed days of 1 to calculate a due date of February 1. Then the system reads the first date range and adds 30 days to calculate a final invoice due date of March 3. Based on this setup, the second date range will never be used in the calculation.

Advanced Payment Term Codes

After you set up due date rules, you assign them to an advanced payment term code using the Advanced Payment Terms program (P00145). Advanced payment term codes are three-character alphanumeric values that identify the type of payment term. When you create advanced payment term codes, you can also specify the discount percent to use for the discount due-date rule that you assign. The system uses this discount percent unless you set up installment or multitiered discounts, in which case the system clears the value specified.

Installment Payment Terms

Instead of paying an invoice or a voucher all at one time, you can enter the transaction for installment payments by using installment payment terms. Like split payment terms, installment payment terms divide the transaction into multiple payments over a specified period of time. Unlike split payment terms, which divide the transaction evenly by a specified number, you determine the percentage of each installment and the percentage of the discount for each installment.

The system calculates the installment amount by multiplying the transaction's gross amount by the percentage that you define. The system calculates the discount due date and net due date of each installment based on the due date rules that you assign to it.

Because you can assign different due date rules to each installment, you can create unlimited variations of the amounts due, the discounts allowed, the dates by which payments must be received to receive a discount, and the dates on which the installment must be paid before it is considered delinquent.

These examples describe the different types of installment payment terms that you might set up:

This example uses an installment payment term for an invoice that is to be split into three installments:

Because the total percentage must equal 100, you must round the percentage of the last installment up as shown in this table:

When you enter the invoice for 9,000, the system calculates the installment amounts as shown in this table:

The system uses soft rounding when amounts do not divide evenly.

See Understanding Rounding Versus Soft Rounding.

Installment payment terms use due date rules to determine the discount and net due dates to assign to the transaction. The system uses the based-on date specified on the due date rule to determine the due dates for the first installment only. The system uses due dates of the first installment as the based-on date for the second installment, and the due dates of the second installment as the based-on date for the third installment, and so on.

For example, suppose in the previous example that you have these due date rules assigned to each installment to calculate the corresponding discount and net due dates:

Because you entered the invoice with an invoice date of July 15, the system calculates the due dates for each installment:

Multitiered Discount Payment Terms

Many companies want to reward their customers for early and prompt payments by allowing a greater discount based on the date that the customers remit their payment. Being able to change the discount percentage based on the date enables you to negotiate better terms with your suppliers and offer better terms to your customers.

You can set up advanced payment terms that allow the discount percentage to vary according to the number of days that have passed from the date that you specify as your based-on date for your due date rule. You can define up to five tiers of discount percentages.

For example, you might set up a payment term that allows a 10 percent discount if the payment is remitted within 10 days from the invoice date, a 5 percent discount if the payment is remitted within 20 days, and a 1 percent discount if the payment is remitted between 21 and 29 days.

To determine the discount due date for the first tier, the system uses the information that you provide on the due date rule. To determine the discount due date for subsequent tiers, the system adds the ending day of the tier to the based-on date specified.

To calculate new discount percentages and discount due dates for subsequent tiers, you must run either the Update A/R Invoices program (R005142) or the Update A/P Vouchers program (R005141).

Examples: Advanced Payment Terms and Due Date Rules

Because payment terms can be very complex, these examples might be helpful when you set up advanced payment terms that use a combination of date ranges and rules. All examples assume that you are using a work day rule that specifies actual (all) days in the due date calculation, as opposed to working days only. You use the Due Date Rule Revisions program to set up date ranges.

Example: Invoice Date

If the invoice date is between the 1^stand 15^th, set up a payment term that uses a fixed date of the 10^thin the following month. Otherwise, add two days to the invoice date if it is between the 16^thand 31^st.

Specify a date range for 1–15 that adds 1 month and has fixed days of 10.

The system calculates the due date to be the 10^thof the following month for all transactions that have an invoice date between the 1^stand the 15^th.

Specify a separate date range for each date after the 15^th:

Continue adding a range for each single day that adds two days through the 31^st.

Important! Do not set up a second range for 16–31 that adds two days. This is a common mistake. In this case, the system would calculate the due date on the 2^nd of the following month because it adds two days to the last day specified in the date range, which could be the 28^th, 29^th, 30^th or 31^st, depending on the month and year.

Example: GL Date

If the GL date is between the 1^st and the 10^th, set up a payment term that adds one month and five days to the GL date. If the date is between the 11^thand the 20^th, add one month to the GL date. If the date is between the 21^st and the 31^st, add one month and use a fixed date of the 31^st.

Specify a separate date range for each day between the 1^st and the 10^th:

Continue adding a range for each single day that adds one month and five days through the 10^th.

Important! Do not set up a range from 1–10 that adds one month and five days. This is a common mistake. In this case, the system would calculate the due date to be on the 15^th of the next month for all transactions with a GL date between the 1^st and the 10^th because it uses the last day of the range (10) and adds one month and five days to it.

Specify a date range for each day between the 11^th and the 20^th:

Continue adding a range for each single day that adds one month through the 20^th.

Specify a date range between the 21^st and 31^st that adds one month and has fixed days of 31.

You do not need to specify a separate range for each date because the due date is fixed.

Example: Prior to Invoice Date

Your company requires payment for goods prior to shipment. Set up a payment term that subtracts 10 days from the invoice date. Because the payment term is not dependent on a date range, specify –10 for the days to add.

Because the customer is prepaying for an item, the payment will be entered as an unapplied receipt until the invoice is generated. When the invoice is generated, it will be matched against the unapplied receipt. Allowing the calculation of due dates prior to the invoice date can help you manage prepayment billing. Additionally, you can use prepayment due date rules in installment payment terms if you need to manage different payment percentages in accordance with different due dates.