Urgent: Automatic vs Expected Cost Posting: inv Setup

On jan1 we switched from Automatic Cost Posting to Expected cost posting due to the fact that our cost were so off. Somtimes it takes 3 to 4 weeks for the vendor invoice to arrive and our costs on the PO are correct so we wanted the system to use those costs instead of waiting.

Our accountant is now seeing that our profit margin if way off by $100,000 (approx) for April & may is off too.

I was wondering if the switch could have contributed to this difference. I have just noticed that someone ticked automatic cost posting so now we have both ticked. Is this a problem? Why would nav allow both to be ticked if it wasn’t ok to do so?

I’m just wondering if both are checked if something is being done twice?

with expected we are still running the adjust cost & post to g/l batch jobs.

any thoughts would be very very apprecicated

Original disscussion here


Nav 3.6


My understanding is that if you do not have automatic cost posting ticked but expected ticked then the expected are ONLY updated, with the costs, when you post the batch routines. With both ticked the expected is posted upon receipt (and sale) and the batch jobs sweep up the differences between invoice and receipt etc.

However if you start switching these on and off with open transactions you are probably going to cause issues. I will explain with an example:

I start with expected cost on and automatic off.

I book in a purchase order for 100.00. Naturally the GL entries do not exist as I have automatic cost posting OFF. I now turn automatic cost posting ON. I process the purchase invoice. The automatic cost posting does what it always does and reverses the expected costs but we never had any! I am not sure if the adjust cost item entry will flush this through or not. Then you have the other side with the sales, you should be posting expected costs, and when you invoice the sales order and eventually invoice the purchased goods it will reverse the expected costs, but these will be costs you never posted!

I think you should try running it through and seeing if the batch jobs catch up. I have a feeling that they will not which means every transaction processed between automatic off and on is going to have an incorrect impact on the expected costs (wherever you are posting these).

I hope it is not like this for you.

I would guess that the Post Costs to G/L batch job would correct the issue that Steven explained wrt the Invoice reversing the costs. The batch job would see that the Cost Posted to G/L (something like that) is different to the Value Entry cost for the Receipt and post an adjustment to G/L.

The only situation I can think of right now that may cause a problem is: Post a Receipt with the Expected Cost on. (Assume that Automatic Cost posting is on or the batch job was run)
The Expected Cost posting is now switched off and the Invoice is posted. I’m not sure whether Navision will reverse the entries out of the interim account because it will now think that you never posted them?

Hope you manage to sort it out. I know how much of a pain Inventory Costing can be!!

You should be able to see the extra dollars in the interim account if they didn’t clear, that is if you have a different g/l account for it, which you should.

This is what I figured but i needed to know I wasn’t crazy - thanks. The accountants usually want the easy/quick answer instead of digging thru the thousands of g/l entries to find mis-postings.

I’m trying to narrow down our problem, so I’m going thru all possible recent changes.

I’ve already found some wrong journal postings, which I believe is the real problem we have.


Curiosity Question: When you (Solution Center peeps) setup a customer what is the setup you usually use?

Is it generally Automatic?

The two setup fields “Automatic Cost Posting” and “Expected Cost Posting” serve different purposes. If “Automatic Cost Posting” is turn on, then inventory cost enries are automaticly posted to G/L. If it is off, then you must run “Post Inventory Cost to G/L”

“Expected Cost Posting” determines whether or not “Expected Cost” are posted to the G/L.

I think without exception in the past few years these have both been ticked for our customers.

Yup, we turn them both on.

In the past, turning off “Expected Cost Posting” was recommended to improve inventory postings. This reduced the number off entries generated during posting, but it also makes reconciling the G/L more difficult.

I generally turn both on, unless there is a compelling reason not to.

I’m not going to quote and reply to each post here, so I will repeat some of what has already been said, so sorry in advance.

The most important thing (as pointed out already), is that these two fields do two completely different things, and have no connection what so ever to one another. Please don’t try to find a relation ship between them. Further, there is not connection between the “Automatic Cost Posting” function, and the Inventory Adjust Cost routine. Automatic cost posting refers ONLY to the Post Inventory Costs To G/L routine.

As to the norm for customers. Every customer is different, and there is no standard of whether either or both of these should be selected or not. So one at a time.

Automatic cost posting all this does, is tells codeunit 22 that once a value entry has been created, to call the “Post Inventory Cost” routine for that Value Entry, this will post the current estimate of cost to the G/L In virtually every scenario, it is NOT a replacement for running the Adjust Cost and Post Cost routines. You should still be running the adjust cost routine regularly. If you use FIFO, and your purchase orders have the EXACT cost already, AND you always purchase items before selling them, then the Auto Posting may generate the correct costs. A very large percentage of Navision users that I have seen set this flag. mainly because they want to see the G/L reflecting Inventory in real time.

Expected Cost Posting. This is in it self a complete set of functionality. Basically in Navision, the receipt or shipment of an Item has no effect on the G/L. It is only the invoicing (or vouchering) of these shipping/receiving documents that will affect G/L. The reason, is that G/L entries are related to Value Ledger entries. Inventory movements create Item Ledger Entries, NOT Value Entries, so there is nothing to affect the G/L. What this means, is that you will now have a significant imbalance between your G/L and Inventory. To address this, you can set the Expected cost posting. What this does is create a dummy Value Entry, which has the current best estimate of cost, and this is posted to the G/L, but using different G/L accounts than the standard G/L accounts. These are the Interim accounts. Now when reconciling inventory to G/L, these accounts will explain a lot of the imbalance. BUT there is one slight issue, in fact almost a bug. (Harry, this is probably what you are seeing). The Expected cost function will record in the interim accounts an estimate of COGS, but it does not post an interim value for Revenue. SO if you Shipped $100 of goods with a sales value of $130 to a client, you will see a cost of $100, but no matching revenue. So now all of a sudden it looks like the company is making a huge loss out of no where. If you invoice your clients very quickly, then the issue is minimized, but it is definitely a problem. To get around this, I prefer to write a new function that generated Interim Revenue (which I post to a B/S account). This then makes the numbers more understandable. At the minimum,. create a report that prints out Goods Shipped not invoiced, so you at least know what the number is.

As to the question of turning on the Expected cost posting option, you can safely turn it on or off anytime you want. The Expected cost Entries are flagged in the system, and will be fully reversed when the true cost is known, EVEN IF the value is the same. Also running the Adjust Cost Routine, will go back and create Interim Value entries for all open shipments and receipts, so its safe to turn on or off, just be aware that it will post a lot of data, and can substantially increase the time your adjustment routines take to run.

Oh and one more thing on the question of What is standard for NSCs to do." This is a wrong question. It really depends on the client, there should never be a case of an NSC that “always does it a particular way”, unless you are dedicated to one specific vertical market.

Always as an NSC,discuss these options carfully BEFORE they Go-Live, and make sure they inderstand the impact.