Accounting concepts revolve around the concept of Generally Accepted Accounting Principle/Policies often referred to as GAAP. The two most fundamental principles among these are
- Revenue recognition and
- Matching COGS (Cost of the goods sold)
In a typical manufacturing and distribution setup environment, intercompany dropship scenario is the need of the hour. In an intercompany drop ship case, the intercompany invoice creation is not interrelated or dependent on the external customer invoice creation. This can create a mismatch between the revenue and COGS at the Selling Operating Unit (OU) and hence will not be of GAAP compliance.
This blog provides insights on how the standard features in Oracle E-Business Suite can help facilitate the Selling Operating Unit (OU) to fulfill this requirement in drop ship scenarios.
Today most of the multinational conglomerates have internal drop shipment processes as part of their manufacturing and order fulfilment processes. The group companies can effectively concentrate on their core strength areas such as manufacturing / distribution which act as separate entities within the chain.
The intercompany transaction flow setup in Oracle solves this need. The setup allows both transactional and financial relationship between two entities/OUs commonly known as starting OU and ending OU. Oracle also allows multiple intermediary nodes to come in-between these two OUs i.e. there can be intermediary OUs between the Starting OU and Ending OU to satisfy the conditions stated in the above example.
Sample Intercompany Transaction Flow Setup in Oracle with Intermediary Nodes
In the Oracle intercompany drop ship sales order functionality, a sales order will be placed on one OU (herein referred as selling OU). However, the shipment for the same sales order will be from an inventory organization under a different OU (herein referred as distribution OU/shipping OU). As part of this process, selling OU will raise an invoice to the customer and the distribution OU will raise an intercompany AR invoice to the selling OU at an agreed transfer price. The selling OU will then record these invoices as intercompany AP invoices. Ideally, these transactions should happen automatically as soon as the shipment takes place.
However if there are more than two OUs in the intercompany transaction flow and there is a need to generate multiple intercompany invoices for each set of OUs between the starting OU and ending OU, an additional solution called ‘Advanced Accounting’ will need to be used between these OUs.
These transactions are not dependent on the customer Invoice, raised by the selling OU. This may potentially cause mismatch between revenue recognition and COGS recognition at the selling OU level. The external invoice at the selling OU would have been put on hold or would not have been raised for various reasons such as consolidated invoicing at the end of the month, a billing hold event that would have occurred after the shipment, need for post billing customer acceptance etc. In all these cases, there is a possibility that COGS get recognized and accounted in the selling OU by way of automatic intercompany AP invoices before even before the revenue is recognized and accounted for. This is also NOT in line with the Generally Accepted Accounting Principle of revenue recognition and matching COGS.
The following chart represents the overstatement, understatement, and correct profitability of for a given period on sample basis:
Solution Overview
The following section provides a brief overview on the solution provided by Oracle for intercompany transaction flows:
Advanced accounting feature in the intercompany transaction process is primarily used when intermediary nodes are involved, and multiple intercompany invoices are to be created between different OUs for physical movement of the same goods. On enabling the Advanced accounting option between the OUs in the intercompany transaction flow, Oracle creates ‘Logical Material Transactions’ and ‘Logical Accounting Entries’.
If more than two OUs are used in the intercompany transaction flow, the system automatically checks this ‘Advanced Accounting’ checkbox. For transaction flows that contain two OUs, users can select this check box to use advanced accounting. For this document, let us assume only two OUs are present in the intercompany transaction flow, understand the impact of advanced accounting and how it creates logical entries.
Accounting entries comparison:
Now we can see that directly cost of goods sold is directly debited even before the external customer invoice has been created if Logical entries are not used. This does not show a clear and fair financial statement and here the profitability for that period/year is unduly decreased.
If Logical entries are used, we can notice a significant difference in the accounting entries of the selling OU. Here the DCOGS account would be shown as an asset in the balance sheet as equivalent of stock owned by the selling OU at a different location. This process ensures that costs are not booked unless and until the revenue is booked and shows a clear and fair financial statement where the profitability is not unduly increased or decreased. This process ensures that both the revenue and matching COGS are accounted for and recognized during the same period.
The other side of the coin
Though Oracle provides this flexibility, it comes with its own set of disadvantages. The disadvantages would be:
- Firstly, and most importantly, it brings in lot of item maintenance overhead. All the items pertaining to the inventory organization (IO) of the shipping OU must be assigned to this logical IO of the selling OU, so that Oracle can create logical entries. This may be a big overhead considering the number of items and size of the organization. But this is generally overcome as mostly they would be common items between the plant and distribution centres.
- Secondly, only one IO pertaining to selling OU can be used for logical transactions. If the selling OU has more than one IO, then only one IO can be selected for logical transactions purposes. The decision to choose one IO for this purpose would be a tough one to make especially if the IOs are based in different physical/geographical locations.
Conclusion
Oracle provides the flexibility to use advanced accounting in intercompany drop ship scenarios even if the intercompany transaction flow has only two OUs. This enables the customer facing OU/selling OU to follow the Generally Accepted Accounting Principle (GAAP) for cost matching concept, thereby synchronizing the revenue and matching costs. As we know that every coin has two sides, this must be a calculated decision considering the pros of GAAP compliance, correct revenue, and profitability reporting vis-à-vis the overheads in terms of item maintenance.
Thanks for your time in reading this article!
References
