overview of intercompany invoicing

Overview of Intercompany Invoicing

An Oracle White Paper July 2005


EXECUTIVE SUMMARY...................................................................................................................................................... 1 INTRODUCTION ................................................................................................................................................................... 1 MAJOR CONCEPTS AND TERMINOLOGY................................................................................................................. 2 The Organization Model........................................................................................................................................................... 2 Intercompany Invoicing............................................................................................................................................................ 4 Customer and Supplier relationship........................................................................................................................................ 6 Intercompany Transaction Flow ............................................................................................................................................. 7 Transfer Price.............................................................................................................................................................................. 9 Freight ........................................................................................................................................................................................ 10 Tax .............................................................................................................................................................................................. 11 Currency..................................................................................................................................................................................... 11 BUSINESS FLOWS................................................................................................................................................................ 14 External Drop Shipment......................................................................................................................................................... 14 Global Procurement (Central Procurement) ....................................................................................................................... 19 Internal Drop shipment (Central Distribution) .................................................................................................................. 23 Internal Fulfillment .................................................................................................................................................................. 27 SCENARIOS NOT SUPPORTED IN INTERCOMPANY TRANSACTIONS...................................................... 28 Scenario 1 – Internal drop shipment from an internal organization to another internal organization ..................... 29 Scenario 2 – Drop Shipment and intercompany transactions for Non-Shippable, Non-Stockable and Non-Transactable items.................................................................................................................................................................... 29 Scenario 3 – Drop Shipment and Intercompany transactions for Non-invoiced items .............................................. 29 Scenario 4 – Global Procurement for projects with expense destination and transfer pricing .................................. 30 Scenario 5 – Global Procurement with shop floor destinations and transfer pricing .................................................. 30 Scenario 6 – Consigned inventory for Global Procurement flows.................................................................................. 30 Scenario 7 – Handling encumbrances in Drop Ship and Global Procurement flows.................................................. 30 Scenario 8 – Retroactive pricing in Global Procurement.................................................................................................. 30 Scenario 9 – P-Cards in Global Procurement ..................................................................................................................... 30 Scenario 10 – Advanced Sales functionality between operating units............................................................................. 30 Scenario 11 – Advanced cross border trade management ................................................................................................ 31 Scenario 12 – Inter Org Transfers......................................................................................................................................... 31 Scenario 13 – Internal Orders with expense destination................................................................................................... 31 CONCLUSION ....................................................................................................................................................................... 31 ADDITIONAL RESOURCES............................................................................................................................................. 31

Figure 1 - Organization Hierarchy Model.............................................................................................................................. 2 Figure 2 - The organizational model mapped in Oracle Applications .............................................................................. 3 Figure 3 - Intercompany Transaction Flow........................................................................................................................... 4

ii

Figure 4 - Advanced Accounting enabled.............................................................................................................................. 5 Figure 5 - Intercompany Transaction Flow........................................................................................................................... 5 Figure 6 - Logical Material Flow.............................................................................................................................................. 5 Figure 7 - Customer - Supplier relationship........................................................................................................................... 6 Figure 8 - Possible intercompany transaction flow options................................................................................................ 8 Figure 9 - Logic for Transfer Price.......................................................................................................................................... 9 Figure 11 - External Drop shipment..................................................................................................................................... 15 Figure 14 - Central Procurement ........................................................................................................................................... 19 Figure 15 - Central Distribution ............................................................................................................................................ 23 Figure 16 - Internal Orders..................................................................................................................................................... 27 Figure 17 - Internal Sales Orders Flow Not Supported .................................................................................................... 29

iii

Intercompany Invoicing

EXECUTIVE SUMMARY More and more companies are doing business globally, and taking advantage of the operations and tax benefits that can be achieved by running operations throughout the world. These companies have multiple operating units and organizations around the world. When goods are shipped or received, the financial ownership through these organizations does not necessarily follow the physical movement of goods. Oracle Applications support three main logistics needs of global organizations – Central Distribution, Central Procurement and Drop Ship. This whitepaper details the modeling of the global logistics in Oracle Applications as in 11.5.10.

INTRODUCTION A corporation manages its global operations in various countries through a network of subsidiaries, separate legal entities, licensees and several associated label franchisee. This complex network of operations is necessitated to take care of local legal and fiscal environment, which prevail in each of those countries. Following are few examples:

• In tele-communications industry, most of the countries stipulate mandatory domestic company partnership.

• Most of the steel and aluminum companies in Asia sell their entire output to another marketing company.

• Automobile industries are increasingly centralizing their sourcing activities globally to leverage their combined volumes for a better price from their suppliers.

• Trading companies are setup in tax haven nations to take advantage of bilateral and multi-lateral trade agreements to minimize the tax.

Consider the following two examples:

Example 1

Vision Operations (V1) is based in USA. It has a 100 % owned subsidiary company called Vision Asia (VA). VA in turn has two subsidiaries – Vision Japan (VJ) and Vision China (VC). VJ has manufacturing facilities in Osaka (O1) and distribution center at Tokyo (T1). Due to tax advantages, V1 sources all the goods from china through VJ. Though the financial transactions between V1 and VC are routed through VJ, logistic movement of goods takes place directly between V1 and VC.

Example 2

Continuing the above example, Vision Operations (V1) has another subsidiary company called Vision Singapore (VS), 100 % that it owns. Individual plants procure components from their own suppliers. VS centralizes all the commodity (like steel, Aluminum etc.,) procurement needs of Vision Operations across


1

world and procures the material on behalf of all VJ and its subsidiary plants and places purchase orders on its suppliers. However, material is directly shipped from the suppliers to all the manufacturing plants.

Figure 1 - Organization Hierarchy Model

A key requirement for the global implementation of Oracle applications in such a complex business environment is the ability to process "intercompany transactions," where one business unit invoices another for transfer of goods and services. Often these intercompany transactions involve transactions related to general expenses, funds transfer, salary transfers, asset transfers, royalty payments and product transfers. This paper discusses only those intercompany transactions that are related to product transfers such as sales of goods and internal procurement.

This paper provides setup steps, implementation tips, and guidance for coordinating the many departments, which become involved with intercompany invoicing. We would be discussing implementation of intercompany invoicing for the fictitious organization as depicted in Figure 1.

MAJOR CONCEPTS AND TERMINOLOGY

The Organization Model When implementing business applications worldwide, companies need to address the issue of how to separate certain information that is specific to each operating unit while at the same time making other types of information globally accessible.

Within Oracle applications, this is handled through the "multi-organization" configuration: a single installation of software, which supports the independent operation of your business units (such as sales order bookings and invoices), with key information being shared across the entire corporation (such as on hand inventory balances, item master, customer master, and vendor master).

While the organization model continues to evolve with advanced releases of the applications, core structures involved with intercompany invoicing remain as follows:

Set of Books - the financial reporting entity for which there is a chart of accounts, currency, and financial calendar for securing ledger transactions.

