This chapter covers the following topics:
Financial accounting has two important Generally Accepted Accounting Principles (GAAP) that guide the statement of financial earnings:
Revenue recognition principle
Cost matching principle
The revenue recognition principle requires revenues to be recognized when a firm has performed all, or a substantial portion of services to be provided, and cash receipt is reasonably certain. The matching principle requires that cash outlays associated directly with revenues are expensed in the period in which the firm recognizes the revenue.
The Oracle E-Business Suite supports this matching principle by synchronizing the recognition of cost of goods sold (COGS) with the revenue recognized in Oracle Receivables for shipments made in Oracle Order Management, or other order fulfillment systems. With this feature, sales order revenue and the associated COGS are recognized in the same period. In addition, when sales order revenue is only partially recognized, the associated COGS is recognized in the same proportion.
When you ship confirm one or more order lines in Oracle Order Management and then run the applicable Cost Management cost and accounting processes, the cost of goods sold associated with the sales order line is immediately debited to a Deferred COGS account pending the invoicing and recognition of the sales order revenue in Oracle Receivables. When Oracle Receivables recognizes all or part of the sales revenue associated with a sales order line, you run a cost process that calculates the percentage of total billed revenue recognized. Oracle Inventory then creates a cost recognition transaction that adjusts the Deferred COGS and regular COGS amount for the order line. The proportion of total shipment cost that is recognized as COGS will always match the proportion of total billable quantity that is recognized as revenue.
You can select the accounting date for which COGS for a ship only order is recognized by setting the profile option 'CST: Ship or Closure Date'. Profile option values include:
Sales Order Issue Date
OM order line closure date (default)
Refer to Profile Options and Security Functions.
Related Topics
Recognizing Revenue, Oracle Receivables User's Guide
The following describes how Oracle Cost Management synchronizes the recognition of earned COGS to earned sales order revenue in a variety of business scenarios.
Revenue / COGS recognition main business flow
At sales order shipment, order lines are costed and booked to a Deferred Cost of Goods Sold (COGS) account. This account is subsequently adjusted for any change in the percentage of earned or recognized revenue associated with the sales order lines. This is done to ensure that amount of earned COGS is recognized proportionately as the amount of earned revenue.
You run a set of concurrent processes to record sales order and revenue recognition transactions and to create and cost COGS recognition transactions. These COGS recognition transactions adjust deferred and earned COGS in an amount that synchronizes the percent of earned COGS to earned revenue on sales order shipment lines.
Record Order Management Transactions: records new sales order transaction activity such as shipments and RMA returns in Oracle Order Management.
Collect Revenue Recognition Information: determines the percentage of recognized or earned revenue related to invoiced sales order shipment lines in Oracle Receivables.
Generate COGS Recognition Events: creates and costs COGS recognition events for new sales order shipments/returns and changes in revenue recognition and credits for invoiced sales order shipment lines.
COGS recognition events are created for:
Invoiceable and shippable order lines
Configured items: invoiceable (parent) line if it has any shippable but not invoiceable children.
A shippable non-invoiceable line that has no invoiceable parent.
A COGS recognition event generates a COGS recognition transaction whose date and time stamp is the end of day as specified in the inventory organization's legal entity time zone.
A rejected acceptance-enabled sales order line will not interface with Oracle Receivables and Oracle Order Management.
An RMA receipt will result in a credit to total COGS (split appropriately between deferred COGS and COGS if necessary) with a debit to inventory.
Customer acceptance only affects Costing indirectly, in that:
It is a revenue recognition contingency for an order line.
A rejected sales order line means all shipped quantities for that line will never be invoiced in A/R. When you close this order line, Order Management flags this as an uninvoiced line. When this occurs, Cost Management moves the balance of the sales order line from deferred COGS to COGS.
There is no accounting when a sales order line is rejected. Costing only creates accounting when the rejected items are received and then either delivered to a regular or a scrap asset subinventory.
In customer drop ship scenarios with advanced accounting, revenue / COGS matching occurs only in the customer-facing organization. If advanced accounting is not enabled, revenue and COGS matching does not occur. Costing books the entire sales order shipment amount to COGS.
The matching and synchronization of the earned and deferred components of sales order revenue and COGS is accomplished by running the following COGS recognition concurrent processes at user-defined intervals:
Record Order Management Transactions
Collect Revenue Recognition Information
Generate COGS Recognition Events
The Record Order Management Transactions concurrent process picks up and costs all uncosted sales order issue and RMA return transactions, and creates a record for each new order line in the costing COGS recognition matching table. This process is not for Perpetual Discrete Costing (Standard, Average, FIFO). In Discrete Costing, the cost processor selects and costs the uncosted sales order issues and inserts them into the COGS matching table.
This process is used for external product integration. For example, the Oracle Process Manufacturing Costing Processor can use the Record Order Management program so that Order Management transactions done for OPM will match to Revenue.
To record order management transactions
Navigate to the Record Order Management Transactions window. The Parameters window appears.
Select a Ledger from the list of values.
Click Submit to run the request.
The Collect Revenue Recognition Information concurrent process calls an Oracle Receivables API to retrieve the latest revenue recognition percentage of all invoiced sales order lines in Oracle receivables for a specific ledger and with activity dates within a user-specified date range. This process must be run before the Generate COGS recognition Event concurrent process.
To collect revenue recognition information
Navigate to the Collect Revenue Recognition Information window. The Parameters window appears.
Select a Ledger to restrict revenue recognition events within a specific ledger..
This concurrent request has two date parameters that allow you to restrict processing of revenue recognition events to a range of dates:
Start Date: Transactions prior to this date are not selected. The default value is the date of the last successful run of the concurrent request.
End Date: Transactions after this date are not selected.
Choose OK.
Choose Submit to run the request.
The Generate COGS Recognition Events concurrent request compares the COGS recognition percentage for each sales order line and accounting period combination to the current earned revenue percentage. When the compared percentages are different, the process raises a COGS recognition event and creates a COGS recognition transaction in Oracle Inventory that adjusts the ratio of earned and deferred COGS to match that of earned and deferred revenue. You must run this process after completion of the Collect Revenue Recognition Information concurrent process.
To generate COGS recognition events
Navigate to the Generate COGS Recognition Events window. The Parameters window appears.
Select a Ledger from the list of values.
Click Submit to run the request.
Ensure that there are open GL period in each ledger for the periods in which you run the concurrent process.
In perpetual costing organizations, you can create backdated COGS recognition events and transactions in open and closed inventory periods.
In periodic costing organizations, only events and transactions that are within the current periodic period's start and end dates will be processed.
The inventory period close process must be synchronized with Oracle Receivables period close to ensure proper recognition of revenue and COGS in an accounting period.
In periodic costing organizations, you cannot close the accounting period if Oracle Receivables has not soft closed its accounting period. Attempting to do so generates an error message. This condition ensures that all backdated revenue recognition transactions in Oracle Receivables are processed in costing prior to period close.
In periodic costing organizations, run the Generate COGS Recognition Events concurrent process after the close of an inventory accounting period to ensure that all COGS recognition events have been processed and costed. Rerun the Periodic Cost Processor and Periodic Distribution Processor. Costing performs a validation to ensure that all organizations in a Periodic Average Costing (PAC) cost group have no mismatched revenue and COGS order lines, and generates an error message if unmatched lines are found.
Revenue / COGS matching is supported for the following sales order business scenarios:
Sales orders: no customer acceptance
Sales orders: customer acceptance enabled
Sales orders: configured items - ATO / PTO
The following scenarios illustrate Revenue / COGS matching for sales orders where customer acceptance is not in the business process flow. The underlying assumption in this set of scenarios is that ownership is transferred at the time of shipment. They apply when customer acceptance is not enabled in Oracle Order Management. Scenarios include:
Scenario 1: Sales order/invoicing, RMA, and credit memo
Scenario 2: Alternate revenue allocation in credit memo
Scenario 3: Credit memo before RMA
Scenario 4: RMA following full revenue recognition
Scenario 5: Sales order, multiple RMA's, revenue recognition, credit memos
Scenario 6: RMA not tied to sales order
Scenario 7: Uninvoiced sales order
Time 1 – Sales order issue: Qty = 10, Cost = $50, Price = $100
Account | Debit | Credit |
---|---|---|
Deferred COGS | 500 | - |
Inventory | - | 500 |
COGS | - | - |
Deferred Revenue | - | 1000 |
Receivables | 1000 | - |
Revenue | - | - |
Time 2 – Revenue recognized at 50% in A/R
Account | Debit | Credit |
---|---|---|
Deferred Revenue | 500 | - |
Revenue | - | 500 |
COGS accounting distributions are adjusted based on the total shipped quantity. A/R flags that 50 percent of the revenue for the 10 invoiced units has been recognized. Costing applies the same percentage to the regular and deferred COGS accounts.
COGS = 500 * .50 = $250
Account | Debit | Credit |
---|---|---|
COGS | 250 | - |
Deferred COGS | - | 250 |
Time 3 – RMA for 2 units received into inventory
The A/R earned revenue percentage remains at 50 percent. When accounting for the RMA receipt, costing reduces the total COGS balance so that the proportion of deferred to earned is maintained. The value of the RMA is 2 x $50 = $100. Costing adjusts the earned and deferred COGS accounts as follows:
Account | Debit | Credit |
---|---|---|
Inventory | 100 | - |
COGS | - | 50 |
Deferred COGS | - | 50 |
At this point in time, the COGS account balance is (500-100) x .50 or $200, and the Deferred COGS account balance is (500-100) x .50 or $200
Time 4 – Credit memo created in AR related to the RMA for 2 units
A/R elects to debit the entire amount of the credit memo in the deferred revenue account and nothing in the earned revenue account. This can occur when there is an outstanding contingency on the returned units and it's assumed that the revenue on the returned units had previously not been recognized.
Account | Debit | Credit |
---|---|---|
Deferred Revenue | 200 | - |
Receivables | - | 200 |
After this transaction, total expected revenue is reduced from $1000 to $800. The earned/unearned revenue proportion has changed and costing needs to create a COGS recognition event to keep the ratio of earned/deferred COGS the same as the ratio of earned/unearned revenue.
New earned revenue percentage: $500 / ($500 + $300) = 62.5 percent
Required earned/deferred COGS percentages: 62.5 percent / 37.5 percent
Total expected COGS balance before RMA/credit memo: $400
Allocated as follows: $400 x .50 = $200 earned, $400 x .50 = $200 deferred
Total expected COGS balance after RMA/credit memo: $400
Allocated as follows: 400 x .625 = $250 earned, 400 x .375 = $150 deferred
COGS recognition transaction: $50 adjustment from deferred to earned COGS
Account | Debit | Credit |
---|---|---|
COGS | 50 | - |
Deferred COGS | - | 50 |
As the credit memo accounting distribution in A/R altered the ratio of earned to deferred revenue, costing will generate a COGS recognition adjustment transaction that keeps the associated earned/deferred COGS ratio the same as the revenue ratio.
Note: Time 1 to Time 3 transactions are the same as those in scenario 1.
Time 4 - Credit memo created in A/R related to the RMA for these 2 units
Instead of applying the entire credit memo amount to deferred revenue, A/R elects to apply it equally to the earned and deferred revenue accounts.
Account | Debit | Credit |
---|---|---|
Deferred Revenue | 100 | - |
Revenue | 100 | - |
Receivables | - | 200 |
After the credit memo is applied, costing will not create a COGS recognition transaction as the proportion of earned/deferred COGS is still equal to the proportion of earned/deferred revenue.
New earned revenue percentage: $400 / ($400 + $400) = 50.0 percent
Required earned/deferred COGS percentages: 50.0 percent / 50.0 percent
Previous earned/deferred COGS percentages: 50.0 percent / 50.0 percent
Total expected COGS balance before RMA/credit memo: $400
Allocated as follows: $400 x .50 = $200 earned, $400 x .50 = $200 deferred
Total expected COGS balance RMA/after credit memo: $400
Allocated as follows: 400 x .50 = $200 earned, 400 x .50 = $200 deferred
COGS recognition transaction: none
Note: Time 1 to time 2 transactions are the same as those in scenario 1.
Time 3 – Credit memo pegged to originating sales order created in A/R for $200
Account | Debit | Credit |
---|---|---|
Deferred Revenue | 100 | - |
Revenue | 100 | - |
Receivables | - | 200 |
Costing will not need to create a COGS recognition adjustment transaction as the credit memo accounting distribution does not change the ratio of earned/deferred revenue.
Time 1 – Sales order issue, full revenue recognition: Qty = 10, Cost = $50, Price = $100
When the items are shipped, the full value of the shipment is booked to the deferred COGS account.
Account | Debit | Credit |
---|---|---|
Deferred COGS | 500 | - |
Inventory | - | 500 |
In A/R, the sales order line is billed and all of the revenue is recognized.
Account | Debit | Credit |
---|---|---|
Receivables | 1000 | - |
Revenue | - | 1000 |
Costing creates a COGS adjustment event to recognize the full amount of COGS as earned.
Account | Debit | Credit |
---|---|---|
COGS | 500 | - |
Deferred COGS | - | 500 |
Time 2 – RMA for 2 units received into inventory
Since the current ratio of earned to unearned revenue is 1/0 (earned/unearned), costing applies the entire amount of the RMA to the earned COGS account.
Account | Debit | Credit |
---|---|---|
Inventory | 100 | - |
COGS | - | 100 |
This RMA could have been created to replace a defective product. As a result, no credit memo is expected and replacement units are expected to be shipped at a later date. The expected COGS is temporarily reduced to $400 pending the shipment of the replacements.
Time 1 – Sales order issue, full revenue recognition: Qty = 10, Cost = $50, Price = $100
When the items are shipped, the full value of the shipment is booked to the deferred COGS account.
Account | Debit | Credit |
---|---|---|
Deferred COGS | 500 | - |
Inventory | - | 500 |
In A/R, the sales order line is invoiced and all of the revenue is deferred.
Account | Debit | Credit |
---|---|---|
Receivables | 1000 | - |
Deferred Revenue | - | 1000 |
Time 2 – RMA receipt for 2 units and credit memo
An RMA for 2 units pegged to the originating sales order is received into inventory and costing books the full amount of the RMA into deferred COGS.
Account | Debit | Credit |
---|---|---|
Inventory | 100 | - |
Deferred COGS | - | 100 |
Time 3 – Credit memo for RMA created in A/R
A/R creates a credit memo to reduce the expected revenue and customer receivable due to the returned units.
Account | Debit | Credit |
---|---|---|
Deferred Revenue | 200 | - |
Receivables | - | 200 |
As the credit memo does not change the ratio of earned/unearned revenue, no COGS recognition adjustment transaction is needed as a result of the credit memo.
Time 4 – RMA no receipt for 3 units and credit memo
An RMA with no associated receipt does not generate any accounting.
After the RMA no receipt is created, A/R creates a credit memo. As no revenue on the associated sales order has yet been recognized in this scenario, the full amount of the credit memo is a debit to the deferred revenue account.
Note: The non-receipt of RMA items may result in the understatement of COGS. For further information, see the Special Case section near the end of this chapter.
Account | Debit | Credit |
---|---|---|
Deferred Revenue | 300 | - |
Receivables | - | 300 |
Time 5 – Revenue recognition at 40 percent on remaining 5 units
The original sales order shipped 10 units to the customer, an RMA - with receipt and credit returned 2 units into inventory, and an RMA - no receipt but with credit for 3 units (presumably scrapped) yields an expected revenue/receivable on only 5 units. A/R recognizes 40 percent of the expected revenue on these 5 units, therefore $500 x .40 or $200 of earned revenue must be booked.
Account | Debit | Credit |
---|---|---|
Deferred Revenue | 200 | - |
Revenue | - | 200 |
Assuming the scrap transaction alternative in Time 4 is not performed, the total expected COGS for these 5 units is $400 ($500 minus $100 for the RMA – with receipt). Costing creates a COGS recognition transaction to recognize 40 percent of the cost on these units, which is $400 x .40, or $160.
Account | Debit | Credit |
---|---|---|
COGS | 160 | - |
Deferred COGS | - | 160 |
To revisit the topic introduced at Time 5, COGS may be understated if you expected the RMA in step Time 5 to be a scrap event. However, as explained, you should create an explicit scrap by receiving the RMA into a scrap subinventory.
Time 6 – RMA no receipt for 1 unit and credit memo
An RMA with no associated receipt into inventory does not generate any accounting.
An additional RMA no receipt with credit memo is created. After the RMA no receipt is created, A/R creates a credit memo and allocates the amount entirely to the unearned (Deferred) revenue accounts.
Note: The non-receipt of RMA items may result in the understatement of COGS. For further information, see the Special Case section near the end of this chapter.
Account | Debit | Credit |
---|---|---|
Deferred Revenue | 100 | - |
Receivables | - | 100 |
An additional RMA no receipt with credit memo is created. A/R creates a credit memo for the RMA and allocates the amount equally between the earned and unearned revenue accounts.
At this point in time, total expected revenue is $400 ($1000 less $600 for three RMA's) of which $200 or 50 percent has been earned and recognized. As the credit memo changes the ratio of earned/deferred revenue, costing creates a COGS recognition transaction to align earned/deferred COGS and revenue.
Current earned revenue percentage: $200 / ($200 + $200) = 50.0 percent.
Required earned/deferred COGS percentages: 50 percent/50 percent
Total expected COGS balance before credit memo: $400
Total expected COGS balance after credit memo: $400
COGS recognition transaction: $40 adjustment from deferred to earned COGS
Account | Debit | Credit |
---|---|---|
COGS | 40 | - |
Deferred COGS | - | 40 |
As this scenario demonstrates, when you create an RMA with credit and do no receive the RMA units into inventory, then earned COGS will be understated (and deferred COGS overstated) by the amount of the unreceived RMA units. This under/overstatement applies from the time the RMA credit is processed to the time revenue and COGS are fully recognized and earned.
For example, in Time 4, the credit memo reduces the total expected revenue by $300 from $800 to $500 with the entire amount in deferred revenue. Had the 3 RMA units been received into inventory, total COGS would have been reduced by $150 from $400 to $250 with the entire amount in deferred COGS. However, the RMA units were not received into inventory and were presumably scrapped by the customer. As a result the deferred COGS account is overstated by $150 at Time 4.
For further details, see the Special Case section near the end of this chapter.
When you process an RMA that is not tied or pegged to an originating sales order, A/R cannot associate the returned items to any particular shipment or customer invoice. As a result, previously earned or deferred revenue on the returned items is not changed. In this scenario, costing assumes that all of the revenue associated with the return was previously recognized and credits the entire amount of the RMA in the earned COGS account.
Account | Debit | Credit |
---|---|---|
Inventory | 500 | - |
COGS | - | 500 |
Time 1 – New sales order is created to ship 10 units, no invoicing created
When customers return goods, it is common practice to exchange returned units with new ones with no credit memo for the returned units, and no customer invoice for the replacement units. When the replacement units are shipped to the customer, a sales order is created. However, no invoice will be created for it. When the replacement sales order ships, costing does not know that the order will not be billed and accounts for the transaction as a regular that is to be invoiced as a sales order shipment.
Account | Debit | Credit |
---|---|---|
Deferred COGS | 500 | - |
Inventory | - | 500 |
Time 2 – Order is closed
No invoice will be created for the shipment, and the accounted amount will remain in the deferred COGS account until the sales order line is closed in Oracle Order Management. The closing of a sales order line with uninvoiced items creates an assumption that revenue has been recognized outside of the normal process, or that revenue will never be recognized. In either case, costing moves the uninvoiced amount from the Deferred COGS account to COGS.
Account | Debit | Credit |
---|---|---|
COGS | 500 | - |
Deferred COGS | - | 500 |
The following scenarios illustrate Revenue / COGS Matching for sales orders where customer acceptance is in the business process flow. The underlying assumption in this set of scenarios is that ownership is transferred at the time of shipment. They apply when customer acceptance is not enabled in Oracle Order Management. Scenarios include:
Scenario 1 - Sales order, acceptance, invoicing, revenue recognition, RMA, credit memo
Scenario 2 - Sales order, RMA replacement, acceptance, invoicing, pre-invoicing acceptance
Scenario 3 - Sales order, invoicing, RMA receipt with credit, rejection, RMA no receipt with credit, post-invoicing acceptance
Scenario 4 - Sales order, rejection
Scenario 5 - Uninvoiced sales order
Time 1 – Sales order issue: Qty = 10, Cost = $50, Price = $100
When customer acceptance is enabled for a sales order in Oracle Order Management, revenue recognition must be deferred until the acceptance is received and recorded.
Account | Debit | Credit |
---|---|---|
Deferred COGS | 500 | - |
Inventory | - | 500 |
Time 2 – Customer accepts the entire shipment
No accounting
Time 3 – Customer billed for the entire quantity
Once customer acceptance is received and recorded, A/R creates a customer invoice and the pending receivable.
Account | Debit | Credit |
---|---|---|
Receivables | 1000 | - |
Deferred Revenue | - | 1000 |
Time 4 – Revenue recognition of 50 percent
Revenue on the customer acceptance sales order is 50 percent recognized. This can occur when contract contingencies or other revenue recognition rules require partial recognition.
Account | Debit | Credit |
---|---|---|
Deferred Revenue | 500 | - |
Revenue | - | 500 |
With the 50 percent recognition of sales order revenue, costing creates a COGS recognition transaction that moves 50 percent of the sales order shipment cost from the deferred to earned COGS account.
Account | Debit | Credit |
---|---|---|
COGS | 250 | - |
Deferred COGS | - | 250 |
Time 5 – RMA for 2 units received into Inventory
The customer returns 2 units that are received into inventory. The RMA references the originating sales order lines on which 50 percent of the revenue has been recognized. Costing allocates the RMA amount equally between the deferred and earned COGS accounts.
Account | Debit | Credit |
---|---|---|
Inventory | 100 | - |
Deferred COGS | - | 50 |
COGS | - | 50 |
Time 6 – Credit memo created for RMA for 2 units
A/R elects to debit the entire RMA amount in the deferred revenue account. Contract contingencies or other revenue recognition rules determine whether RMA/credit memos for shipments whose revenue has not been fully recognized will reduce earned or deferred revenue.
Account | Debit | Credit |
---|---|---|
Deferred Revenue | 200 | - |
Receivables | - | 200 |
The allocation of the credit memo amount to the deferred revenue account changes the prior ratio of earned/deferred revenue. As a result, costing creates a COGS recognition transaction to realign the earned/deferred portions of COGS and revenue.
New earned revenue percentage: $500 / ($500 + $300) = 62.5 percent
Required earned/deferred COGS percentages: 62.5 percent / 37.5 percent
Previous earned/deferred COGS percentages: 50.0 percent / 50.0 percent
Total expected COGS balance before RMA/credit memo: $500
Allocated as follows: $500 x .50 = $250 earned, $500 x .50 = $250 deferred
Total expected COGS balance after RMA/credit memo: $400
Allocated as follows: 400 x .50 = $200 earned, 400 x .500 = $200 deferred
COGS allocation required: 400 x .625 = $250 earned, 400 x .375 = $150 deferred
COGS recognition transaction: $50 adjustment from deferred to earned COGS
Account | Debit | Credit |
---|---|---|
COGS | 50 | - |
Deferred COGS | - | 50 |
Time 1 – Sales order issue Order #1: Qty = 10, Cost = $50, Price = $100
Sales Order 1 is shipped to a customer subject to customer acceptance.
Account | Debit | Credit |
---|---|---|
Deferred COGS | 500 | - |
Inventory | - | 500 |
Time 2 – RMA for 4 units on Sales Order 1
Customer returns 4 units of sales order and these are received into inventory.
Account | Debit | Credit |
---|---|---|
Inventory | 200 | - |
Deferred COGS | - | 200 |
Time 3 – Sales order shipment of replacements units on Sales Order 2
Sales Order 2 is created and replacement items are shipped to customer.
Account | Debit | Credit |
---|---|---|
Deferred COGS | 200 | - |
Inventory | - | 200 |
Time 4 – Sales Order 2 is closed
This sales order was created to ship replacement items to the customer. Sales order lines will not be invoiced as replacements are provided to the customer at no cost as a gesture of good will. When the sales order is closed, costing moves the cost of the shipped items from the deferred to earned COGS account.
Account | Debit | Credit |
---|---|---|
COGS | 200 | - |
Deferred COGS | - | 200 |
Time 5 – Acceptance and invoicing of 10 units on Sales Order 1
The customer sends a customer acceptance notification for the 10 units in sales order 1, and A/R invoices the customer for these units.
Account | Debit | Credit |
---|---|---|
Receivables | 1000 | - |
Deferred Revenue | - | 1000 |
At this point in time, the proportion of earned/deferred in revenue and COGS are no longer the same. The transaction flow generated $1000 in deferred revenue and only $300 in deferred COGS. The closing of Sales Order 2 in the previous step reduced the deferred account by $200 and booked this amount to earned COGS.
Note: In order to keep the COGS accounts properly synchronized with the revenue accounts when the transactions span multiple accounting periods, a manual journal entry may be needed that reverses the accounting generated by the replacement order (Sales Order 2). This adjustment increases the Deferred COGS account balance to $500 and reduces the earned COGS account balance to zero which exactly synchronizes with the revenue accounts.
Account | Debit | Credit |
---|---|---|
Deferred COGS | 200 | - |
COGS | - | 200 |
Time 6 – Revenue recognition of 50 percent - Sales Order 1
A/R recognizes 50 percent of the $1000 revenue for Sales Order 1.
Account | Debit | Credit |
---|---|---|
Deferred Revenue | 500 | - |
Revenue | - | 500 |
With the 50 percent recognition of sales order revenue, costing creates a COGS recognition transaction that moves 50 percent of the $300 cost of Sales Order 1 from the deferred to the earned COGS account.
Account | Debit | Credit |
---|---|---|
COGS | 150 | - |
Deferred COGS | - | 150 |
At this point in time, the proportion of earned/deferred in revenue and COGS is no longer the same. The transaction flow generated $500/$500 or 50 percent in earned/deferred revenue, and the earned/deferred COGS account balances for the combined orders are $150/$350
Important: In order to keep the COGS accounts properly synchronized with the revenue accounts when the transactions span multiple accounting periods, a manual GL journal entry is needed to increase the earned COGS for the combined orders to $250.
Account | Debit | Credit |
COGS | 100 | - |
Deferred COGS | - | 100 |
This adjustment results in earned/deferred COGS account balances of $100/$100 or 50 percent for Sales Order 2 to $100, and $250/$250 or 50 percent for the combined orders.
This procedure is required if you want to synchronize revenue/COGS matching across an originating sales order with an RMA, and an associated unbilled replacement sales order whose cost is recognized when the order is closed.
If the accounting impact is not material or the transaction flow does not cross accounting periods, an alternative accounting approach is to forego the manual GL journal entries. This will result in the early recognition of COGS for unbilled replacement orders and a reduced recognition of COGS in subsequent periods on the originating sales order.
Time 1 – Sales order issue: Qty = 10, Cost = $50, Price = $100
A sales order is shipped to customer subject to customer acceptance.
Account | Debit | Credit |
---|---|---|
Deferred COGS | 500 | - |
Inventory | - | 500 |
Time 2 – Customer billed for the entire quantity
A/R creates an invoice that bills the customer for the sales order shipment.
Account | Debit | Credit |
---|---|---|
Receivables | 1000 | - |
Deferred Revenue | - | 1000 |
Time 3 – Revenue recognition of 50 percent
When customer acceptance is enabled for a sales order in Oracle Order Management, revenue recognition must be deferred until the acceptance is received and recorded. The attempt to recognize revenue fails.
Time 4 – RMA receipt with credit for 2 units, received into inventory
The customer returns 2 units for credit that are received into inventory.
Account | Debit | Credit |
---|---|---|
Inventory | 100 | - |
Deferred COGS | - | 100 |
Time 5 – Credit memo created for RMA for 2 units
A/R creates a credit memo and the entire amount is allocated to deferred revenue because no revenue has been recognized.
Account | Debit | Credit |
---|---|---|
Deferred Revenue | 200 | - |
Receivables | - | 200 |
Note: No COGS recognition transaction is needed because there is no change in proportion of earned/deferred revenue.
Time 6 – Sales order shipment is rejected by customer
No accounting.
Time 7 – RMA for 4 units into scrap subinventory
An RMA for 4 units is received into a scrap asset subinventory for inspection and subsequent disposal.
Account | Debit | Credit |
---|---|---|
Expense Subinventory | 200 | - |
Deferred COGS | - | 200 |
Note: You must set up a scrap asset subinventory so that a specified scrap expense account is charged upon RMA receipt.
Time 1 – Sales order issue: Qty = 10, Cost = $50, Price = $100
A sales order is shipped to the customer and is subject to customer acceptance.
Account | Debit | Credit |
---|---|---|
Deferred COGS | 500 | - |
Inventory | - | 500 |
Time 2 – Customer rejects the sales order shipment
The customer rejects the sales order shipment and does not return the rejected items because these will be scrapped at the customer site. The sales order line is closed and costing creates a COGS recognition transaction to record the earned cost.
Account | Debit | Credit |
---|---|---|
COGS | 500 | - |
Deferred COGS | - | 500 |
On orders where customer acceptance has been enabled, you cannot close a sales order line until the line is accepted. Once the sales order line is accepted, the transaction flow and accounting is the same as sales orders where customer acceptance has not been enabled. See: Uninvoiced Sales Order.
Oracle Cost Management supports the allocation of item cost between earned and deferred COGS for Assemble to Order (ATO) and Pick to Order (PTO) items. Revenue/COGS synchronization for configured items is achieved by matching a shipped, costed line to the invoiceable line that it most closely relates to. If the shipped line is invoiced, then the revenue recognition schedule for that line drives COGS recognition. If the shipped line is not invoiced, then COGS for that line will be driven by the revenue recognition for the nearest invoiced line that it rolls up to.
You can synchronize revenue/COGS for the following types of configured items:
Kit (PTO without options)
ATO model
PTO model
PTO model with imbedded ATO model
A kit is a grouped set of items that are sold together as a unit and in which there are no optional items. A BOM is used to define the kit's components. In the Oracle e-Business Suite, sales orders, price lists, and invoices are created and managed at the kit level. However, order shipments and shipment costs are managed at the included item level. The following example illustrates how revenue and COGS are synchronized after the shipment of a kit.
Kit item K1 is composed of two included items, A and B. Items A and B are shipped but only K1 is invoiceable.
Ship Model Complete
When a kit is shipped with all of its included items, a deferred COGS transaction is created for each of the shippable, costed items. In this example, these are items A and B. When A/R invoices and recognizes revenue for kit K1, costing first performs a check to determine whether all of the kit's items have been shipped. In this example, if the kit is ship model complete, costing creates a COGS transaction for item A and item B which results in the recognition of earned COGS for A and B that is proportional to the earned revenue for kit K1.
Non-ship Model Complete
Non-ship model complete occurs when you invoice the kit, but ship only part of the included items that make up the kit. For example, item A is shipped and the model is invoiced before B is shipped. When revenue is recognized, costing only creates a COGS recognition transaction for the shipment line with item A. Only when item B is subsequently shipped will costing apply the earned revenue percentage.
An Assemble to Order (ATO) model is a configuration that is manufactured or assembled in response to a customer order that includes both mandatory and optional items. The ATO model is created using a model bill of material with included and optional items and option selection rules. It is configured during the entry of a customer order and may be shipped to the customer complete or in staged shipments.
In the Oracle e-Business Suite, it's the ATO model and its optional items that are ordered, priced, and invoiced. However, it's the configured item (star item) that gets shipped and costed.
The following diagram illustrates an ATO model that is defined by a bill of material and routing that produces a model with a rolled-up cost, and optional items O1 and O2. During sales order configuration, the ATO model is a mandatory order line selection while one or both of the optional items (O1 and O2) can be selected. The configured item ATO* is shipped. However, it's the ATO model (and its included items) O1 and O2 that are invoiced.
A Pick to Order (PTO) model is a configuration that is fulfilled in the warehouse in response to a customer order that includes both mandatory and optional items. The PTO model is created using a model bill of material with included and optional items, and option selection rules. It is configured during the entry of a customer order, picked and fulfilled in the warehouse, and may be shipped to the customer complete or in staged shipments.
In the Oracle e-Business Suite, it's the PTO model and its optional items that are ordered, priced, and invoiced. However, any combination of the model line, included items, and optional items can be shipped and costed.
The following diagram illustrates a PTO model item that is composed of included items A and B, optional item O1, and option class OC with included item C and optional item O2. PTO models can be shipped complete or in stages with multiple shipments, depending on the availability of the model's specified items.
For example, all of the model's items (PTO Model, A, B, O1, and O2) are shipped (option classes are not shippable or costing-enabled). When A/R invoices the customer for the configured model, only three of the items are invoiced (PTO Model, O1 and O2). Items A and B are included items in the model and are not priced or invoiced separately. Model option C has no price and is not invoiceable. All items except option class OC are costed.
When the six sales order lines are ship confirmed, costing raises a COGS recognition event for each shipment line and books the item cost into a deferred COGS account. When A/R invoices and recognizes revenue for PTO Model and options O1 and O2, costing applies the revenue recognition percentage to the costed items and records earned COGS for those items. In cases where a model item is not invoiceable, the revenue recognition percentage of the nearest parent item is used.
A PTO model may have one or more ATO models defined in its Bill of Material. For example, PTO Model 2 is composed of included items A and B and optional items ATO2 and C2. In this example, PTO2, A, B, ATO2* and C2 are shipped, but PTO2, ATO2 and its options and C2 are invoiced.
This is no different than the previous example. The ATO is just another shippable line that must have the percentage applied when it is passed from AR for the top model.
For internal drop shipments to customers, Cost Management only synchronizes revenue and COGS in the customer facing Operating Unit (OU) when advanced accounting is enabled. Revenue/COGS synchronization is not performed in the non-customer facing operating units.
For a sales order issue out of the shipping operating unit and other intermediate operating units, the intercompany COGS is not deferred. The application applies the entire cost of the shipment in all of the non-booking operating units to Intercompany COGS and intercompany revenue.
Time 1 – Sales order issue in Booking OU from Ship OU: Qty = 10, Cost = $50, Price = $75
An internal order is created in the booking OU (customer facing OU) and shipped directly to the customer from the shipping OU. An intermediate operating unit is part of the transaction flow. The internal transfer price is $75 in all operating units.
Account | Debit | Credit |
---|---|---|
Intercompany COGS (Shipping OU) | 500 | - |
Inventory (Shipping OU) | - | 500 |
Deferred COGS (Booking OU) | 750 | - |
Inventory (Booking OU) | - | 750 |
In external drop shipment scenarios where shipments are made directly from the supplier to the customer, intercompany revenue and COGS are fully recognized. The revenue and COGS deferrals take place only in the customer-facing booking operating unit.
If you need to immediately recognize the scrapping of physically non-received RMA items, Oracle recommends that you create an RMA with receipt, and then perform a virtual receipt of the unreceived into an asset subinventory designated as a scrap inventory. The valuation account for this subinventory can be set up to point to a scrap valuation or expense account so the RMA receipt is immediately recognized as either an impaired asset or a realized scrap expense.
If your business needs mandate that you process the unreceived RMA items as an RMA – no receipt, then the deferred COGS associated with the originating sales order shipment will be overstated and the scrapping or disposal of returned units will not be booked to a scrap or other designated expense account. Once revenue/COGS are fully recognized, the earned COGS account for the sales order shipment will include the cost of the rejected, unreceived RMA units.
If this cost needs to be reclassified as a scrap/loss/disposal expense, then you can create a manual GL journal entry to transfer RMA no receipt amounts from deferred COGS to a designated expense account.
Cash and Carry
The physical flow for cash and carry sales orders typically includes picking, staging, and shipment activities. Goods can be picked up in a warehouse or show room by the customer, and paid in cash. However, the sales order lines are ship confirmed and a sales order issue transaction is created in the same way as a non-cash sales order. Cash and carry sales orders are interfaced with Oracle Receivables that invoices the sales order and recognizes revenue as earned.
When the sales order issue transaction is created, the accounting flow is the same as that of regular non-cash sales orders. The sales order issue amount is charged to the deferred COGS account and transferred to earned COGS when a revenue recognition event is received from Oracle Receivables.
RMA Receipt after Standard Cost Update
When you perform an RMA receipt for an item which references the originating sales order, Oracle Cost Management looks up the cost of the item at the time of shipment and credits the COGS account for that amount. If the order is shipped from a standard costing method organization and you have performed a standard cost update on the item after the item shipped, but prior to the RMA receipt, then the difference between shipped and updated cost is credited to the deferred COGS account debited at shipment.
For example, an item is shipped at a cost of $100, a standard cost update changes the cost to $110, and an RMA receipt is performed. Revenue on this item has not been recognized. In this scenario, the accounting entries are as follows:
Accounting when the item ships:
Account | Debit | Credit |
---|---|---|
Deferred COGS | 100 | - |
Inventory | - | 100 |
Then an RMA receipt is performed:
Account | Debit | Credit |
---|---|---|
Inventory | 110 | - |
Deferred COGS | - | 100 |
Standard Cost Update Adjustment | - | 10 |
Note: The COGS account defined in the Organization Parameters window will be used for the Standard Cost Update Adjustment account.