Category Archives: Inventory - Page 2

Inventory Value to General Ledger Reconcilation in Dynamics NAV

I recently signed up to be a guest columnist on the Microsoft Dynamics NAV community site. I wrote an article with the list of common steps to finding and reconciling the difference between your inventory valuation and the inventory G/L account. The article is posted in the Dynamics NAV Community site hosted by Microsoft.

The article is found here:
https://community.dynamics.com/product/nav/navnontechnical/b/navguestcolumn/archive/2011/09/12/reconciling-inventory-value-to-your-inventory-general-ledger-account.aspx

Again, the focus is to save you time so you can go home on time.

Accounting Cost vs. True Cost

In Microsoft Dynamics NAV, when doing costing and profitability analysis, you need to differentiate between a transaction’s True Cost and Accounting Cost. Don’t bother looking up these terms in the manual, I made them up for a lack of better terms.

To better explain the difference between True Cost and Accounting Cost, we will use this example:

8/15/08 – Item A was received at 10 pieces for $2.00 each.
8/30/08 – 6 pieces of item A was sold for $5.00 per piece
9/1/08 – The vendor invoice for Item A is posted at $3.00 per piece
9/15/08 – The freight invoice came in and item charge is used to allocate an additional $1.00 per piece
9/20/08 – The rest of the 4 pieces of item A was sold for $5.00 per piece

Accounting Cost:
Assuming on 9/30/08, you’re asked to do a sales analysis for the month of August. When the costing is analyzed for the sales made on 8/30/08, the COGS that accounting recognize will be $2.00 per piece. This means that if we’re printing reports based on Value Entry posting date filter from 8/1/08 to 8/31/08, the profit margin would be 60% per piece. Not bad! For accounting, the cost is indeed $2.00 per piece since that’s the only amount that was recognized in that period. (Some companies makes an accrual on the G/L side for the expected cost of good sold, but that’s a separate topic). This number to management, of course, is incorrect.

True Cost:
In actuality, the cost of the item should be $4.00 per piece because each piece came in at $3.00 with an additional $1.00 in freight charges. The margin of the item should be 20%.

Another scenerio is you’re running the sales report from 9/1/08 to 9/15/08, you would show 0 quantities sold, but the cost recognized in that period would be $12.00 ($1.00 in the additional vendor cost + $1.00 in the freight cost * 6 pieces sold). If you did not check this report and you present this report to the management, be prepared field a load questions on the integrity of both you and the numbers.

Solution:
Both Accounting Cost and the True Cost are correct! Do not assume otherwise! It’s just a matter of how the user wants to look at the numbers. For accounting, they need the numbers to be recognized in the proper periods so the previous period numbers does not get changed. For management, they want to see the true cost of sales transaction. What to do?

As a simple rule, the Value Entry stores the accounting cost, the Item Ledger Entry stores the true cost. Since most NAV reports dealing with Contribution Margin uses Value Entry table, we typically remove those field from the report because they are misleading for everyone. We create separate reports using the Item Ledger Entry table taking the Cost Amount (Actual) since it rolls up all the costs associated with the sale transaction.

One thing to note when presenting the report off of the item ledger to the management, depending on when you post the vendor invoice and other landed cost charges, the profitability number will change. This means that, in our example, the profitability report ran on 9/1/08 will be different than the same report with the same filters ran on 9/20/08. However, in my experience, once you properly explain this concept to accounting and management, they will understand.

[EDIT] You can also use the Value Entry table for calculating True Cost. However, just filter on the Valuation Date instead of the Posting Date.

Abnormal Posting Dates

Abnormal posting date entries happens when the Posting Date of the receipt/shipments of inventory is after the Posting Date of the invoice. Why does this happen? You’ll need to ask your CFO or Controller. Typically, I found this more in return orders where the receipt of the product is a certain date, and the accounting department decides to post the credit memo in prior dates.

Either by mistake or intentional, if this happens, your Inventory Valuation will not tie to your G/L.

Here’s a step by step on how to replicate this problem, and how to solve this problem:
1. Create a sales order with posting date of 11/01/08
2. Post the Shipment with a posting date of 11/01/08
3. Change the posting date to 09/01/08
4. Post the invoice
5. Run your inventory valuation report as of 9/30/08
6. Notice that the item is not taken out? But if you look at your G/L, the inventory value is taken out.

This will work for purchase side as well. It doesn’t matter how to do it either using warehouse shipment/receive, the underlying process will net you the same problem.