Legal Entity - the organization at whose level fiscal and tax reporting is prepared.

Operating Unit - the organization which is considered a major "division" or "business unit", at whose level business transactions are segregated – sales orders, invoices, cash applications, payables, and purchasing documents, for example. Certain Oracle applications such as OE, AR, AP, and parts of PO are "partitioned" at this level, meaning that operating units have visibility only to their own transactions.


2

Inventory Organization - the organization at which warehousing, manufacturing, and/or planning functions are performed.

The implementation should be top to bottom approach. You need to clearly understand the corporation’s organizational setup and map it to Oracle’s Multi-Org’s model. For example, the organization structure depicted in figure 1 can be modeled in Oracle applications as depicted in Figure 2.

Figure 2 - The organizational model mapped in Oracle Applications

Following are the key implementation points you need to look into:

• Understand the corporation business entities and the relationship between them. Identify selling-shipping relationships and procuring-receiving relationships.

• Understand Oracle multi org structure and the building blocks in data structure.

• Breakup the business relationships into manageable process flow and map it to various entities in Oracle applications.

• Consider how your designs will stand up to changes over time. Challenge them with extensive unit and integrated test plans which simulate (1) the current environment and (2) scenarios going forward at least 5 years. Integration testing, in particular, is a great opportunity for validating how well your business processes and system transactions will flow throughout your applications worldwide.


3

Intercompany Invoicing Intercompany invoicing is done when one organization offers products / services to another operating unit. For example, when a customer order is processed through the order cycle and then invoiced, the selling organization records journal entries to accounts receivable, revenue, and as applicable tax and freight. The shipping warehouse records journal entries to its inventory asset and cost of goods sold accounts. When this scenario involves a selling organization in one business unit but a shipping warehouse in a different business unit, additional accounting must take place. The shipping organization needs to bill the selling organization at transfer price, and the selling organization needs to make the corresponding payment.

Note that intercompany invoicing is possible only between two operating units. You cannot invoice between two inventory orgs if they belong to the same operating unit.

The intercompany AR invoice is the transaction used by Oracle to record intercompany receivable accounting for the shipping organization: debiting intercompany AR (at transfer price), tax, and freight and crediting intercompany revenue.

The intercompany AP invoice is the transaction used by Oracle to record the payable accounting for the selling organization: debiting intercompany COGS (at transfer price) and freight and crediting the intercompany payable account. Ideally, these transactions should happen automatically and as soon as possible after the shipment takes place. This can be done using the intercompany invoicing process within Oracle applications.

Oracle supports intercompany invoicing when:

• Shipping operating unit is different from selling operating unit and

• Receiving operating unit is different from procuring operating unit.

For a single process flow (one procure-to-pay cycle or order-to-cash cycle), you can model Oracle to generate intercompany invoices between two or more operating units. The building block of intercompany invoicing is the setup of intercompany transaction flow.

Figure 3 - Intercompany Transaction Flow

The intercompany transaction flow establishes the physical flow of goods and financial flow relationship between two operating units. The intercompany transaction flow establishes the relationship between one operating unit (known as Start Operating Unit) and another operating unit (known as End Operating Unit) about the actual movement of goods. Similarly, it also establishes the invoicing relationship between Start Operating Unit and End Operating Unit.

Intercompany transaction flow is of two types – shipping flow and procuring flow. You need to setup intercompany transaction flow of type shipping when selling operating unit is different from shipping operating unit. You need to setup intercompany transaction flow of type procuring when buying operating unit is different from receiving operating unit.


4

By enabling advanced accounting for an intercompany transaction flow, you would be able to generate multiple intercompany invoices between different operating units for the same physical movement of goods.

Figure 4 - Advanced Accounting enabled

Oracle supports intercompany invoicing for both shipping and procuring flows. However, you need to use the ‘Advanced Accounting’ option for enabling intercompany invoicing for procuring flow even if it involves only two operating units. If you do not enable ‘Advanced Accounting’ option at the intercompany transaction header, then no logical transactions will be generated and no intermediate nodes can be defined.

You need to define intercompany relations between each pair of operating units in the intercompany transaction flow. When advanced accounting is enabled for an intercompany transaction flow, you will be able to define multiple intercompany relationships between different operating units. If advanced accounting is set to No, then an intercompany transaction flow can have only one intercompany relation (it is between start operating unit and end operating unit).

Figure 5 - Intercompany Transaction Flow

At each pair of intercompany relationship, you will define the intercompany accounts, and currency code to be used on AR and AP invoices.

Note that in Figure 5 - Intercompany Transaction Flow, physical goods never flow through intermediate operating unit. Oracle creates ‘Logical Material Transactions’ between the operating units, based on which intercompany invoices between multiple operating units are raised. No logical transactions will be created when you do not choose ‘Advanced Accounting’. For example, the transactions in Figure 4 can be broken down as depicted in Figure 6.

Figure 6 - Logical Material Flow

Logical transactions are useful to record financial transactions between two operating units without physical movement of goods. For example, in Figure 6 - Logical Material Flow, Vision Japan is an intermediate operating unit through which no physical goods flow. However, it is a financial intermediate node, which is involved in intercompany invoice flow. To facilitate accounting in the intermediate OUs, logical intercompany


5

receipt and issue transactions are created. Similarly, logical receipt and logical sales order issue transactions are created for those receipts and issues that are not accompanied with physical receipt and issue of goods.

‘Advanced Accounting’ option is not available for internal requisitions – internal sales order business flow. Though you can set the ‘Advanced Accounting’ flag at Intercompany Transaction Flow header to ‘Yes’, system ignores the flag and does not generate any logical transactions. This means you cannot have an intermediate financial node in the intercompany transaction flow. Also, you cannot have intercompany invoicing for internal sales order with direct transfer (in shipping network between the inventory organizations) as an option. You have an flexibility to switch off intercompany invoicing for internal sales orders by setting the profile ‘INV: Intercompany Invoice for Internal Orders’ to No.

Intercompany invoicing is possible for inter-org transfers of type ‘In-transit’ only through ‘Internal sales Orders’. No intercompany invoicing is possible if you perform org transfers between two inventory orgs belonging two different operating units without ‘internal sales Orders’. Also note that intercompany invoice cannot be raised for inter-org transfers of type ‘Direct Transfer’ through Internal sales Orders.

Customer and Supplier relationship Intercompany invoicing is widely used in multinational organizations. Sometimes you will find that these companies engage in a customer – supplier relationship.

Figure 7 - Customer - Supplier relationship

For example, in Figure 7, you need to define Vision Japan as a customer in Vision China operating unit. Similarly, Vision China should be defined as a supplier in Vision Japan. When you define an intercompany relationship between Vision Japan and Vision China, actually you are establishing an internal customer and supplier relationship. Similar is the case for every intercompany relationship in an intercompany transaction flow. However, at present intercompany invoicing does not support any sales credit check.


6

