When it comes to processing receivables, it’s the little things that matter. Payment terms seem pretty straight forward, but I’ve come across many companies whose requirements for payment terms are not simple or straight forward. The good news is, NAV can handle almost all of them. In fact, I’ve only run across one specific payment term that I haven’t been able to calculate.

What does the Payment Terms field do and how does it work? In its simplest form, Payment Terms tell you when your Customers need to pay you; it calculates the Due Date. But it’s so much more than that. To start with, the Due Date that is calculated is driven by the Document Date in your Sales Invoice. When posting a Sales Invoice, you can drive what period an invoice posts to with the Posting Date and what the Due Date will be with the Document Date. Additionally, if offer a payment discount (i.e. 1% discount if paid within 15 days) to your Customer, the Payment Term assigned to that Customer and Sales Invoice will drive the calculation for the discount during payment.

Here you can see in the Customer Ledger entries the original Posting Date, Due Date, and Pmt. Discount Date.

To set up Payment Terms, you will need to identify the following things for each term:

**Code:**A 10-digit alphanumeric code to identify the code for the term.**Due Date Calculation:**Specify the number of days after the Document Date the invoice is due.**Discount Date Calculation:**Specify the number of days after the Document Date an invoice needs to be paid by in order to receive the discount identified in the Discount % field.**Discount %:**Specify the discount percentage to be calculated if paid by the Discount Date.**Calc. Pmt. Disc. On Cr. Memos:**If this box is checked, the system will calculate discounts on Purchase Credit Memos.**Description:**Specify the description for the Code. Like the Code field, a style guide for descriptions should be created as it will be printed on documents where the Payment Terms are used.

Some of the most common payment terms are below:

**Net XX Days** – Payment is due at XX number of days.

**Due Upon Receipt / Cash on Delivery** – Payment is due upon delivery of the goods or upon receipt of the invoice.

**X% Discount / Net XX Days** – Payment is due at XX number of days with a discount if paid early.

Of course, nothing is as simple as that, right? Perhaps you want to be paid at the first of the month, regardless of the document date. Or the end of month. Below are examples of some of the less common examples.

**DAY15** will give us the 15^{th} of the month. If the Document Date falls between the 1^{st} and the 14^{th} of the month, the Due Date will be the 15^{th} of the current month. If the Document Date falls between the 15^{th} and the 31^{st} of the month, the Due Date will be the 15^{th} of the following month.

**MNTHBEG** will give us the Due Date for first day of the following month, where CM-3D will give us a Due Date that is 3 days prior to the end of the current month. **MNTHEND** will give us the last day of the current month as a Due Date. These terms may be useful for Vendors that require payment at the beginning of the following month, such as Rent, depending on how you pay them.

**2MNTHDAY15** gives us the 15^{th} of two months in the future for dates that fall between the 1^{st} and 14^{th} of the month. Dates 15^{th} through the 31^{st} will give us the 15^{th} of three months. For example, a Document Date of 1/1/18 – 1/14/18 will calculate a Due Date of 3/15/18, where a Document Date of 1/15/18 – 1/31/18 will calculate a Due Date of 4/15/18.

As you can see, NAV can handle some pretty advanced Due Date calculations. To date, the only calculation I have not been able to find a solution for is driven off the idea of an if/then statement. If a Document Date is between the 1^{st} and the 15^{th} of the month, the Due Date is the 20^{th} of the current month. If a Document Date is between the 15^{th} and the 31^{st} of the month, the Due Date is the 10^{th} of the following month.

In this case, you have a couple of options, shown below.

First, the Due Date is editable both in the Sales Invoice and the Customer Ledger entries for a Customer. Create a manual Payment Term (**MANUAL**). This will remind your users to enter a Due Date manually (note: It will default with the same day as the Document Date).

Here you can see the Due Date in the Customer Ledger Entries is the same as the Posting Date.

Click on the Edit List option in the Ribbon and enter correct due date.

Second, the Payment Terms field also is editable in the Sales Invoice. Create two Payment Terms that your users will update depending on the Due Date required. Term **1MNTHDAY10** will calculate the 10^{th} day of the next month and **DAY20** will calculate the 20^{th} day of the current month. DAY20 will calculate the 20^{th} of the current month, regardless of the Document Date (for example, 1/25/18 will calculate a Due Date of 1/20/18).

Regardless of how simple or complicated your Payment Term requirements are, it’s important to remember how all of these fields are dependent and related to each other. The Document Date is the basis for the Due Date calculation, which is driven by the criteria in the Payment Terms.

Stay posted for the next blog in this series to learn about Payment Methods and how your Payment Terms might change depending on what method of payment your customers use to pay you.

## Leave a Reply