Skip to content

Contact Us    Now Hiring

@meritweb on TwitterMerit Solutions on LinkedInMerit Solutions YouTube Video SeriesMerit Solutions on FacebookSubscribe to Merit Matters Blog

   

Implications of Choosing Actual or Standard Costing

This is the second of an (intermittent) series of blog entries on costing in Dynamics GP. Our previous entry reviewed the first choice you have to make – whether to use standard or actual costs to value your inventory. In this entry we will explore the impact of choosing standard vs. actual costs.

Dynamics GP offers users the opportunity to manage product costs accurately. Accurate costing enables management to understand product costs, provide for fact-based decision making regarding product profitability, and ultimately reduce expenses, increasing profits.

For a business to realize these benefits, it’s important to understand the options available in Dynamics GP and the proper way to perform transactions so that costs may be captured correctly. During your implementation, you will choose a costing method for each and every individual item in your system. For any given item, you can choose between different varieties of either standard or actual cost. Either method requires attention to detail during setup. You have to make sure you get the settings and GL accounts correct on the item classes and items so that GP will process journal entries the way you expect.

Standard costing means exactly that – you set a cost for an item that does not change until you change it by setting a new standard. All transactions will use the standard cost – regardless of whether or not the actual cost is different than the standard. Any differences between standard and actual cost for an item will be booked as variances.

For transaction processing, standard cost tends to be a bit more forgiving to end users than actual costs, especially in a manufacturing environment. Once you set your standards correctly for an item, all transactions happen at standard cost. This means that if users accidentally entry transactions out of order, the system will still get the costs right. For instance (assuming you allow overrides to inventory to let quantities go negative), if you issue an item to a manufacturing order in the system before you have received the item into inventory from a Purchase Order, both transactions will happen at standard cost and the MO will accumulate costs for the raw material as soon as it is issued.

In addition, standard costing is a bit easier to reconcile between the General Ledger and the Inventory module. Since all transactions occur at standard, and the value of inventory is simply the standard cost times the quantity on hand, inventory valuation is a fairly simple task.

Actual costing means the system will use the actual transaction cost for valuing inventory. If something is being received, typically this means either a cost from a purchase order or from a manufacturing order. Another example / alternative is the cost a user keys in on a positive inventory variance or adjustment transaction. For usage transactions, the actual cost used is applied to the transaction automatically by the system. It will retrieve the appropriate actual cost of the inventory receipt “layer” being used. It does this in order of receipt – either in FIFO (first in-first out) order or LIFO (last in – first out) order depending on the costing method chosen.

Actual costing is a bit less forgiving than standard cost for timing mistakes on the part of users. For instance, if you issue the material to a Manufacturing Order before it is received against a PO and invoiced, then it will go to the Manufacturing Order at zero cost (because there is no cost for “zero” inventory). If the MO is subsequently received before the PO receipt happens, then the actual cost of the manufactured item won’t include costs for the material – because it was issued at zero cost. So, this is a cautionary note to anyone considering actual costs. Actual costs work very well in GP – but you have to have user procedure discipline to make sure transactions are entered timely for it to work properly. GP can adjust and post cost variances and adjusting entries up to a point, but there is no substitute for good procedures and disciplined, timely transaction entry.

Actual costing is a bit more difficult to reconcile between the General Ledger and the Inventory module. Since all transactions may occur at different actual costs (even for the same item), the value of inventory is more challenging to compute since one has to review the value of every inventory layer to reconcile inventory to the General Ledger. In addition, to look at the value at a point in time requires calculating the value based on the value of the transactions that occurred up to that point in time (or back to that point in time in history. Luckily, there are some reports available in Dynamics GP to help with this task – but it is still more challenging than standard costing.

For each choice (standard or actual), you can further choose whether you are going to use receipt layers of your inventory on a FIFO (first in / first out) or LIFO (last in / first out) basis. Dynamics GP tracks every receipt made for every item and/or item/lot combination. These receipt layers are “used up” through sales, issue to manufacturing orders, negative item adjustments and variances, or usage on service calls or projects. The order in which the layers are used depends on the FIFO or LIFO choice made with the costing method. For standard costs, this does not make much difference from a cost perspective because all layers are valued at standard cost. For the actual costing choices, it makes a difference because each receipt can be valued at a different cost depending on the actual cost applied at receiving time.

Trackbacks

No Trackbacks

Comments

Display comments as Linear | Threaded

No comments

Add Comment

Enclosing asterisks marks text as bold (*word*), underscore are made via _word_.
Standard emoticons like :-) and ;-) are converted to images.
E-Mail addresses will not be displayed and will only be used for E-Mail notifications.
To leave a comment you must approve it via e-mail, which will be sent to your address after submission.
Form options