Intercompany Transaction Flow Intercompany transaction flow with advanced accounting describes the financial accounting flow between start operating unit and end operating unit through a series of intermediate operating units. However, all the costing transactions are carried out at inventory organization. This section describes the role of inventory organizations in inventory transaction flow with advanced accounting.

Intercompany transaction flow is created between two operating units (called as start Operating unit and End Operating Unit). For shipping flow, you can create as many number of transaction flows as there are inventory organizations in start operating unit (shipping operating unit) and for procuring flow, you can create as many number of transaction flows as there are inventory organizations in end operating unit (receiving operating unit). Similarly, you can create intercompany transaction flows for specific item categories. All logical transactions in intermediate operating units and start / end operating unit will be logged in the inventory organization specified in each intercompany relationship.

Inventory Organization in intermediate and end operating unit are used for logging logical transactions based on which costing will be done. Similarly, you have to run your intercompany AR and AP programs in those operating units. More often you will find that intermediate operating units do not have any physical warehouses. However, you have to create inventory organizations though no physical entities exist, for recording logical transactions and for running your intercompany AR and AP programs.

In Oracle, Intercompany Transaction Flow as a header and the intercompany relationship between each pair of nodes is modeled as intercompany relationship lines. Following are the attributes of the header:

1. Start Operating Unit 2. End Operating Unit 3. Flow Type – Shipping / Procuring 4. Ship From (for Shipping flows) and Ship To (Procuring Flows) 5. Category (Purchasing category for purchasing flows and Inventory category for shipping flows) 6. Item Pricing Options for Asset Items (PO/Transfer price available for procuring flows only) 7. Item Pricing Options for Expense Items (PO/Transfer price available for procuring flows only) 8. Start date and End Date for the Transaction flow 9. Advanced Accounting flag (Set to Yes for creating logical transactions and defining intermediate

nodes). This flag should be set to Yes for all Procuring Flows.

For each transaction relationship between two nodes, you can define the following: 1. For Relationship between nodes:

a. From Operating unit b. Inventory Org of From operating unit c. To Operating Unit d. Inventory Org of To Operating unit. (Not mandatory if the ‘Advanced Accounting is set

to No). If advanced accounting flow is set to ‘No’ at Intercompany Transaction Flow header, then you can define only one pair of From Operating unit and To operating unit.

2. For AR invoicing: a. Customer (Bill – To customer) b. Customer Number c. Customer Location


7

d. AR Transaction Type e. Intercompany COGS Account f. Currency Code (Currency code of the order/ Currency Code of the From Operating unit

/ Currency Code of the End Operating Unit). 3. For AP Invoicing:

a. Supplier b. Supplier site c. Freight Account d. Inventory Accrual Account e. Expense Accrual Account

Figure 8 - Possible intercompany transaction flow options

You can create additional transactional flows between operating units by defining item category for each intercompany transaction flow.


8

Transfer Price Transfer Price is the price at which an item is transferred from one operating unit to another operating unit. Transfer price is also usually called as “Arm’s length Price” and is generally guided by the originating country’s accounting standards.

Logic for transfer price determination for shipping flows is explained in Figure . However, for procuring flow, you can specify whether the transfer price is same as the PO price in intercompany transaction flow. This means that an operating unit sells at the same price at which it procured the item to another operating unit. If you specify that the transfer price is not same as the PO price in the intercompany transaction flow, then system uses the same logic as depicted in . For procuring flow, you specify the pricing option (transfer price or PO price) separately for asset and expense items.

Figure 9 - Logic for Transfer Price


9

You can make use of the external API feature of the intercompany invoicing to develop your own custom logic for determining transfer price. For example, if you want to use the cost price as the transfer price, then build your custom logic to fetch the cost price. The name of the external API is MTL_INTERCOMPANY_INVOICES.get_transfer_price and the name of the file is INVICIVB.pls located at $INV_TOP/patch/115/sql. Ensure that the API returns transfer price along with currency code.

Please ensure that the transfer price is not 0. Oracle expects that the transfer price should be greater than 0. You will be able to create an intercompany AR invoice but will not be able to create an intercompany AP invoice resulting in intercompany reconciliation discrepancy.

You need to set the profile “QP: Security Control” to ‘Off’, to generate logical transactions and for raising the intercompany AR invoice.

Transfer Price for ATO / PTO items

Oracle uses the same logic as mentioned in figure 9. In addition to the above, oracle uses the following logic to determine the transfer price and subsequent AR invoicing.

Scenario Logic Drop Shipment Sales Order and Advanced Accounting set to ‘No’.

If profile "INV: Use Model & Options for Configuration Pricing" is ‘Yes’, use price of model and price of options and create invoice lines for each model and option. If profile is "No" use configured item's price and create one invoice line for configuration item. Price of options is not mentioned. Even if you maintain a price for the ‘* item’ (i.e., configured item), system ignores it.

Drop Shipment Sales Order and Advanced Accounting set to ‘Yes’.

System looks for the price of the ‘* item’ (i.e, configured item) and creates one invoice line for configured item. If the price of the ‘* item’ is not found or is equal to 0, then system rolls up the price of model and price of options and creates one invoice line for configuration item.

Global Procurement and Advanced Accounting set to ‘Yes’.

System rolls up the price of model and price of options and creates one invoice line for configuration item.

Global Procurement and Advanced Accounting set to ‘No’.

Not Supported.

Internal Orders with Advanced Accounting set to ‘Yes’.

System looks for the price of the ‘* item’ (i.e, configured item) and creates one invoice line for configured item. You need to create a price list by rolling up the price of options and model (manually).

Internal Orders with Advanced Accounting set to ‘No’.

System looks for the price of the ‘* item’ (i.e, configured item) and creates one invoice line for configured item. You need to create a price list by rolling up the price of options and model (manually).

Freight Freight charges can be added to the intercompany invoice only for shipping flows. Auto-invoice will apply freight only if you set ‘Allow Freight’ field to ‘Yes’ in the AR transaction type defined at the intercompany transaction relationship between two operating units. You need to define an inventory item with user type as “Freight”. Then assign this item in the profile “Tax: Invoice Item as Freight”. You need to setup a modifier of type “Freight and Special Charge List” and define the freight charge for the “Freight Item”. Freight is a line


10

item on the intercompany invoice and the item to be mentioned on the invoice line is determined from the profile “Tax: Invoice Item as Freight”.

Tax You can also apply tax to intercompany invoices. Auto-invoice will apply taxes only if you set ‘Tax Calculation’ field to ‘Yes’ in the AR transaction type defined at the intercompany transaction relationship between two operating units. Auto-invoice looks for a tax code in the following order, stopping at the first place where it finds a tax code:

1. Ship-To-Site 2. Bill-To-Site 3. Customer 4. Item

If you do not want tax to be calculated on freight lines, make sure that the profile option “Tax: Invoice Freight as Revenue” is set to No. If this is set to Yes, AR creates a line item of type 'Line' on the invoice for the freight amount and the tax will be calculated on the freight line. If the profile is set to No, then the system will create a line item of type ‘Freight’. Logic for determination of Tax Code for the freight will be same as that of any other invoice line item.

