Why You Should Not Turn On Expected Cost Posting for Navision

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!

40 thoughts on “Why You Should Not Turn On Expected Cost Posting for Navision

  1. Rashed says:

    I don’t agree. It’s a great feature. If you don’t like it you have the option of not using it.
    There are many companies that use expected cost for freight for example.
    There are many other features that should not have been in NAV, but expected cost is a great feature that I use to solve many costing requirements.

  2. Alex Chow says:

    I don’t see how the expected cost posting feature deals with inventory costing? All it does is it post the accruals on the G/L side only. You can accomplish this using recurring journal at the end of the month to satisfy auditing/month end requirements. With a lot less resource consumed I might add.

  3. Jens Glathe says:

    Hello Alex, after some thought (and looking up in a CRONUS db 😉 ) I agree with you. For any document having to show the expected amounts, there seem to be fields which are already filled in. To show the amounts on a receipt or shipping document before invoice is no problem (unless you have to use RDL… :mrgreen: ). The masses of G/L entries are a bit of an overdocumentation in this case. SAP has this feature, too, and it seems to be pretty important for the accounting people. However, I can imagine one cases where the direct accruals in the G/L are useful, a top-down fast close scenario with consolidation. There will be other useful scenarios, but if you don’t need the accruals down to the transaction, then I would recommend your solution.

    with best regards

    Jens

  4. Alex Chow says:

    It’s hard to imagine why any company would need to accrual down to the transactions there are supporting documentation (Inventory to G/L Reconcile report) already in the system… Unless you’re consolidating 100 companies on your own, I still cannot recommend any companies to do this.

  5. Christian Ernst says:

    In manufacturing companies excpected cost posting is a must as I see it. Otherwise you have problems with WIP on finished production orders, that is in versions before 5.0 SP1 but I still think this feature is good.

  6. Alex Chow says:

    Expected cost when you analyze the inventory value is already in standard Navision inventory functionalities and it works very well. At any given point in time, you’re able to see WIP, shipped not invoiced, received not invoiced, etc.

    What I’m talking about is turning on the expected cost posting on the G/L level, which is unnecessary and causes burden on your database.

  7. Vasja Bojanic says:

    I also recommend to all my customers not to use this feature for the very same reasons you list. But there are situations when it is very useful. One of my customers does purchase of recycled materials, and by nature of this business, invoices come much later then actual goods, many times more then a month pass. In this situation mgmt wants to see expected purchase cost (and expected payables) every day, not just at the end of the month.
    As for the valuation of inventory and costs of consumption and cogs it has nothing to do with it, since value entries get expected cost regardless of this setting.

  8. Alex Chow says:

    Yes, but you can generate the expect cost reports (inventory to G/L Reconcile report) everyday. It only makes sense if the management wants to see the financial statement every day.

  9. Rob says:

    With my previous employer we used the expected cost and as an Acountant I have never seen a system which gives me better info then NAV.

    Therefore I think you have to listen to what your customer would like. Same as what Vasja says. We need mgmt info every day. As an accountant I would like to have a system which does my accrual, especially on product level, instead of doing this manually.

    Yes, you create a bigger db, performance will be a bit slower. we have judged that as acceptable, giving the info we get out of the system.

    I can imagine there are situations you would not need Expected costs but if you want:
    1. mgmt info every giving time of the day
    2. a 1-to-1 relation of logistics to finance.
    turn it on.

  10. Rob says:

    in addition on my previous post: I’m an accountant. You will notice that in this post as well.
    During education in Finance the basics of the information is posting the logistics according to the scheme which is used by Ëxpected costs. If a receipt is done, the financial registration of this is:
    Inventory
    @ Invoices to be received.

    As an accountant I want to have this entry both in Logistics and Finance.

    My conclusion: do not look at expected costs only as an IT professional where your trying to save disk space, performance etc.
    There are situations where companies do need the info provided by the expected costs.

    I can imagine especially in big companies with lots of transactions (like we are) you would turn it on.
    Doing accruals once a month is not realistic for these type of companies.

  11. Alex Chow says:

    I do understand the reporting requirements. My point is that the accrued cost that is posted by NAV will only create marginal value verse the maintenance of it.

    Perhaps I haven’t done enough implmentations, but I’ve never been in a company, public or private, that needs to report their financial statements on a daily basis. However, if it doesn’t make sense for your company to do these accruals manually based on supporting reports (2 journals), then by all means, turn it on.

    My arguement is that running reports (which you have to do anyway) and creating 2 journal entries per inventory account may be a better alternative. I do understand if a large corporate have 100 inventory accounts you have to journal into, that’s why there are tools like the recurring journals that helps you with these entries.

  12. ajmal says:

    Hi Alex, thanks for this method.I agree, having additional entries confuses the matter.

    I would like to try this out and have found the Inventory to GL Reconciliation report (ID10138.
    I will be grateful if you can confirm…Expected Cost Posting is unticked/ no need to add COGS interim and Inventory Accrual interim in Gen Posting Setup/ no need to add Inventory Ac interim in Inventory setup.

    Please advise…

    (Thanks)

    Ajmal

  13. Donavan D. Lane, ABC Computers says:

    Alex,

    I very much disagree with your opinion. With my 28+ years of implementing ERP systems, NAV is the only one that I have encountered that unfortunately will allow your Inventory on hand balance to be different that your G/L valuation on that inventory. Expected Cost Posting was introduced into NAV Version 3.01 when there was an outcry from resellers around the world that wanted to insure that there would always be an accurate G/L Balance to equal what was physically counted on-hand, without having to rely upon a reconciliation report.

    Let me explain the scenario of why it remains my opinion that it is always important to have Expected Cost Posting turned on, along with Automatic cost posting.

    Here’s what happens if you don’t turn it on. Shortly before the end of the month, say the 29th.. The General Ledger shows $90,000 balance in on-hand inventory. A purchase order is received that day for another $10,000 worth of inventory. On the 30th, the warehouse does a physical inventory. They count the items of the recent PO receipt. The physical inventory worksheet valuation total shows $100,000. They bring it back to the front office and where someone that’s not savvy enough to print the Inventory to G/L reconciliation report and needs to explain the difference. The discrepancy turns out to be an auditing mess every month.

    The amount of transactions this generates is insignificant to the overall disparaging issues of solving an audit difference each month, and especially at the end of the year!

    We want to see all of the PO Receipt G/L Transactions to show the audit trail of the inventory posted at the PO cost. In NAV2013 the amount of G/L transactions for dimensions is reduced by 95%, so there is little effect on what dimensions cause. This was NOT a function that was created out of necessity during the “feature wars”.

    We encourage all of our customers to TURN on expected cost posting.

    Donavan D. Lane, ABC Computers, Inc.

  14. Alex Chow says:

    Yes, this is why printing out the Inventory to G/L Reconcile report in Dynamics NAV and making the proper accrual entries based on teh report is so important. As stated in this article.

  15. David Cox (Adeptris) says:

    Hi Alex,
    I agree that it is of little use for most companies, it is a matter of choice and need, agreed it is not a big job to print the Received not Invoiced, Shipped not Invoiced reports, and they could post a recurring reversing accruals journal at month end for managagement reporting.

    We know a lot of management reports are created outside of Dynamics NAV then they do not have is a way of snapshot reporting, they cannot look at previous periods, like for like and trends.

    However we have used it for this scenario, a customer tht has high value “Goods on the Water”

    Vendor arranges and pays for transport to named port. Vendor delivers goods, cleared for export, loaded on board the vessel.

    Risk transfers from Vendor to the Company once the goods have been loaded on board, i.e. before the main carriage takes place.

    Seller also arranges and pays for insurance for the goods for carriage to the named port.

    However as with “Carriage and Insurance Paid To”, the rule only require a minimum level of cover, which may be commercially unrealistic.
    Therefore the level of cover may need to be addressed elsewhere in the commercial agreement.

    http://www.incotermsexplained.com/cost_insurance_freight.html

    They needed to know what they owned on the water for additional insurance and liability of the goods, some of which are in transit for 45-90 days.

    The accounts department need the value of goods on hand (in the warehouses) and goods on the water (in transit) for insurance liability and customs reasons, using different Inventory Posting Groups they can post to different interim accounts and make the calculations easy, and have an historic record of interim values for forecasting.

    They receive the Purchase for the goods taking ownership when they are dispatched, they can promise and reserve against the inventory and fulfill the Sales Order when the goods arrive.

    Regards

    David

  16. Alex Chow says:

    If the company owns the goods as soon as it’s loaded on to the ship, then they would need to create the on the water location to receive and invoice the goods in.

    In the case you mentioned, the Expected Cost Posting will not help you.

  17. Malcolm says:

    How does Alex’s solution post any fewer entries? When Expected Cost is on, it posts the 2 entries to the Interim accounts, and once Invoices, those are reversed and the actual postings take place. Alex suggests that you use a recurring journal to post the accruals, then reverse it. Isn’t that still posting the same number of entries as the when the function is turned on? I don’t see the difference, plus having to post the accrual via a journal will cause the user to spend more time posting and manually reconciling entries, ultimately spending more time processing rather than allowing the system to do it for them. If you process thousands of orders a day, this is a great option and the manual option is not viable.

  18. Alex Chow says:

    That’s incorrect. When you do accrual entries, it’s just 4 transactions at the end of the month. When you use Expected Cost Posting, it creates additional transactions PER POSTING!

  19. Sida says:

    I cannot do undo posted receipt?? It will prompt me error “You must specify Direct Cost Applied Account in General Posting Setup Gen. Bus Post. Group=’AM’, Gen.Prod. Posting Group=’SPAREPART’.

  20. Rob says:

    Is expected cost of any value to companies that implement standard cost? I have a situation where on a released production order, there is actual material cost that is the same as the standard material cost but the expected cost is zero….how could that be when all the required material is already issued to the job and the material variance is zero?

    Thanks,
    Rob

  21. michael carr says:

    If you do not use Expected Costs in NAV , then you cannot produce GAAP or IFRS compliant financial statements. Without the expected cost entries , the inventory and liability for purchase receipts do not get recorded until you process the invoice. And that that is not GAAP. And that , make NAV 2013 a second rate ERP package.

  22. Alex Chow says:

    Did you not read the article? You have to make the expected cost. My argument is that it should be done manually instead of automatically.

  23. Pieter de Vries says:

    Hi Alex,
    Great post. Still actual. It seems to me that report 10138 only suites trading companies using purchase and sales orders. It does not provide enough information for manufacturing companies to adjust WIP.
    The interim postings on ‘Inventory Account (Interim)’ hit three balancing G/L Accounts:
    – ‘Invt. Accrual Acc. (Interim)’ for purchase
    – ‘COGS Account (Interim)’ for sales
    – ‘WIP Account’ for production during output posting

    In report 10138 the ShippedNotInvoiced and ReceivedNotInvoiced are calculated based on the sign of the valued quantity. Should it not take the ‘Item Ledger Entry Type’ into account to provide all the information?

  24. Pieter de Vries says:

    In addition to my previous post: The Dutch version does not have such a report. 10138 is a great starting point and easily to extend/customize to provide the correct information.

  25. Peter Taylor says:

    Fascinating post. In manufacturing environments it is key to understand the breakdown of WHICH purchase orders from WHICH vendors are received but not invoiced at month end. This analysis is not possible if Expected Cost posting is turned off, which makes the decision for me (i.e. turn Expected Cost Posting ON). The Stock Received not Invoiced report is crucial to this process, without it I would now know who I expect to pay, and more importantly, I would lose the ability to report on my vendors who are delaying their invoicing to my business.

  26. Alex Chow says:

    The report you’re talking about is available even if you don’t turn on Expected Cost Posting. The calculation is done at the Item Ledger/Value Entry level, not the G/L level.

  27. Dennis Wong says:

    I understand what Alex try to mentioned.

    we all know turn it on will save a lot of user question but can we do a step more to have better balance between transaction volume and practical needed

    Let me summarize what key point mentioned.
    1. Expect Cost must be entered in system BUT mostly likely, most company do not require expected cost per transaction level, you can summarize it to month or to day.

    2. booking expect cost manually with tools help (recurring journal, report…). some argue that turn off will increase the workload for accountant, i think minor customize can be done to help them generate the entry (it should not difficulties) when run the inventory report. it is duty for accountant to do some checking when month end.

    please correct me if i am wrong.

  28. Ashaduzzaman says:

    Dear Dennis Wong & Alex Chow,
    This is very good suggestion to avoid the Expected Cost Posting & according to your suggestion I will turn off but what is Customization that we have to for Inventory report, please advise me.

  29. Jeff Landeen says:

    Now that I’ve seen more and more implementations go sideways due to user issues another consideration here may be risk. While it is possible for users to review reports and post adjustments on a periodic basis (say monthly) and properly account for the interim transactions without turning on expected cost posting. These user initiated entries are open to the risks of human error or incorrect calculations (or say not pay attention to things and post adjustments on the wrong dates). With expected cost posting turned on – NAV worries about making the appropriate entries. The unfortunate downside is that there are going to be extra GL entries posted and disk space consumed.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.