HOW-TO: Adjusting Costing Method STD to AVG

[zvanmeter]

Heyo,

This weekend we converted one of our companies from Standard to Average, and I am going to document how we did it. We didn’t like standard costing for a lot of reasons, so if you’re also ready to switch, I hope this post makes it easier. We worked with an Epicor consultant to develop this process, so big thanks to @KSK!

Our goal was to replace every average cost in our system with the current standard cost, and allow the parts to naturally adjust from there. We wanted to demonstrate that this was done “correctly” by having $0.00 impact across the transition. This method worked for us. If you wanted to jump right from Standard to Average, you could skip running the APICostAdjustmentNonInv BAQ / DMT both times.

I am also attaching all of our DMT ready BAQs that you could import if you wanted to do this yourself.

I ran these BAQs via the API which is why they are all named APIxx, but they’re just regular BAQs that you can run however you like.

We send our production teammates home by Saturday morning. This process took from 9am-5pm, but most of that time was us being careful and and double checking some oddball normal operations things.

1. Before you begin, you can move over parts which aren’t in inventory. This is a time saving measure, If you have tens of thousands of parts, you can run these the night before to save time
   1. Adjust the cost to standard on parts which we dont have in inventory (APICostAdjustmentNonInv)
   2. Change Cost Method (APIPartCostingMethodNonInv)
2. While no one is transacting
   1. We reconcile any labor issues (Unapproved Labor)
   2. We resolve any negative on hand quantities (Quantity Adjustment)
   3. Ensure that no inventory is picked, allocated, or packed (Unpick SO, Fulfilment Workbench, Customer Shipment Entry)
   4. Clear everything out of Receipt Inspection (Inspection Processing)
      1. All Sites !!!
   5. Run all bold BAQs right now. You’ll need to run APICostAdjustmentNonInv & APIPartCostingMethodNonInv a second time after we adjust inventory, during step 5. You’ll also run both APIPartClassReference & APIPartPlantReference as confirmation in step 5.
3. Get a solid starting point
   1. Run Inventory/WIP Reconciliation, Stock Status
   2. Run Capture COS/WIP Activity
      1. Check the “Post to General Ledger” checkbox to TRUE
      2. Check the “Post Cost of Sales / MFG Variance” to TRUE
   3. Run Inventory/WIP Reconciliation again, which should error
4. Taking the inventory out:
   1. Adjust all inventory out. (Quantity Adjustment / APIAllInventoryNegative)
   2. Run Inventory/WIP Reconciliation, Stock Status
   3. Run Capture COS/WIP Activity
      1. Check the “Post to General Ledger” checkbox to TRUE
      2. Check the “Post Cost of Sales / MFG Variance” to TRUE
   4. Run Inventory/WIP Reconciliation again, which should error
5. Change the Costing Method…
   1. Change the costing method on the (Company Configuration)
   2. Change the costing method on the Part (APIPartCostingMethodNonInv)
      1. The costing method on the Part Plant is updated automatically, but at this stage, run both of these to confirm APIPartClassReference / APIPartPlantReference
6. Bringing it back in
   1. DMT the Standard costs into Average (Cost Adjustment / APICostAdjustmentNonInv)
   2. DMT Inventory Adjust our units back in (Quantity Adjustment / APIAllInventoryPositive)
   3. Run Inventory/WIP Reconciliation, Stock Status
   4. Run Capture COS/WIP Activity
      1. Check the “Post to General Ledger” checkbox to TRUE
      2. Check the “Post Cost of Sales / MFG Variance” to TRUE
7. Reset our Job Estimated Costs
   1. I was lazy here, and I left in a calculated field “TotalJobCost” which is a column you will need to delete in order to import these BAQs.
   2. Un-release and un-engineer all open jobs that have no cost allocated yet. (APIJobUnrelease)
   3. Re-release and re-engineer all those jobs (APIJobRelease)
8. Resume normal operations!

Here’s the goods.
APIAllInventoryNegative.baq (16.7 KB)
APIAllInventoryPositive.baq (15.8 KB)
APICostAdjustmentNonInv.baq (8.8 KB)
APIJobRelease.baq (17.0 KB)
APIJobUnrelease.baq (17.0 KB)
APIPartClassReference.baq (8.2 KB)
APIPartCostingMethod.baq (13.7 KB)
APIPartCostingMethodNonInv.baq (7.9 KB)
APIPartPlantReference.baq (8.5 KB)

[utaylor (Utah Taylor)]

Nice work @zvanmeter! Well documented too, thanks a ton for sharing! Another win for @KSK too! Been a minute since I have worked with Kimberly!

[knash (Ken Nash)]

Thanks for writing this up — this is exactly the kind of real-world walkthrough that’s hard to find, and the DMT-ready BAQs are a nice bonus.

Quick question: now that you’re a few days past it, was there anything that came up that you wish you’d known before the weekend? Any surprises once production started transacting again on Monday?

[zvanmeter]

Yes! that’s exactly the sort of thing I’m trying to capture. This community has taught me so much, so I try to give back when I can. I’m imaging myself googling how to do this in five years only to see that I’m the purple link answering my own question

As for issues, well, nothing yet! But here are some other hurdles we had to jump through during our testing.