You need to setup the same tax structures (tax codes and rates) in Oracle Receivables and Oracle Payables. This will allow AR invoices to be correctly mirrored into intercompany Oracle Payables.

You can offset the tax liability on the AP invoice for VAT purposes. For example, an office in an EU state paying an intra EU invoice can assign a VAT tax and a corresponding Offset tax to an invoice, so it can record and report VAT taxes without actually paying any to other operating unit. If the tax code on the AP invoice line has an associated offset tax and if you enabled the ‘Use Offset Tax’ check box for the supplier site, system creates a default offsetting tax distribution for each tax distribution on an invoice. You can use offset taxes to record the value added tax (VAT) name and amount without paying VAT to other operating unit (the tax distribution and the offset tax distribution net to zero). For example, in the Tax Codes window, you can define an offset tax code named Offset 10 that has a negative 10% rate. You can then define a user-defined tax called VAT 10 that has a 10% rate. You can assign the Offset 10 tax to the VAT 10 tax.

A separate business flow should be identified to treat other charges like insurance, handling charges that affect only one organization and does not affect other organization. For example, custom duties need to be paid on the intercompany invoices in international transactions. Handling of customs duty should be treated as a separate processes from intercompany invoices.

Currency You have different currency options to be used in an intercompany invoice. The attributes that determine which currency to be used in an intercompany invoice for shipping flow are the profile option “INV: Advanced Pricing for Intercompany Invoice” and “Currency Code” attribute in intercompany transaction flow.


11

For shipping flows, currency will be determined by the following decision table:

Flow Type

Use Advanced Pricing Profile

Currency code in Intercompany Transaction Relationship

Currency Code in AR Invoice

Shipping N Does not matter Currency Code mentioned in the price list Shipping Y Shipping Operating Unit Shipping Operating Unit Currency Code Shipping Y Selling Operating Unit Selling Operating Unit Currency Code Shipping Y Order Currency Code Sales Order Currency Code

The attributes that determine on the currency to be used in an intercompany invoice for procuring flow are the profile option “Intercompany: Use Advanced Pricing” and “Currency Code” and “Pricing Option” attributes in intercompany transaction flow.

For procuring flows, currency will be determined by the following decision table:

Flow Type

Pricing Option Use Advanced Pricing Profile

Currency code in Intercompany Transaction Relationship

Currency Code in AR Invoice

Procuring PO Price N Does not matter Purchase Order Currency

Procuring Transfer Price N Does not matter Currency Code mentioned in the price list

Procuring Transfer Price Y Procuring / Shipping Operating Unit Procuring Operating Unit Currency Code

Procuring Transfer Price Y Receiving / Selling Operating Unit Receiving Operating Unit Currency Code

Procuring Transfer Price Y Order Currency Code Purchase Order Currency

Procuring PO price Y Does not matter Purchase Order Currency

Summary Of Profiles

This section summarizes all the profiles used in the intercompany invoicing flows:

Profile Values Description INV: Advanced Pricing for Intercompany Invoice

Yes, No If set to Yes, then system looks for the transfer price in QP. If set to No, then system uses the static price. See the section on Transfer price. System looks for this profile in the ‘From operating unit’ of each intercompany relation in the intercompany transaction flow.

INV: Intercompany Currency Conversion

System uses this currency conversion code for conversion. For example, the currency code in the static price list is EUR and an intercompany invoice has to be created in USD, then system will look into this Conversion Code for exchange rates. System looks for this profile in the ‘From operating unit’ of each intercompany relation in the intercompany transaction


12

flow. INV: Intercompany Invoice for Internal Orders

Yes, No If set to yes, then you can raise an intercompany invoice for internal orders.

INV: Use Model & Options for Configuration Pricing

Yes, No See the section on Transfer price for ATO/PTO items. System looks for this profile in the ‘From operating unit’ of each intercompany relation in the intercompany transaction flow.

Yes, Price Not As Incoming Cost Yes, Price As Incoming Cost

CST: Transfer Pricing Option

No

Applicable only for internal orders. If the profile is “Yes, Price Not As Incoming Cost”, then the incoming cost to the receiving org is still the sending org’s inventory cost. the values are derived from: • value in cogs = sending org’s

inventory cost • value in inter-company expense =

transfer price • value in profit in inventory = transfer

price - sending org’s inventory cost If the profile is “Yes, Price As Incoming Cost”, then the incoming cost to the receiving org is purely based on the Transfer Price. The accounting entries are the same as if it were a normal sales order and purchase order. No Profit in Inventory account is necessary. The values are derived from: • Value in COGS = Sending Org’s

inventory cost • Value in Inter-company Expense =

Transfer Price QP: Security Control On, Off When this profile is set to ‘Off’, will restrict

the users of other operating units to retrieve the price. It is recommended to set this profile to ‘Off’; otherwise the creation of the logical transactions will fail.

Tax: Allow Override of Tax Code

Yes, No System will retrieve the tax code for the freight only if this option is set to ‘Yes’ and passes it to AR for freight. It is recommended that you set this option to ‘Yes’ otherwise, system will default the profile ‘Tax : Invoice Freight as Revenue’ to ‘No’ and ‘Tax: Inventory Item for fright’ to NULL instead of retrieving the profile values. System looks for this profile in the ‘From operating unit’ of each intercompany relation in the intercompany transaction flow.

Tax: Inventory Item for Freight Define an inventory item with user type as ‘Freight’ and assign it here. System uses this for description on the freight line as well as to retrieve the tax code applicable for the freight. System looks for this profile in the ‘From operating unit’ of each


13

intercompany relation in the intercompany transaction flow.

Tax: Invoice Freight as Revenue

Yes, No This profile determines whether the fright lines are invoiced as revenue lines. If you want your freight lines to be taxed, then set this profile to ‘Yes’. System looks for this profile in the ‘From operating unit’ of each intercompany relation in the intercompany transaction flow.

When you implement intercompany invoicing, following key points need to be noted:

• Identify the ‘Internal Sales Orders’; ‘Procure-to-Pay’ and ‘Order-to-Cash’ business flows.

• Identify the parties involved in the business flow – whether the business flow cuts across multiple business units or involves only one operating unit.

• Identify the need for intercompany invoicing between different business units involved in the process flow. If three or more business units are involved in a process flow, then you need to use ‘Advanced Accounting’ option for the intercompany transaction flow. If only two business units are involved, using ‘Advanced Accounting’ option will give you more transparency in material flow.

• Examine the intercompany invoice entries. You need to look at the following entities – transfer price, freight, tax and currency.

• Determine the logic for transfer price. Determine whether the standard options can be used. Otherwise customize the logic for determination of the transfer price.

• Determine the accounting standard about the treatment of freight – whether freight needs to be treated as revenue.

• Determine the tax applicable and develop a standardize tax codes across business units so that tax in AR invoice is mirrored correctly into AP invoice.

