When it comes to processing payables, 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 to pay your Vendors; 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 Purchase Invoice. When posting a Purchase 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 a Vendor offers a payment discount (i.e. 1% discount if paid within 15 days), the Payment Term assigned to that Vendor and Purchase Invoice will drive the calculation for the discount during payment.

ap1

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

ap2

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.

ap3

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

ap4

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

ap5

Of course, nothing is as simple as that, right? Some Vendors 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.

ap6

DAY15 will give us the 15th of the month. If the Document Date falls between the 1st and the 14th of the month, the Due Date will be the 15th of the current month. If the Document Date falls between the 15th and the 31st of the month, the Due Date will be the 15th 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 15th of two months in the future for dates that fall between the 1st and 14th of the month. Dates 15th through the 31st will give us the 15th 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 1st and the 15th of the month, the Due Date is the 20th of the current month. If a Document Date is between the 15th and the 31st of the month, the Due Date is the 10th of the following month.

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

ap7

First, the Due Date is editable both in the Purchase Invoice and the Vendor Ledger entries for a Vendor. 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).

ap8

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

ap9

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

ap10

Second, the Payment Terms field also is editable in the Purchase Invoice. Create two Payment Terms that your users will update depending on the Due Date required. Term 1MNTHDAY10 will calculate the 10th day of the next month and DAY20 will calculate the 20th day of the current month. DAY20 will calculate the 20th 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 you will be using for a Vendor.