Skip to main content

Deferred COGS Accounting in R12


The deferred COGS of goods account is the new feature introduced in Release 12. The basic fundamental behind the enhancement is that the COGS is now directly matched to the Revenue. The same was not possible till now.

Prior to this enhancement, the value of goods shipped from inventory were expensed to COGS upon ship confirm, despite the fact that revenue may not yet have been earned on that shipment. With this enhancement, the value of goods shipped from inventory will be put in a Deferred COGS account. As percentages of Revenue are recognized, a matching percentage of the value of goods shipped from inventory will be moved from the Deferred COGS account to the COGS account, thus synchronizing
the recognition of revenue and COGS in accordance with the recommendations of generally accepted accounting principles.

The Matching Principle is a fundamental accounting directive that mandates that revenue and its associated cost of goods sold must be recognized in the same accounting period. This enhancement will automate the matching of Cost of Goods Sold (COGS) for a sales order line to the revenue that is billed for that sales order line.

The deferral of COGS applies to sales orders of both non-configurable and configurable items (Pick-To-Order and Assemble-To-Order). It applies to sales orders from the customer facing operating units in the case of drop shipments when the new accounting flow introduced in 11.5.10 is used. And finally, it also applies to RMAs that references a sales order whose COGS was deferred. Such RMAs will be accounted using the original sales order cost in such a way that it will maintain the latest known COGS recognition percentage. If RMAs are tied to a sales order, RMAs will be accounted for such that the distribution of credits between deferred COGS and actual COGS will maintain the existing proportion that Costing is aware of.  If RMAs are not tied to a sales order, there is no deferred COGS.

SETUP and ACCOUNTING :

To set the deferred COGS account.

Inventory -- Setup -- Organization -- Parameters -- Other Accounts
A new account is added which is referred as the Deferred COGS accounts. 
Please note that when upgrading from a pre R12 version the DEFERRED_COGS_ACCOUNT will be populated if it is null with the cost_of_goods_sold_account on the organization parameter. This can then be changed accordingly if a different account is required.

NEW ACCOUNTING :

Release 12 : 
When a Sales order is shipped the following accounting takes place:

Inventory Valuation Account : Credit.
                   Deferred COGS account : Debit

Once the revenue is recognised, you would need to decide the percentage you wish to recognize the Revenue. A COGS recognition transaction will be created to reflect a change in the revenue recognition percentage for a sales order line.

The steps to generate such transactions are as follows:
1. Run the Collect Revenue Recognition Information program. This program will collect the change in revenue recognition percentage based on AR events within the user specified date range.
2. Run the Generate COGS Recognition Events. This program will create the COGS recognition transaction for each sales order line where there is a mismatch between the latest revenue recognition percentage and the current COGS recognition percentage.

Note that users can choose how often they want to create the COGS Recognition Events.

Navigation to run the COGS recognition request :
- Cost > COGS Recognition > Collect Revenue Recognition Information
- Cost > COGS Recognition > Generate COGS Recognition Events
- Cost > View Transactions > Material Transactions


The distribution for the COGS Recognition transaction associated with the Sales Order transaction now would be as follows:

       Deferred COGS : Debit revenue percentage
       COGS               : Credit (Actual revenue percentage )

Thus, essentially the recognized COGS balance is to move the value from Deferred COGS to COGS.

This particular COGS recognition transaction actually correspond to a revenue recognition percentage change.

You can view the transactions as :
Navigation:
- Cost > View Transactions > Material Transactions > Distributions

A new COGS Revenue Matching Report shows the revenue and COGS information of sales order that fall within the user specified date range by sales order line


SIMPLER TERMS ( Table level details ) : 
Once the whole cycle is complete we will have 2 transactions lines in mtl_material_transactions.

1. Sales Order
2. COGS Recognition transaction

Accounting will be in mtl_transaction_accounts and the Subledger accounting tables as follows:

Transaction 1:
Inventory Valuation Account : Credit. (item_cost)
             Deferred COGS account : Debit (item_cost) 
Transaction 2:
Deferred COGS : Credit (Actual revenue percentage)
              COGS : Debit (Actual revenue percentage ) 

Comments

  1. But there is a balance in trail every month in Defferred COGS.

    What will be the reasons.

    ReplyDelete
  2. sir, the process you are mentioning is not existing . is it?
    1. collect revenue recognition information programme-- it is not available in opm/ar

    2.generate cost of goods sold event

    ReplyDelete
    Replies
    1. Please check in the cost management responsibility, (Either they would be as function or the concurrent program)

      Delete
    2. Please check the reports in Revenue Management Resposibility..

      Delete
  3. can you please mail me to sagarorissa@gmail.com

    ReplyDelete

Post a Comment

Popular posts from this blog

Difference Between MTS, ATO, MTO ,PTO ,CTO and ETO.

 Make-to-stock (MTS) In MTS environments, products are created before receipt of a customer order. Customer orders are then filled from existing stock, and then those stocks are replenished through production orders. MTS environments have the advantage of decoupling manufacturing processes from customer orders. Theoretically, this enables customer orders to be filled immediately from readily available stock. It also allows the manufacturer to organize production in ways that minimize costly changeovers and other disruptions. However, there are risks associated with placing finished goods into inventory without having a firm customer order or an established need. These risks tend to limit MTS environments to simple, low-variety, or commodity products whose demand can be forecasted readily.  Assemble-to-order (ATO) In ATO environments, products are assembled from components after the receipt of a customer order. The key components in the assembly or f...

Accounting entries in Oracle Purchasing and Payables

This document gives in detail different accounts used and the accounting impact of various transactions that take place in Oracle Purchasing and Oracle Payables. Both Standard costing and Average costing methods are considered. The accounts are Oracle Applications specific and might differ from the conventional accounting names. Examples are given wherever required for better understanding of the concept. The sources of these accounts are given. PURCHASING:  Receiving – For Accrual Process for perpetual Accruals Receipts for inventory purchases are always accrued upon receipt. And also use perpetual accruals for expense purchases you want to record uninvoiced purchase liabilities immediately upon the receipt of the expense goods. Receiving Account (Receiving Account) To record the current balance of the material in receiving and inspection. Where to define in Apps: Define Organization           ...

Scheduling ,Reservations and ATP in Oracle Order management

Before we start understanding scheduling we need to know certain terms and how they are derived in Oracle. Terminology Understanding the following terms will help you understand how scheduling works in OM. Actual Arrival Date - The date the order line arrives at the customer site. Actual Ship Date - The date the order line is shipped. This date is recorded by the ship confirm action. Arrival Set - A set of order lines which arrive at the same time at the destination. Available to Promise (ATP) - The quantity of current on-hand stock, outstanding receipts and planned production not already committed to sales orders or other sources of demand. ATP Date - The date that a requested quantity will be available to promise. Delivery Lead Time - Time (in days) for items to reach the customer once they are shipped. There are two ways to help system calculate this date. 1) Create a location for the Ship-to address and assign it as the internal location and then define...