• Determine the currency to be used in the invoice.

BUSINESS FLOWS Lets look at various business processes that need intercompany invoicing and their mapping in Oracle. We would be looking at the business process, corresponding system transactions and their accounting entries.

External Drop Shipment In this business process the sales order is placed in one operating unit, and goods are directly shipped from a supplier belonging to another business unit. With increased focus on core competency, many corporations out-source to fulfill their market demand for non-core competency products. Often these products are manufactured by contract manufacturers and distributed by a central marketing agency. However, the local arm of the global corporation engages these contract manufacturers. These contract manufacturers directly supply to the global customers.

We will now discuss External Drop Shipment from supplier to customer for Asset Items.


14

Flow 1 – External Drop Shipment from supplier to Customer for Asset Items

An example of external drop shipment for asset items is depicted in Figure 11. Assume that the customer is from Germany and places an order on Vision Operations (V1). The order currency is EUR. To fulfill this order Vision China (VC) places a Purchase order and drop ships the goods from its contract supplier based in Thailand to the customer in Germany. The currency of the PO is THB. VC sends an invoice at transfer price to Vision Japan (VJ) and the invoice currency is CNY. VJ in turn sends an invoice at the transfer price to V1 and the invoice currency is USD.

External drop shipment business flow depicted in Figure 11 is summarized in the following table:

Step Description A Customer places an order on V1. B Sales order is scheduled to be shipped from a supplier of VC. C VC raises a PO on supplier. Purchase price is 400 THB. D Supplier ships the goods directly to the customer. E V1 invoices the customer. Selling price is 20 EUR. F Supplier sends an invoice to VC. G VC issues an intercompany receivable invoice to VJ at transfer price of 150 CNY. H VJ issues an intercompany payable to VC. I VJ issues an intercompany receivable invoice to V1 at transfer price of 20 USD. J V1 issues an intercompany payable to VJ.

Figure 11 - External Drop shipment

System Transactions

Above business steps can be mapped to following system transactions: Step Process Responsible Description

1 Enter, book the customer order

V1 Order management

Record the order header and order line. Order currency is EUR. Source at the order line is set to External and receiving inventory Org is S1 belonging to operating unit VC.

2 Run ‘Import Requisition’ VC Purchasing This program creates requisition for the sales order. Source needs to be set as ‘Order Entry’. Make sure that item has a list price setup.

3 Run ‘Auto Create PO’ VC Purchasing Convert the requisition to the PO. Check the supplier


15

Step Process Responsible Description on the PO and order currency is JPY. Check that Ship-To for order line should be the German customer. Approve PO. Send the PO to the customer.

4 Receive the PO S1 Inventory After Japanese supplier ships the goods to German customer, make a receipt against the PO. This receipt will be of type logical PO receipt. This PO receipt will trigger logical transactions in other operating unit. This transaction will create logical sales order issue in V1 and intercompany sales issue in VC and VJ. Similarly, it will also create logical intercompany receipt in VJ and V1. If the parameter ‘Defer logical transactions’ in S1 organization is marked as Yes, then logical transactions are deferred. Once the logical transactions are deferred then you can run the concurrent program ‘Create Deferred Logical Transactions’ in any of the inventory organizations associated in Intercompany Transaction Flow (i.e., S1, T1 and M1) to create the logical transactions. You can view the logical transactions by checking the flag ‘View Logical Transactions’ in the Material Transactions form.

5 Cost the transactions S1 Costing T1 Costing M1 Costing

All the logical transactions need to be costed.

6 Create Intercompany AR invoices

S1 Inventory Run the concurrent program ‘Create Intercompany AR invoices’. This program populates AR interface tables. This program can be run mutually exclusive in both operating units i.e., you can still run T1 intercompany AR program before S1 intercompany AR.

T1 Inventory

The currency of the intercompany AR invoice is based on the parameter ‘Currency Code’ for each intercompany relation line. Therefore, the intercompany relation line between VC and VJ should be ‘Currency Code of From Operating unit’ and that between VJ and V1 should be ‘Currency Code of To Operating unit’. This setup ensures that the AR invoice generated between VC and VJ is in CNY and between VJ and V1 is USD. The exchange rate used for the conversion of the transfer price into intercompany AR currency is based on the invoice date. AR intercompany invoice cannot be created for the following reasons: 1. Logical transactions are not created. 2. Transactions are not costed. 3. Transfer price cannot be determined. Check that

the transfer price is correctly setup. 4. Exchange rate could not be determined. This step successfully populates AR interfaces tables. Check for freight and tax codes.

7 Run ‘Auto Invoice Master VJ Receivables This program will create AR invoice from the data


16

Step Process Responsible Description Program’ V1 Receivables populated in AR interface tables. Once this program is

run successfully, you will see the intercompany AR invoice in Oracle Receivables. AutoInvoice will use AR grouping rules to group various AR invoices and orders the invoice lines using line-ordering rules.

8 Create AP intercompany invoices

T1 Inventory M1 Inventory

Run the concurrent program ‘Create Intercompany AP invoices’. This program populates AP interface tables. Only those records that were successfully processed in step 7 can be imported. This program can be run mutually exclusive in both operating units i.e., you can still run V1 intercompany AP invoice program before VJ intercompany AP invoice program.

9 Run ‘Expense Report Import’

VJ Payables V1 Payables

This program generates intercompany AP invoice from the data populated in the AP interface tables and you will see the intercompany AP invoice in Oracle Payables. Check that the transfer price in AP invoice is same that of AR invoice. If you do not see the tax correctly, then it means that the tax structure in From operating unit is not same as To operating unit. Therefore, check that tax codes and rates are the same in both operating unit.


17

Accounting Transactions

1. Accounting entries are as follows:

Particulars Debit Credit Particulars Debit Credit Particulars Debit CreditT1

T2 Run 'Cost Manager' Does accounting for the receipt transaction VC Clearing 100Accural 100

T2 Deliver in S1 Inv Org Receiving Transaction Processor runs and creates 'Deliver' Transaction

If the flag 'Defer Logical Transactions' in S1 is Yes, MMT creates following logical transactions:

Logical Intercompany issue in S1Logical Intercompany receipt in T1Logical Intercompany issue in T1Logical Intercompany receipt in M1Logical Sales Order issue in M1

T3 Run 'Cost Manager' VC Inventory 100VC Accural 100

I/C COGS 100VC Inventory 100

VJ Inventory 1500I/C Accural 1500

I/C COGS 1500VJ Inventory 1500

V1 Inventory 20I/C Accural 20

V1 COGS 20V1 Inventory 20

T4 Run 'Auto Invoice Master Program' in I/C Receivable 150I/C Revenue 150

T5 Run 'Expense Report' in T1 I/C Accural 1500I/C Payable 1500

T6 I/C Receivable 2000I/C Revenue 2000

T7 I/C Accural 20I/C Payable 20

T8 M1 Receivable 25M1 Revenue 25