Usually, problems like this won’t come up until the user is trying to do month end and gets really frustrated on why their inventory doesn’t tie to G/L. Unfortunately, there’s no easy way to reverse this transaction after it’s posted, the only way is to run a report at the end of the period to see what transactions have this “Abnormal Posting Dates”.

Here’s a report that will give you all the transactions that have abnormal posting dates. If you take this amount, add/subtract it to your inventory valuation report, it will be equal to the G/L inventory.

To run this report, just put the period you want to close on the Posting Date field. For example, if you’re trying to close November 2008, then your Posting Date filter should be 11/1/08..11/30/08.

Here’ the link for the report:

http://www.mibuso.com/dlinfo.asp?FileID=920

Entering Beginning Inventory Balance

When moving from a legacy system into Dynamics NAV (Navision), one of the areas you want to try and avoid is messing with the inventory G/L accounts. Most systems are usually pretty good with open A/R and A/P accounts, they can be transferred using the “posting back to the same account” technique that most implementers do. The beginning A/R and A/P G/L accounts would be based on your entry on the General Journal. This is assuming that the A/R and A/P aging reports matches the G/L.

Inventory valuation is one of the areas where we find the most discripencies based on what is entered on the Item Journal  from the physical count and the inventory valuation report from the legacy system. Depending on your requirements, sometimes it doesn’t make sense to go through line by line on the item journal to see where the differences are.

A rule of thumb I always go by is to let Navision determine what the inventory value should be in the G/L based on the positive adjustments posted from the Item Journal.

To accomplish this, do the following:

Suppose you have the following G/L accounts:
11000 – Inventory
58850 – Inventory Adjustment

When posting a positive adjustment in the Item journal, it will post a debit to Inventory and credit to Inventory Adjustment.

When you’re ready to enter your beginning G/L balance, enter the G/L balance for Inventory to account 58850. This way, the difference between the inventory G/L balance from the legacy system and Navision will be reflected on account 58850.

If you do not want to reflect the adjustment in the current period due to financial reporting reasons, you can adjust the difference into an asset account. We usually recommend create a separate account (i.e. 11100 – Inventory Suspense) to store this difference until you can depreciate it.

By not posting any general journal entries to the inventory accounts, you’ve ensured that inventory valuation reports will ALWAYS match G/L, making everyone happy in the process.

Why you have Negative Inventory Value with 0 Quantity – Navision 3.7b to Navision 5.0

Here are a couple of reasons why you would get inventory value if you have 0 quantities when you print Inventory Valuation report and Inventory to G/L Reconcile report as of a certain date.

Scenario 1:

If the adjust cost is processed on 7/31/07, and the Allow Posting From was 7/1/07 on General Ledger Setup, the following would occur:

 6/15/07 – Purchase Receipt – $10
6/28/07 – Ship and Invoice – $10
7/15/07 – Purchase Invoice – $12
7/31/07 – Additional Cost for the sale made on 6/28/07 – $2

In this case, when you print the inventory valuation as of 6/30/07, the inventory quantity would be 0 and the inventory value would be 0.

Scenario 2:
If the adjust cost is processed on 7/31/07, and the Allow Posting From was 6/1/07 on General Ledger Setup, the following would occur:

6/15/07 – Purchase Receipt – $10
6/28/07 – Ship and Invoice – $10
7/15/07 – Purchase Invoice – $12
6/28/07 – Additional Cost for the sale made on 6/28/07 – $2

In this case, when you print the inventory valuation as of 6/30/07, the inventory quantity would be 0 and the inventory value would be -$2.00.

Explaination
Navision will automatically post the additional cost to the original invoicing entry because that’s where the cost originally applies to. If Navision detects that the Allow Posting From is before the adjusting date, then it will use whatever the Posting Date is when the adjust cost is ran.

Scenario 3:
If the adjust cost is processed on 8/31/07, and the Allow Posting From was 7/1/07 on General Ledger Setup, the following would occur:

6/15/07 – Purchase Receipt – $10
6/28/07 – Ship and Invoice – $10
7/15/07 – Purchase Invoice – $12
8/31/07 – Additional Cost for the sale made on 6/28/07 – $2

In this case, when you print the inventory valuation as of 6/30/07, the inventory quantity would be 0 and the inventory value would be 0. When you print the inventory valuation as of 7/31/07, the inventory quantity would be 0, but the inventory value would be $2.00.

Explaination
Navision will automatically post the additional cost to the original invoicing entry because that’s where the cost originally applies to. If Navision detects that the Allow Posting From is before the adjusting date, then it will use whatever the Posting Date is when the adjust cost is ran. In this example, since the Adjust Cost process posting date is 8/31/07, it will use this date as the Posting Date for the adjusting entry.