I am reviewing a whole fiscal year and I can see that from Summary the total COGS is not exactly the same as the one showing for the same period in the Cost of Sales column in the Inventory Value Movement report.
Shouldn’t the two figures be the same?
I have looked at the Cost of Sales of some items and they appear the same in both COGS from Summary and in the Inventory Value Movement. Could there be some errors in the calculations for some items?
I don’t think I have any of those. I have checked for example the numbers for 2016 and all orders placed in that year entered the stock in 2016 and all related costs were also captured in 2016. When it comes to deliveries, they are done together with the invoices, therefore they have the same dates and there is no invoice for example in 2016 with a delivery in 2017 (or vice versa).
You don’t have to think. You can know. Look in the Inventory Items tab under Qty to receive and Qty to deliver.
You may also have issues with backorders, items that were sold before they were on hand.
Resolution of your problem lies in what you wrote in your first post:
You are going to need to look at all items to discover which disagree. Then you can begin tracking down why they disagree. But it is impossible to troubleshoot from verbal descriptions of a problem like this.
Quantity to receive and quantity to deliver is something whose values are only as of today. They cannot be showed as of end of last year of for a specific time period. So if I want to look at last year’s COGS it is not possible to go that way. Correct?
Well this is not a funny thing to do. I wish there was an easier way to do this…
If you drill down on the figures in the Inventory Items tab, you will see the customers/suppliers contributing. Then you can drill down on those figures to see specific transactions. Hopefully, you just have a few entries that are causing this problem. If not, you are probably doing something incorrectly on a systematic basis. In that case, exploring a few transactions should reveal the problem. Then, you can probably resolve it with batch operations.
I found where the difference is. For 2 items (bought at the same time, entered the stock at the same time, invoiced and delivered to clients at the same time) the two Purchase Invoices for their transport costs have dates that are earlier than the Sales Invoice through which we sold them. This is because sometimes our logistic company gives us credit and invoices us once the goods are delivered.
This creates what I mentioned in another post as “ghost lines” with 0 values.
The costs related to transport gets then allocated to the COGS and in it appears with the description “Quantity on hand for this item is zero. Value on hand automatically transferred to expenses.”
But these specific costs do not appear in the Value Movement Report.
However, if the quantity on hand does not become 0, the “ghost line” do not appear and the figures for an item in the COGS and the Inventory Movement Report match:
I understand there might be valid reasons for this, but it is quite normal, I think, that suppliers issue invoices much later than when their services/products are supplied. I think this should be taken into consideration too.
Now I wonder whether these values that are not used in the Inventory Value Movement Report are not taken in consideration even in the Inventory Profit Margin Report?
Yes. If you have an inventory item with zero quantity, then it can’t have any money value.
So when you post a freight-in to that zero inventory item it gets expensed as per the noted description.
Manager doesn’t know and will never know if that freight-in charge was even posted to the correct inventory item or that it should be associated with any following purchase invoice for that inventory item.
Therefore to resolve this, both the reporting and the ghost line issues, you need to do as advised in that other post, put the prior dated freight-in charges to a holding clearing account and then re-allocate within the purchase invoice. It is simply this - your data therefore it’s your control - Manger is just a processor not a predictor.