Vision China (CNY) Vision Japan (JPY) Vision Operations (USD)Accounting Transactions

Material Transaction Processor runs and creates 'Logical PO receipt'

Does accounting for logical PO receipt created in S1

Does accounting for logical sales order issue created in M1

Time Transaction Description

Receiving Transaction Processor runs and creates 'Receive' Transaction

Receipt in S1 Inv Org

Does accounting for logical intercompany receipt created in T1

Does accounting for logical intercompany receipt created in M1

Run 'Auto Invoice Master Program' in M1 for raising a customer invoice

Does accounting for logical intercompany issue created in S1

Does accounting for logical intercompany issue created in T1

Run 'Auto Invoice Master Program' in T1Run 'Expense Report' in M1

2. Exchange Rate is as follows:

From To Exchange RateUSD JPY 100.00CNY JPY 10.00CNY THB 4.00

Overview of ntercompany Invoicing 18

USD EUR 0.80

Global Procurement (Central Procurement) Most of the multi-national companies consolidate procurement functions for all global business units into one or multiple Shared Service Centers. Corporations draw the following benefits from shared procurement office:

• Leverage buying volume by consolidating demand across organizations

• Standardize terms and conditions across all enabled organizations

• Centralize supplier relationship management

• Transact across international borders through foreign subsidiaries/shared service centers

• Automated and flexible funds settlement between the buying org and using org (PO Price/Transfer Price)

Primarily, these centralized Shared Service Centers generally have two responsibilities:

• negotiate contracts with suppliers

• execute purchasing transactions on behalf of all other business units in the enterprise

We will discuss the Global Procurement of asset items with inventory destination and accrue on receipt in detail.

Flow 3 – Global Procurement of asset items with inventory destination and accrue on receipt

Central Procurement shared services is depicted in Figure 14. Vision Singapore (VS) acts as a shared procurement office for all the operating units across the world for commodities. It aggregates its global requirement and leverages this buying volume for better contracts with the supplier. It centrally plans for the material and places a Purchase Order on the supplier with deliveries to be made in each manufacturing plant across the globe. A manufacturing plant will receive the material for the Purchase Order placed by VS.

Figure 14 - Central Procurement


Central Procurement business flow depicted in Figure 14 - Central Procurement is summarized in the following table:

Step Description A VC raises a purchase requisition resulting in a PO in VS B VS communicates the PO to the supplier with S1 as Ship To. Purchase Price is 700 JPY. C Supplier supplies goods to the manufacturing plant (S1) of VC. D Supplier sends the invoice VS. E VS issues an intercompany receivable invoice to VJ at PO price. The currency of the invoice is SGD.

Price in the intercompany invoice is 10 SGD. The price in the intercompany invoice is same as the Price in the Purchase Order.

F VJ issues an intercompany payable to VS. G VJ issues an intercompany receivable invoice to VC at PO price. The currency of the invoice is CNY.

Price in the intercompany invoice is 50 CNY. The price in the intercompany invoice is same as the Price in the Purchase Order.

H VC issues an intercompany payable to VJ.

System Transactions


1 Purchase Requisition VC Purchasing VC raises a purchase requisition, requesting VS to raise a PO.

2 AutoCreate PO VS Purchasing VC runs AutoCreate PO process, which results in a PO in VS. Note that it is not the shared service, which runs the AutoCreate Concurrent program, but the requesting organizations that run the AutoCreate PO. If the shared service Purchase Organization has already raised a Blanket Purchase Agreement, then running a AutoCreate in the requesting organization will create a release for the Blanket Purchase Agreement in Purchasing Org. For using Blanket Purchase Agreement, you need to do the following: 1. Mark the blanket purchase agreement as ‘Global’. 2. In Enable Organizations, list all the requesting

organizations. In this case list, Vision China is the requesting Org and Vision Singapore is the Purchasing Org.

3 Approve PO VS Purchasing VS checks the supplier, Ship To, PO price and approves the PO. Ship To should be S1.

4 Receive the material S1 Inventory Receive the material in S1against the Purchase Order. This will create physical PO receipt followed by logical intercompany issue transactions in S2 and T1, logical intercompany receipt in T1and S1 and logical PO receipt in S2. Therefore in S1 you will see both logical as well as physical PO receipt transactions. If the parameter ‘Defer logical transactions’ in S2 organization is marked as Yes, then logical transactions are deferred. Once the logical transactions are deferred then you can run the concurrent program ‘Create Deferred Logical Transactions’ in any of the inventory


Step Process Responsible Description organizations associated in Intercompany Transaction Flow (i.e., S1, T1 and S2) to create the logical transactions. You can view the logical transactions by checking the flag ‘View Logical Transactions’ in the Material Transactions form.

5 Cost the transactions VC Costing VJ Costing VS Costing


6 Run ‘Create Intercompany AR invoices’

VS Inventory Run ‘Create Intercompany AR invoices’. This program populates AR interface tables. The currency of the intercompany AR invoice is based on the parameter ‘Currency Code’ for each intercompany relation line.

VJ Inventory

The exchange rate used for the conversion of the transfer price into intercompany AR currency is based on date the invoice date. AR intercompany invoice cannot be created for the following reasons: 1. Logical transactions are not created. 2. Transactions are not costed. 3. Transfer price cannot be determined. Check that

the transfer price is correctly setup. 4. Exchange rate could not be determined. This successfully populates AR interfaces tables. Check for freight and tax codes.

7 Run ‘Auto Invoice Master Program’

VS Receivables Once this program is run successfully, you will see the intercompany AR invoice in Oracle Receivables. AutoInvoice will use AR grouping rules to group various AR invoices and orders the invoice lines using line-ordering rules.

VJ Receivables

8 Run ‘Create Intercompany AP invoices’

VJ Inventory VC Inventory

This program populates AP interface tables. Only those records that were successfully processed in step 6 can be imported.


VJ Payables VC Payables

This program generates intercompany AP invoice and you will see the intercompany AP invoice in Oracle Payables. Check that the transfer price in AP invoice is same that of AR invoice. If you do not see the tax correctly, then it means that the tax structure in From operating unit is not same as To operating unit. Therefore, check that tax codes and rates are the same in both operating unit. The tax codes should be spelled the same with matching upper case and lower case.



Accounting entries are as follows:

Exchange Rate is as follows:

From To Exchange Rate

SGD JPY 70.00SGD CNY 5.00


Internal Drop shipment (Central Distribution) Most multi-national companies have highly focused companies in their network of company, with each company specializing in their area of operations. Often you will find that sales organization is different from the distribution organization. In these cases, goods are only financially transferred from manufacturing company to the sales company without goods physically passing through sales organization. This kind of business model allows each organization to concentrate on their core operations and a separate P&L statement can be made for the organization. Central distribution organization concentrates on the increasing efficiencies in the logistics by optimizing the route, negotiating with carriers, planning the deliveries, minimizing stock outs etc.,

We will discuss Internal Drop Shipment of asset items in detail:

