Month End Closing Process Flowchart – SAP CO-PC Month-end processing is really where the bulk of the work exists for finance. Throughout a given period, actual expenses are recorded in SAP as purchases are made, payroll is processed, bills are paid, and production occurs. Postings are now under final review by plant controllers and corporate finance. Incorrect postings that were not resolved throughout the month are uncovered and the finance department finalizes fixes and adjustments before processing a series of steps in the month-end close calendar. At month end, work in process, variance, and settlement are calculated. COSTS are settled after all material movements in the previous period are completed. The variance between actual costs and standard costs can be capitalized and/or result in planning changes for costing the next period or year. Let’s use Figure 5.4 to illustrate how variances work. This example can work for both planned orders (repetitive manufacturing) and production orders (discrete manufacturing). Assume we have an order to produce ten cases of perfume bottles. Components on the perfume bottle BOM are back flushed to the production order at plan quantities, or directly issued at actual quantities.
Figure 5.4: Component issues to order This credits component inventory and debits the production order with consumption of raw materials, packaging, etc. See Table 4.1 for an example.
Table 5.2: Debit & credit for material consumption Activities are confirmed on the order for setup, labor, overhead based on either plan routing figures, or actual figures entered during production. that total activity quantities and dollars are planned by cost center in order to calculate an activity rate. That activity rate is multiplied by the actual activity hours in production (see Figure 5.5).
Figure 5.5: Activity confirmations to order This credits the work center’s cost center and debits the production order with the secondary cost element assigned on the activity type (see Table 5.3).
Table 5.3: Debit & credit for activity confirmation Now that debits are incurred on the order to reflect the consumption of materials and activities, a credit is posted to confirm that finished good inventory is produced. Finished good confirmations, also called production confirmations, may also be done as each case of perfume is produced, at the end of a shift, or when all cases are produced. Depending on the scenario, components and activities may be backflushed at the time of finished good confirmation. It is important that you understand how your production team plans to record production so you can understand results. Want To Get SAP Product Costing Training From Experts? Enroll Now For Free Demo On SAP Product Costing Training. Work in process (WIP) calculation The WIP calculation function valuates the work in process (unfinished products). Prior to calculating variances and settling orders, orders must run through work in process calculation to determine what portion of the order, if any, is not complete. Since WIP inventory cannot be counted during a physical inventory count or cycle count, this process determines the dollar value of WIP. In order to calculate variances and move the costs associated with work in process to the balance sheet, we need to run WIP. No financial posting is made when WIP is executed. When the order or product cost collector is settled, WIP should post to these s: Expense – Production Credit WIP Inventory – Work in Process In product cost by period (repetitive manufacturing), WIP is valued at the target cost of quantities confirmed (based on a cost estimate) minus scrap and goods receipt quantities. In configuration, you determine if the target cost estimate is the standard cost estimate or the preliminary cost estimate (see Figure 5.6).
Figure 5.6: WIP calculation for product cost by period Repetitive work in process example A product cost collector has a plan order quantity of 100. At month end, only 10 (of the 100) are finished. The standard cost of the finished good is $1.04. Total debits on the order are $25 based on material consumption and activity confirmations. Total credits on the order are based on the goods receipt of finished goods (10 times standard cost of $1.04 = $10.40). Target cost of quantities confirmed is ($1.04 * 10) = $10.40. $10.40 – $0- $25 = $14.60 Total WIP amount.
In product cost by order (discrete manufacturing), WIP is the difference between total debits on an order (expenses from material backflushes and activity confirmations) and total credits on the order (production credits at standard cost for each confirmation of finished goods) (see Figure 5.7).
Figure 5.7: WIP calculation for product cost by order In order for WIP to be calculated, the production or process order must be in status ‘REL’ meaning released. Regardless of whether the material has work in process or not, all production or process orders can go through WIP calculation at the end of the month. Only orders that have a valid results analysis key and are not in status DLFL (Deletion flag) or DLT (Deleted) are included in WIP calculation. Throughout order processing, orders are debited with expenses for labor, material, and services. As finished goods are produced, a production credit is posted to the order. At this point, all orders remain on the profit and loss statement. WIP calculation determines the remaining cost on an order after the credit for finished goods at standard cost. Through WIP calculation, we move WIP balances to balance sheet inventory s. Discrete work in process example An order is in REL status (Not TECO or DLV yet since it is still in progress). The plan order quantity is 100. At the end of the month, only 10 (of the 100) are finished. The standard cost of the finished good is $1.04. Total debits on the order are $25 based on material consumption and activity confirmations. Total credits on the order are based on the goods receipt of finished goods (10 times std cost of $1.04 = $10.40). Total plan costs are ($1.04 * 100) = $104. However, this value is not used in WIP calculation. Total actual debits minus total actual credits equals WIP: $25.00 – $10.40 = $14.60 Total WIP amount.
The screenshot Figure 5.8 is transaction KKAO for calculating WIP for an order in a plant. You can also use WIP transaction KKAX for one order of transaction KKAS for each product cost collector at a time. Note that you can run WIP in test mode at any time and review results prior to posting.
Figure 5.8: Work in process collective processing In the screenshot in Figure 5.9, you will see two columns with WIP values. The first is cumulated WIP. Cumulated WIP is the amount of WIP for the period 9, in this case, and the amount that will show up on the balance sheet as a WIP. The second column to the right is WIP period change. This column is for analysis purposes only and shows the change from last period’s WIP to this period’s WIP. You will also notice that some orders are grouped with a description ‘WIP data reserve for unrealizedcosts’. This means that the order has more credits (production credits for finished goods) than the total debits (expenses from material consumption or activity confirmations). SAP creates a reserve because we expect more debits on this order based on the standard cost estimate for the material. When you settle, reserves for unrealized costs result in the system is debiting the expense (from reserves) in the income statement and crediting the reserves for unrealized costs in the balance sheet.
Figure 5.9: Work in process object list
Variance calculation Prior to settling the difference between total order debits and credits, we perform variance calculation to classify variances for further analysis. SAP offers variance analysis on the input (consumption, overhead allocation, actual expense) side and output (production quantity or valuation) side. See the lists below for information on input and output variances. Variance calculation provides you with detailed cost information on products or manufacturing orders. The variance calculation function: Shows the variance between target costs and control costs (the control costs can be the net actual costs, for example) Determines the difference between the actual costs debited to the object and the credit from goods receipts (total variance) Valuates the unplanned scrap quantities with target costs to determine the scrap variances Determines production variances and planning variances for informational purposes Shows the causes of the variances and assigns the variances to different variance categories depending on the cause
The system updates the variances by object for each cost element, or for each cost element and origin. Input Variances Variances on the input side are variances based on goods issues, internal activity allocations, overhead allocation, and G/L postings. These variances are assigned to the following variance categories according to their cause: Input Price Variance: Caused by differences between plan and actual material and activity prices. Only calculated if material origin is selected on material master. Resource-Usage Variance: Caused by using different materials and activities than were planned in BOMs and Routings/Master Recipes. Material Quantity Variance: Caused by different material and quantities than were planned in BOMs. Remaining Input Variance: This occurs when costs are entered without a quantity or when OH rates are changed. Scrap Variance: Caused by differences between operation scrap in routing and actual scrap confirmed. Output Variances Mixed Price Variance: Caused when the system determines a different mixed cost than the released cost estimate. Must be selected in the variance variant to see. Output Price Variance: Caused if the standard price changed between delivery to stock and when variances are calculated, moving average price materials are not delivered to stock at standard price, or price used to valuate inventory is not a mixed price. Lot Size Variance: Differences between the planned and actual costs that don’t vary with lot size. Remaining Variance: Differences between target and allocated actual costs that cannot be assigned to any other category. Also used when no variance categories defined in variance variant. The screenshot in Figure 5.10 is transaction KKS1 to run variance calculation for all orders in a plant. You can also run variance calculation for one order at a time with transaction KKS2 or transaction KKS6 for product cost collectors. Along with WIP, you can run variance calculation in test mode at any time.
Figure 5.10: Variance calculation After executing the variance calculation, the list in the screenshot in Figure 5.11 will appear. This screen shows the target and actual cost for each order, the allocated actual, work in process, scrap variances, and total variances. Many columns can be added using the layout button that looks like a Rubik’s Cube on the toolbar to further analyze order variance details. This report also shows you a default view of version, which represents target costs for total variances and variances are displayed in the company code currency.
Figure 5.11: Variance calculation list The term allocated actual costs is typically confusing to people when they view this report. Think of allocated actual costs as costs with which the order is credited. When variances are calculated, allocated actual costs are compared with target costs to calculate variances on the output side. These costs are actual credits from deliveries to stock when a finished good is produced. Orders may show $0.00 target costs, which means the finished good material did not have a cost estimate at the time the order was created. A strong master data management process can help reduce the number of orders that have no target costs. If an order has no target costs, the system will produce an error that variances cannot be calculated. If you cost the material, then un-TECO the order, and click the calculator icon, you can recost the material on the order to produce target costs. I suggest that you check throughout the month for orders without target costs in order to mitigate these issues prior to month end. Many companies prefer to perform variance calculation more often than month end in order to stay on top of large production variances and mitigate issues. This transaction can be run in test mode as often as needed to produce a detailed variance report for analysis. Explore SAP Product Costing Sample Resumes! & Edit, Get Noticed by Top Employers! Now! Order settlement
When a production order is settled, the actual costs incurred for the order are settled to one or more receiver cost-objects (for example, to the for the material produced or to a sales order). Offsetting entries are generated automatically to credit the production order: If the costs for the production order are settled to a material , the order is credited each time material is delivered to stock. The material stock is debited accordingly. If the costs for the production order are settled to another receiver (for example to a sales order), the order is credited automatically at the time of settlement. The cost-objects are debited accordingly. The debit posting remains in the order and can be displayed even after the costs have been settled. The settled costs are updated in the corresponding receiver cost-object and can be displayed in the reporting. Finally, we must settle orders so that the remaining balance on orders can be offset and the variances can post to a final resting place on the financial statement. As we have discussed in this field, orders are debited with actual costs during production material and activity confirmations. When finished goods are produced, the order is credited at the standard cost of the material. When you perform settlement, the difference between the debit and credit of the order is transferred to the cost center based on the finished good material’s profit center. Each cost object in controlling has a settlement rule in the order to determine where the order’s costs should be settled. Figure 5.12 is a screenshot of a sample settlement rule from a production order. The default settlement receiver for orders in SAP is material. The settlement profile configuration determines what settlement rule should default in the order and you do not need to enter a settlement rule. Further details on the settlement profile are in section 142.
Figure 5.12: Order settlement rule The screenshot in Figure 5.13 is transaction CO88, actual order settlement for an entire plant. Transaction KO88 can be used for settling individual production or process orders. Transaction KK87 can be used for settling product cost collectors individually.
Figure 5.13: Actual settlement orders Sales orders can be settled with transaction VA88 for an entire sales order at a time, a range of sales documents, and/or a range of document items. This settlement transaction is shown in Figure 5.14: Actual settlement sales orders.
Figure 5.14: Actual settlement sales orders After orders are settled, you should review the financial documents and ensure that all orders that should be settled were settled. A great transaction to view order balances is transaction KOC4 (see Figure 5.15). Running this transaction after settlement can clearly show you what orders will have actual cost debits for the period and what are not settled yet. Then, you can resolve the root cause and settle those orders again.
Figure 5.15: Order selection results list