Quantcast
Channel: Dynamics NAV Financials » due date
Viewing all articles
Browse latest Browse all 2

Aging methods in NAV – which buckets are you looking for?

$
0
0

When running any type of financial report, it’s important to ask the right question in order to get the right answer. When running your accounts payable or accounts receivable aging reports, it’s especially important since there are three available options that will give you the same total answer but will break your transactions down into different aging bucket categories. Choosing the correct option for the question you actually want to answer is the key.

Question #1:  How overdue is the invoice?

By choosing the Aging Method of Due Date, you are asking NAV to age each bucket on your aging in intervals based on the Due Date of the invoice. Remember the due date is based on a calculation that applies payment terms against the document date of the invoice.

Question #2:  How many days have passed since the invoice was posted?

By choosing the Aging Method of Transaction Date, you are asking NAV to age each bucket on your aging in intervals based on the Posting Date. This is sometimes confusing to new users since on both the purchase and sales invoice forms, the two available dates are posting date and document date. The posting date should always be the date you want to post the invoice to your books and therefore the fiscal period the invoice will report in. For the purposes of your aging reports, posting date is equivalent to transaction date.

Question #3:  How many days have passed since the vendor billed us – or – since we billed the customer?

By choosing the Aging Method of Document Date, you are asking NAV to age each bucket on your aging in intervals based on the Document Date. This one makes a little more sense to folks because at least the terms are the same. But darn us accountant types, we often call the document date the invoice date when we’re referring to it. Basically, this date should be the date your vendor has provided on the invoice, or from the customer side, the date you shipped and therefore the date you provided on the invoice to the customer. Any payment terms defined on the account will use the document date to calculate the due date.

An example of two invoices shown with all three aging methods

In a perfect world, our posting dates and document dates would all be the same. Let’s pick a perfect example with posting date of 11/01/10 and document date of 11/01/10 and payment terms of Net 21. This would calculate a due date of 11/22/10 on this invoice.

Then let’s pick an imperfect example. Let’s pretend someone at our company turned in that 11/01/10 invoice sometime in December, after the November books were closed. We still need to book this late invoice, so we’ll choose a posting date of 12/01/10, but since it was not the vendor’s error, we’ll use their invoice date of 11/01/10 in order to calculate the payment terms correctly.

Now, let’s look at an aging as of December 15th, 2010, all three ways. Take note that for all three methods, the balance due is exactly the same. The differences appear in how the aging buckets are defined and how transactions age into the different buckets.

Aging Method of Due Date

Key difference here is the aging buckets start calculating at the due date, so you’ll see column headers of current, up to 30 days, 31-60 days and over 60 days only when using this aging method.

Aging Method of Transaction Date

This aging is based on the posting date, the date that corresponds to the fiscal period you posted the invoice in. Note the late invoice with a 12/1/10 date shows as current.

Aging Method of Document Date

This aging has the same buckets as the one run with transaction date, but is based on the document date or invoice date.



Viewing all articles
Browse latest Browse all 2

Latest Images

Trending Articles





Latest Images