Flow 12 – Internal Drop Shipment of asset Item

For example, Vision China (VC) is the central distribution company for the entire Vision group of companies. Vision Operations (V1) books the sales order and VC ships the goods to customer. VC invoices Vision Japan (VJ) at transfer price and VJ in turn invoices V1 at transfer price. V1 raises a sales invoice and sends it to the customer.

Figure 15 - Central Distribution Central Distribution business flow depicted in Figure 15 - Central Distribution is summarized in the following table:

Step Description A V1 receives customer order and books it. Sales price is 25 EUR. B V1 pick releases the sales order to S1 in operating unit VC. C S1 ships the goods to the customer. D V1 invoices the customer. Currency of the invoice is EUR. E VC issues an intercompany receivable invoice to VJ at transfer price of 150 CNY. F VJ issues an intercompany payable invoice to VC at transfer price. G VJ issues an intercompany receivable invoice to V1 at transfer price of 20 USD. H V1 issues an intercompany payable invoice to VJ at transfer price.


System Transactions


1 Enter, book the customer order

V1 Order management

Record the order header and order line. Order currency is EUR. Source at the order line is set to Internal and shipping Org as Suzhou manufacturing plant (S1) in China.

2 Run ‘Pick Release Sales Order’

V1 Order management

This program creates a move order in S1 for shipping the goods.

3 Ship Confirm the delivery S1 Shipping Allocate the material for this move order and transact the move order. This transaction will create logical intercompany receipt and issues in T1, logical issues in S1 and M1. If the logical transactions are deferred then, the inventory manager in each operating unit needs to run ‘Create Deferred Logical Transactions’. You can view the logical transactions by checking the flag ‘View Logical Transactions’ in the Material Transactions form.

4 Cost the transactions VC Costing VJ Costing V1 Costing


5 Create Intercompany AR invoices

VC Inventory Run ‘Create Intercompany AR invoices’. This program can be run mutually exclusive in both operating units i.e., you can still run VC intercompany AR program before VJ intercompany AR.

VJ Inventory

The currency of the intercompany AR invoice is based on the parameter ‘Currency Code’ for each intercompany relation line. Therefore, the intercompany relation line between VC and VJ should be ‘Currency Code of From Operating unit’ and that between VJ and V1 should be ‘Currency Code of To Operating unit’. This setup ensures that the AR invoice generated between VC and VJ is in CNY and between VJ and V1 is USD. The exchange rate used for the conversion of the transfer price into intercompany AR currency is based on date the invoice date. AR intercompany invoice cannot be created for the following reasons: 1. Logical transactions are not created. 2. Transactions are not costed. 3. Transfer price cannot be determined. Check that

the transfer price is correctly setup. 4. Exchange rate could not be determined. This successfully populates AR interfaces tables. Check for freight and tax codes.


VC Receivables VJ Receivables

Once this program is run successfully, you will see the intercompany AR invoice in Oracle Receivables. AutoInvoice will use AR grouping rules to group various AR invoices and orders the invoice lines using line-ordering rules.

7 Create AP intercompany VJ Inventory This program populates AP interface tables. Only those


Step Process Responsible Description invoices V1 Inventory records that were successfully processed in step 6 can be

imported. This program can be run mutually exclusive in both operating units i.e., you can still run V1 intercompany AP invoice program before VJ intercompany AP invoice program.


VJ Payables This program generates intercompany AP invoice and you will see the intercompany AP invoice in Oracle Payables.

V1 Payables

Check that the transfer price in AP invoice is same that of AR invoice. If you do not see the tax correctly, then it means that the tax structure in From operating unit is not same as To operating unit. Therefore, check that tax codes and rates are the same in both operating unit. The tax codes should be spelled the same with matching upper case and lower case.




Accounting entries are as follows:

Exchange Rate is as follows:

From To Exchange Rate USD JPY 100.00 CNY JPY 10.00 USD EUR 0.80

Internal Fulfillment A common business practice in multi-national companies is internal fulfillment. You will find two common scenarios that need internal fulfillment from another operating unit:

• Manufacturing operations are spread out geographically. For example, in automobile industries critical assemblies like engine and gear assemblies are produced in a central manufacturing location globally, but final assembly is done in each country.

• Central manufacturing facility but multiple distribution centers.

The demand is mostly generated by a min-max planning at the source organization. For example, in Figure 16 - Internal Orders, Vision Operations has a distribution center at Seattle. Seattle warehouse follows Min-Max planning for replenishment and places an internal sales order to replenish the goods from Suzhou manufacturing plant in China.

Figure 16 - Internal Orders As said earlier, advanced accounting option is not available for internal sales orders. Therefore, you cannot use an intermediate financial node for this flow.

Internal fulfillment business flow depicted in Figure 16 - Internal Orders is summarized in the following table:

Step Description A Vision Operations (V1) runs a Min-Max planning report for Seattle Manufacturing (M1). It creates an

internal requisition. This internal requisition is transferred as internal sales order for Vision China (VC). B VC pick releases the internal sales order to Suzhou manufacturing plant (S1) C S1 ships the material to M1. M1 receives the material. D VC issues an intercompany receivable invoice to V1 at transfer price. Currency of the invoice is USD. E V1 issues an intercompany payable to VC.

System Transactions


1 Run Mi-Max Planning Report

M1 Inventory Min-Max planning will generate an internal requisition depending on the Min-Max setting and on-hand quantity.

2 Run ‘Import Requisition’ request

V1 Purchasing Import the internal requisition.


Step Process Responsible Description 3 Approve Internal

Requisition V1 Purchasing Approve Internal Requisition.

4 Run ‘Create Internal Order’ V1 Purchasing This will populate OE interface tables. 5 Run ‘Order Import’ request VC Order Entry An internal sales order is created. Book the order.

Check that the source is internal with shipping org as S1. Check that the intercompany price list is setup properly so that the price on sales order is correct.

6 Pick Release the Sales Order

S1 Shipping The internal sales order is pick released. Pick release creates a move order and then allocate the material.

7 Confirm shipment of the goods

S1 Shipping Check that the shipping network between S1 AND M1 is of type ‘In-Transit’. No intercompany invoice will be created if the shipping network is of type ‘Direct Transfer’.

8 Receive the goods M1 Inventory Receive the goods. 9 Cost the transactions S1 Costing Check that the cost manager is running and has costed

the internal sales order issue. 10 Create Intercompany AR

invoices S1 Inventory Run ‘Create Intercompany AR invoices’.

The currency of the intercompany AR invoice is based on the parameter ‘Currency Code’ for in intercompany relation line. The exchange rate used for the conversion of the transfer price into intercompany AR currency is based on date the invoice date. AR intercompany invoice cannot be created for the following reasons: 1. Transactions are not costed. 2. Transfer price cannot be determined. Check that

the transfer price is correctly setup. 3. Exchange rate could not be determined. 4. You have defined multiple intermediate nodes. This successfully populates AR interfaces tables. Check for freight and tax codes.


