Inventory Best Practices in NAV
*This post was written for Dynamics NAV but the content also directly applies to Dynamics 365 Business Central. You may notice some slight differences in the screenshots, but the information and steps still apply.
In this post, I’ll point out some of the more common inventory best practices in NAV I’ve suggested to my clients over the years. Taking the steps outlined below will definitely make for a smoother reconciliation process down the road.
Inventory reconciliation in NAV tends to be a more challenging process when compared to the reconciliation of the other sub-ledgers. For starters, NAV allows the flexibility of breaking out inventory-related postings to separate G/L accounts per location. Further complicating matters is the fact that inventory costs tend to be a moving target, especially in FIFO, LIFO, or Average costing environments. Since actual inventory cost may not be known at the time of the inventory posting, a portion of your overall inventory value can be sitting in “interim” accounts. That said, if you are using multiple locations with the “Expected Cost Posting” feature enabled, you’ll end up having quite a few GL accounts to consider at reconciliation time.
In a later post, I’ll discuss the value of using the “Inventory to GL Reconcile” report when conducting inventory reconciliations. But, for this post, let's get to the inventory best practices for NAV.
Disable the “Direct Posting Allowed” setting on all inventory control GL accounts. - Disabling the “Direct Posting Allowed” feature for the inventory, interim inventory, COGS, Direct Cost applied, and WIP accounts will ensure that no user is allowed to manually “plug” numbers into these accounts without a supporting inventory ledger posting.
Avoid mapping multiple posting sources to a single GL account. - Within NAV’s posting setup pages, mapping different types of postings into the same GL account can cause major problems at reconciliation time. For example, mapping a single GL account for use as both the “Inventory” and “Interim Inventory” accounts negates the benefit of tracking expected costs and makes reporting/reconciling difficult as you end up with apples and oranges in the same bucket. A suggestion that I commonly make to accountants getting started in NAV is to spend a few minutes checking all of the control accounts (AR, AP, Bank, Inventory, etc.) by using the chart of the account’s “Where-Used List” feature. This feature can be used to quickly find out what posting sources are mapped to a given GL account.
Pay attention to costs on positive adjustments. - With a negative adjustment, the cost entered on the item journal line is irrelevant as NAV will use that item’s costing method to figure out the appropriate outbound cost. When posting positive adjustments, however, the cost entered on the item journal line is extremely important as it’s the cost that NAV will use to value the inventory. For example, a common mistake occurs when a user mistakenly keys in a “case” cost when positively adjusting using the “each” unit of measure, etc.
Make use of the “Revaluation Journal”. - When trying to correct an inventory costing error, oftentimes a user’s first instinct is to start posting more positive and negative adjustments to correct the original mistake. In most cases, the “Revaluation Journal” offers an easier approach. The beauty of the revaluation journal is that it allows you to “revalue” the cost assigned to the initial positive entry. From there, NAV will trickle this adjusted cost down to any outbound movements of inventory that had originally pulled the incorrect cost.
Set the item’s “Base Unit of Measure” to the smallest unit you’d like to process with. - For example, If you were to set up an item with a base unit of measure of “Dozen”, but then later needed to sell it by the “each”, you’d be forced to sell .0833333 DOZEN whenever you needed to post a transaction in “each”. Tracking inventory in decimals is never a good idea. Instead, setting up the item with a base unit of measure of “each” and a secondary unit of measure of “Dozen” would allow you to conduct all transactions in whole numbered units.
Strive to set up one item card per item. - A single item (card) in NAV is made to be set up to handle multiple: units of measure, buy-from vendors, locations, shelves, colors, reordering policies, etc. In a situation where you are tempted to create a duplicate item card, first consider whether simply adding a new: unit of measure, variant, non-stock item, location, stock-keeping unit or cross-reference record would suffice. Reports become more useful and physical inventory counts tend to go much smoother in a system where a given item is only set up in the software once.
Avoid setting up generic items. - From my experience, setting up generic items can cause more trouble than they are worth. Counting such items can be nearly impossible. Further, unless the item is serialized or has a very flat cost fluctuation, recording reasonable COGS on sales of generic items can be challenging at best.
Understand the implications of enabling the “Automatic Cost Adjustment” feature. - In an earlier post, I described the “Automatic Cost Adjustment” feature. While your order entry person(s) may not be aware of it, with this feature enabled, NAV can/will post additional inventory adjustments that isn’t even related to the document that the user is currently trying to post. Due to the great benefit of keeping a more real-time account of inventory costing, I almost always recommend enabling this feature. That said, I typically make two additional suggestions.
- Roll both the “General Ledger Setup” and “User Setup” posting date restrictions forward together. Since NAV looks to the “General Ledger Setup” posting date restrictions when determining what posting date to use on inventory costing adjustments, as a general rule, I suggest that the “General Ledger Setup” posting date restrictions be moved forward at the same time that the user-specific (user setup) posting date restrictions are rolled forward. This will ensure that your users won’t have to deal with confusing posting date errors that reference mysterious posting dates.
- Block dimension values sparingly. Keep in mind that when an inventory adjustment (a new value entry) is posted, NAV will attempt to make the posting with the same dimension values that were used on the original inventory movement (item ledger entry). That said, blocking dimension values tends to cause issues downstream when NAV attempts to post adjustments with a dimension value that has been blocked since the original posting occurred.
Consider Exact Cost Reversing. - In an earlier post, I discussed the concept of “exact cost reversing” and described how this feature can be used to keep costs on inventory returns in sync with the cost associated with the original sale. For some of my clients, especially those that have considerable cost fluctuations per item, this feature is a big plus. For others, the effort of enabling the feature outweighs the potential benefits. Either way, it’s worth considering whether or not this feature is right for you.
Under the terms of this license, you are authorized to share and redistribute the content across various mediums, subject to adherence to the specified conditions: you must provide proper attribution to Stoneridge as the original creator in a manner that does not imply their endorsement of your use, the material is to be utilized solely for non-commercial purposes, and alterations, modifications, or derivative works based on the original material are strictly prohibited.
Responsibility rests with the licensee to ensure that their use of the material does not violate any other rights.