Firstly, we did four rounds of testing. FWIW, I think this would apply for any costing method transition.

The first round was a failure, because I didn’t know about the DMT field Part.UpdatePartPlant, which can be set to True or False to answer the popup window that appears any time you change costing method, or quantity bearing in the Part Menu. Without this, and in a multi-site environment, the fraction of a second where we had two separate costing methods on two sites threw errors, and we had to reset the test because we got to messing with Site Cost ID’s which was needless.

In our testing, we had some pain with adjusting out 100% of our inventory, with receipt inspection processing, picked, allocated, and packed inventory. This was annoying, but not so bad. One day I will share the auto-unpick all inventory REST script that we built. I got annoyed with packed inventory so I tried to delete the customer shipment lines and not the order, via rest, and inadvertently created a RESTful way to delete ShipHead lines without deleting ShipDtl lines, so again, we had to reset the test.

On the third try we actually got the migration fully functional, but we wanted some reports to show the brass about the impact of the change, so we adjusted inventory out at the Standard cost, and in at the Average cost, without adjusting the Average equal to the Standard. This showed us what our overall overstated inventory was, and what it will eventually adjust down to as we transact.

On the fourth try, we shipped all of the sales orders instead of deleting them… If your shipping department is like ours, they pre-stage shipments the day before. That means they spend all day Friday picking and packing for shipments Monday. We marked this shipped on Friday, didn’t invoice them, adjusted our inventory, then on Monday, we marked them unshipped, and then shipped when they actually went out. This will no doubt cause a blip on INV-WIP, but one which ought not to cause waves, since we did it mid month.

I encourage anyone changing costing methods to do it mid-month.

[utaylor (Utah Taylor)]

@zvanmeter

I’m imaging myself googling how to do this in five years only to see that I’m the purple link answering my own question

so funny when it happens haha

[utaylor (Utah Taylor)]

Thanks for sharing, nice job figuring all this out.

[SLK (Staci Kramer)]

We are actually looking at going from Average costing to Standard. Would you mind sharing the main frustrations with Standard costing that made you choose to move away from it?

[spulsifer (Sharon Pulsifer)]

We converted years ago. Since we manufacture buildings, we also converted to one part per job. With average costing, we eliminated variances and cost rolls. We achieved actual costs. Actual cost is what our business leaders wanted for each job.

[zvanmeter]

I’ll second what Sharon mentioned about actual costs!

Our team is producing parts for long and short run demand. we bid our raw material purchases and there isn’t really a uniform price buy to buy- as the pricing is heavily dependent on volume, as are out setup costs.

Our team didn’t find a lot of value in manufacturing variance reports. While they can be helpful, there isn’t a lot in them which you cant find through an operational metric or BAQ. When manufacturing variance came off of the part at job close, and those parts went into inventory at standard cost, the variance would not roll through to our gross margin report. This meant that we essentially needed to roll our manufacturing variance back into our analysis to make use of some of these executive reports.

I could see if your company really stayed on top of manufacturing variance. If you always followed it up with minute adjustments and such, but for our company that wasn’t possible. This is because we couldn’t make / sell parts in consistent quantities. As you may know, the Costing Lot size (PartPlant.MfgLotSize) is one number, and if you have variable setup costs, or price breaks, there isn’t a lot of flexibility.

Suppose it costs $1,000 to set up a part. The customer orders 20 units, and so our setup cost is ~$50 per part. They order 200 units, and our setup cost is $5 per part. If we put our standard in there at a 200pc lot size, it looks like a disaster on the 20pc order, no matter what kind of price breaks we have. Even though we’re selling it for an appropriate price, the margin analysis looks wacky.

So we’re adjusting standards essentially every month, resulting in our variance reports being useless, and our margin reports being inaccurate. Average is really what we wanted the whole time.

[Mark_Wonsil]

@zvanmeter

Suppose it costs $1,000 to set up a part. The customer orders 20 units, and so our setup cost is ~$50 per part. They order 200 units, and our setup cost is $5 per part. If we put our standard in there at a 200pc lot size, it looks like a disaster on the 20pc order, no matter what kind of price breaks we have. Even though we’re selling it for an appropriate price, the margin analysis looks wacky.

If it costs $1000 to set up a part with an economic order quantity of 200 and I decide to only make 20, that IS a disaster! The margin is bad and should look so. If you make 200 and only sell 20, there should be no problems there.

Costing is really dependent on your business model. In Sharon’s case, it’s more of a project-based system. Materials are generally purchased for a particular order or project. Actual costs are easier to get in this world. When we start to share materials amongst orders or costs are changing rapidly is when things get sticky for standard costing. If I think of the standard as an estimate (because it kinda is), I have the same problem though. If I estimated wood would cost one amount when quoting the project and it comes in way higher, we’re in the same boat from variance analysis, right? It’s reality.

The main purpose behind standard costing is to make accounting easier. Move everything at a fixed cost and deal with the variances separately. The problem that standard cost is trying to solve is timing. When material is purchased, received, and used before the invoice comes in at a different amount, going back to allocate the differences is a PITA - less so for project accounting. That’s why people use standard cost outside of project accounting.

We use average cost for our purchased items but standard for our assemblies. That seems to absorb the purchase price fluctuations and lets us concentrate on time for the assemblies.