Overview
The ERP software business is a very competitive business. If the software company does not devote a lot of their resources into research and development of the product, it becomes outdates very quickly. Therefore, when choosing to purchase an asset that is the lifeblood of your organization, it’s very important to not just consider how well the product and serve your company, but also the company behind the product.
Having said that, there are also a lot of features that are developed because “the competitors have it”, not because it makes good operational sense. These features are important in sales demos and feature comparison analysis for end users looking to purchase a new system.
One of these features in Dynamics NAV, in my opinion, is the Expected Cost Posting feature in Dynamics NAV. The reason is not the feature itself, but the amount of useless data it generates. This article will exam this feature a little closer and give you some informed decision on how you should configure this for your company.
What Does the Feature Do?
According to Dynamics NAV help, this is what the feature does:
Expected costs are the estimate that you make of the cost of, for example, purchasing an item before you actually receive the invoice for the item.
You can post expected cost to both inventory and to G/L. Whenever you post a document, such as an order or a journal, as received or shipped, a value entry line will be created with the expected cost. This expected cost will affect inventory value, but it will not be posted to G/L unless you have set the program up to do that.
Basically, this feature accrues the values of the inventory that you receive (and ship) that has not been invoiced yet. Sounds great! This is in compliance with GAAP (Generally Accepted Accounting Principles), you should match up the value of your inventory to the G/L. Having this checked, on the G/L entries are created for you automatically.
NOTE: This feature DOES NOT have ANYTHING to do with your inventory cost and how it’s valued! Do not get it confused! This feature is STRICTLY for Navision to post expected cost the G/L.
In practice, this is what the feature does. Consider the following purchase order:
I’m using the CRONUS database with item 70001 and 70002 as our example.
If you create a purchase order and post the Receipt, it creates the following transactions. This is done by Navigating on the Purchase Receipt and showing the G/L Entry table:
As you can see, the system creates 2 additional transactions per item. One goes to the Inventory Interim account specified on your Inventory Posting Setup and the other entry goes to the Invt. Accrual Acc. (Interim) account specified on your General Posting Setup. If you do not turn on the Expected Cost Posting, no G/L transactions are posted.
Now let see what transactions are created when when the purchase invoice is posted.
When invoice, it creates 2 additional transactions per item. The same entries as what we did on purchase receipt, but this entry effectively reverses out the entries in the interim accounts.
For normal transactions for items that are received, there are no G/L Entries created. When you post the invoice, the Direct Cost Applied and the Inventory are hit per item. Then 2 transactions are created for the whole invoice for Purchase and Accounts Payable.
The functionality works on the sales side as well. So if you do post sales shipment and sales invoice, the number of transactions occur the same way except using different G/L accounts.
If you do the math, with Expected Cost Posting turned ON, you’re creating 40% of additional transactions per entry when you post a purchase invoice! In addition, you’re creating additional entries when you post the purchase receipt.
The number of transactions increases significantly if you use Dimensions!
Why is it a Waste of Space?
Space is cheap, we all know that. But even if storage is cheap, I’m still a firm believer that you should only keep track of data that’s of some value.
Having Navision post these additional transaction, in my opinion provides no value and typically adds to the confusion of the company using it. Not to mention that it creates additional work for the accounting folks if all of a sudden accounts are off because someone decided it was a good idea to turn on Direct Posting for those accounts. Or if a bad implementor decided it was a good idea to turn on Expected Cost Posting without closing all the outstanding orders.
In addition, think about your back up. By creating an additional 40%+ of transactions per purchase and sales order, you’re making your database size bigger than it has to be. And we all hate dealing with large files and all the problems that it comes with.
How do I Get the Expected Cost for Accrual Purpose?
That’s easy. There’s a outstanding report in standard Navision that’s there since version 1.x called Inventory to G/L Reconcile. This report gives the figures for receipt not invoiced and shipped not invoiced. The example of the report from our example above:
All you need to do is take that amount and book your accruals accordingly. You can set this up on the Recurring Journal easily enough so you post the accrual entries, and the system will automatically reverse it out on the next period. Look at the Recurring Method in the Help file if you’re not sure what I’m talking about.
Since we highly recommend (I should say mandate) our clients to turn off direct posting to Inventory, COGS, Purchase, etc accounts, we usually ask them to create separate account for accrual purposes, just like the example in the CRONUS company.
Conclusion
I truly believe this is a function that was created out of necessity during the “feature wars” of the ERP software. Ultimately, the “feature war” is good for the ERP software consumers because it forces ERP software companies to invest, or be phased out. However, in practice, not all of the features should be implemented just because it sounds like a great idea.
A good Navision consultant should walk you through these key features and what impact it has. The person should have enough knowledge to know where the pitfalls are so you’re not wasting your time going through every little feature in the system.
The balance of what needs to further explanation and what doesn’t is really up to your Navision consultant. And the way that the Navision consultant should know these is through experience. If your Navision consultant is new or not that experienced, just reading from the manual, he/she will think that this is a great feature and a must, just like the end users!