S1 Receivables Once this program is run successfully, you will see the intercompany AR invoice in Oracle Receivables.

12 Create AP intercompany invoices

M1 Inventory This program populates AP interface tables.


M1 Payables This program generates intercompany AP invoice and you will see the intercompany AP invoice in Oracle Payables. Check that the transfer price in AP invoice is same that of AR invoice. If you do not see the tax correctly, then it means that the tax structure in From operating unit is not same as To operating unit. Therefore, check that tax codes and rates are the same in both operating unit. The tax codes should be spelled the same with matching upper case and lower case.

SCENARIOS NOT SUPPORTED IN INTERCOMPANY TRANSACTIONS Before setting up intercompany transaction flow, you need to run through the following scenarios, which are not supported by the system. Being aware of these scenarios will help in modeling the intercompany


transactions better. This may require re-engineering some of the business practice like using purchase price for intercompany invoicing over using transfer pricing or determining your customization needs. Intercompany transactions does not support following scenarios:

Scenario 1 – Internal drop shipment from an internal organization to another internal organization Though you can setup intercompany transaction flow with intermediate nodes for internal drop shipment from one internal organization to another internal organization, system will not create any logical transactions. You will be able to generate intercompany invoices only when it involves two operating units without any intermediate operating units.

Figure 17 - Internal Sales Orders Flow Not Supported

Scenario 2 – Drop Shipment and intercompany transactions for Non-Shippable, Non-Stockable and Non-Transactable items You cannot create intercompany invoices if the business flow between operating units involves non-shippable, non-stockable or non-transactable items. System ignores the intercompany transaction flow and errors out. Therefore, it is necessary to ensure that the items involved in the business flow do not have these attributes.

Scenario 3 – Drop Shipment and Intercompany transactions for Non-invoiced items In some cases of central distribution, promotional items are shipped to the customer from the central warehouse and customers are not invoiced for such shipments. However, the central distribution warehouse invoices the selling operating unit for the shipment. Selling operating unit pays the shipping operating unit for the shipment but does not invoice the customer.


To prevent the selling operating unit from raising AR invoice for the customer, the promotional item is made as non-invoicable item so that sales order can be closed. However, you cannot raise an intercompany invoice if the item is non-invoicable. System currently does not support the business flow for the items that are non-invoicable.

Scenario 4 – Global Procurement for projects with expense destination and transfer pricing In Global procurement scenario if the procurement is for a specific project and task and the destination type is expense, then you cannot use transfer price for intercompany invoicing. In this scenario, you have only one option – use purchase price on the PO as the price on the intercompany invoicing.

Scenario 5 – Global Procurement with shop floor destinations and transfer pricing If the procurement is made with shop floor as destination, then you cannot use transfer pricing for intercompany invoicing. In this scenario, you have only one option – use purchase price on the PO as the price on the intercompany invoicing.

Scenario 6 – Consigned inventory for Global Procurement flows In some Global procurement scenarios, central procurement office places a PO with a delivery in a warehouse in another operating unit. However, in the receiving operating unit’s warehouse the inventory is consigned and the supplier is paid only when the consigned inventory is transferred to the regular inventory. For each consumption by the receiving organization, the procuring organization raises an intercompany invoice.

However, system does not support intercompany invoicing for the above scenario.

Scenario 7 – Handling encumbrances in Drop Ship and Global Procurement flows Buyers generally encumber funds on a blanket PO or blanket agreements to reflect the commitments to a certain level of spending. However, you cannot encumber funds for a Purchase Order if the receiving warehousing belongs to another operating unit or is part of an external drop shipment scenario.

Scenario 8 – Retroactive pricing in Global Procurement Retroactive pricing is supported in purchasing organization but the changes would not be communicated to the receiving organization. Inventory in the receiving organization will not be revalued based on the latest retroactive price.

Scenario 9 – P-Cards in Global Procurement You cannot make use of P-Cards in Global Procurement scenarios.

Scenario 10 – Advanced Sales functionality between operating units Usually, the operating units involved engage in a customer-supplier relationship. The service providing operating unit need to market its service to other operating units and compete with other operating units for providing the service. Advanced sales functionality like credit checks, sales credit are not available for either shared services operating units or for the intermediate operating units.


Scenario 11 – Advanced cross border trade management Multi-national companies often practice intercompany invoicing and the intercompany invoicing is guided by specific regulations of each country. Sometimes, these intercompany invoices attract various duties (like customs duty, counter-veiling duty, surcharges etc.,) depending upon the parties involved in the invoicing. The advanced cross border trade management softwares fulfill these taxation requirements and currently system offers only rudimentary support for the complex taxation involved in intercompany invoicing.

Scenario 12 – Inter Org Transfers You cannot raise an intercompany invoice in the following cases:

• Internal transfers through internal requisition – internal sales order flow with Direct Transfer.

• Inter Org transfers in inventory between inventory orgs belonging to different operating units (not using internal requisition – internal sales order flow). This is true irrespective of the transfer type in the shipping network.

Scenario 13 – Internal Orders with expense destination You can raise an internal requisition with expense destination and subsequently create a sales order and ship the item. However, you cannot raise an intercompany invoice for this transaction.

CONCLUSION This paper describes implementation of intercompany invoicing in multi-national organizations. It describes various scenarios that can be configured in Oracle applications. Since the process as a whole involves many departments in different operating units, the underlying transactions performed using Oracle applications need to be carefully planned and managed. The large amount of data that needs to be set up must be carefully managed as well.

This paper should give sufficient information that you need to begin setting up the intercompany transactions involving two or more operating units.

ADDITIONAL RESOURCES • Intercompany Invoicing: How to Set Up and Use this Feature within Oracle Applications, Oracle White

Paper, May 2000.

• Intercompany Invoicing and Advanced Pricing Integration, Oracle White Paper, May 2002.

• Intercompany Transactions, Oracle White Paper, July 2005.

• Oracle Inventory Users Guide, 11.5.10.

• Oracle Order Management Users Guide, 11.5.10.

• Oracle Accounts Receivable Users Guide, 11.5.10.

• Oracle Accounts Payable Users Guide, 11.5.10.

• Oracle Purchasing Users Guide, 11.5.10.


Overview of Intercompany Invoicing July 2005 Author: Sharma Manda Contributing Authors: Karthik Gnanamurthy and Krish Ratnam Koothan Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. Worldwide Inquiries: Phone: +1.650.506.7000 Fax: +1.650.506.7200 www.oracle.com Oracle Corporation provides the software that powers the Internet. Oracle is a registered trademark of Oracle Corporation. Various product and service names referenced herein may be trademarks of Oracle Corporation. All other product and service names mentioned may be trademarks of their respective owners. Copyright © 2005 Oracle Corporation All rights reserved.

overview of intercompany invoicing

Documents

global procurement flows

intercompany transactions

internal organization

external drop shipment

internal orders

internal fulfillment

transfer pricing

intercompany transaction