Overview of Intercompany Invoicing

Overview of Intercompany
Invoicing
An Oracle White Paper
July 2005
Overview of Intercompany Invoicing
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 NonTransactable 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
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:
- the financial reporting entity for which there is a chart of accounts, currency, and financial
calendar for securing ledger transactions.
Set of Books
Legal Entity
- the organization at whose level fiscal and tax reporting is prepared.
- 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.
Operating Unit
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 corporations
organizational setup and map it to Oracles Multi-Orgs 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 sellingshipping 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.
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.
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
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.
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
3.
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).
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.
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 Arms length Price and is generally guided by the originating countrys
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
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
Drop Shipment Sales Order and Advanced
Accounting set to No.
Drop Shipment Sales Order and Advanced

Accounting set to Yes.
Global Procurement and Advanced

Accounting set to Yes.
Global Procurement and Advanced
Accounting set to No.
Internal Orders with Advanced Accounting
set to Yes.
Internal Orders with Advanced Accounting
set to No.
Logic
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.
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.
System rolls up the price of model and price of options and
creates one invoice line for configuration item.
Not Supported.
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).
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.
2.
3.
4.
Ship-To-Site
Bill-To-Site
Customer
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
Shipping
Shipping
Shipping
Shipping
Use Advanced
Pricing Profile
N
Y
Y
Y
Currency code in Intercompany

Transaction Relationship
Does not matter
Shipping Operating Unit
Selling Operating Unit
Order Currency Code
Currency Code in AR Invoice

Currency Code mentioned in the price list
Shipping Operating Unit Currency Code
Selling Operating Unit 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
Procuring
Pricing Option
PO Price
Use Advanced
Pricing Profile
N
Currency code in Intercompany

Transaction Relationship
Does not matter
Procuring
Transfer Price
Does not matter
Procuring
Transfer Price
Procuring / Shipping Operating Unit
Procuring
Transfer Price
Receiving / Selling Operating Unit
Procuring
Transfer Price
Order Currency Code
Procuring
PO price
Does not matter
Currency Code in AR
Invoice
Purchase Order
Currency
Currency Code
mentioned in the price
list
Procuring Operating
Unit Currency Code
Receiving Operating
Unit Currency Code
Purchase Order
Currency
Purchase Order
Currency
Summary Of Profiles
This section summarizes all the profiles used in the intercompany invoicing flows:
Profile
INV: Advanced Pricing for
Intercompany Invoice
INV: Intercompany Currency

Conversion
Values
Yes, No
Description
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.
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
INV: Intercompany Invoice for

Internal Orders
INV: Use Model & Options for
Configuration Pricing
Yes, No
CST: Transfer Pricing Option
Yes, Price Not As Incoming Cost

Yes, Price As Incoming Cost
No
Yes, No
QP: Security Control
On, Off
Tax: Allow Override of Tax

Code
Yes, No
Tax: Inventory Item for Freight
flow.
If set to yes, then you can raise an
intercompany invoice for internal orders.
See the section on Transfer price for
ATO/PTO items. System looks for this
transaction flow.
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 orgs
inventory cost. the values are derived from:
value in cogs = sending orgs

inventory cost
value in inter-company expense =

transfer price
value in profit in inventory = transfer

price - sending orgs 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 Orgs

inventory cost
Value in Inter-company Expense =

Transfer Price
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.
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
transaction flow.
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
Tax: Invoice Freight as

Revenue
Yes, No

transaction flow.
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
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 outsource 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
A
B
C
D
E
F
G
H
I
J
Description
Customer places an order on V1.
Sales order is scheduled to be shipped from a supplier of VC.
VC raises a PO on supplier. Purchase price is 400 THB.
Supplier ships the goods directly to the customer.
V1 invoices the customer. Selling price is 20 EUR.
Supplier sends an invoice to VC.
VC issues an intercompany receivable invoice to VJ at transfer price of 150 CNY.
VJ issues an intercompany payable to VC.
VJ issues an intercompany receivable invoice to V1 at transfer price of 20 USD.
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
V1 Order
Record the order header and order line. Order currency
order
management
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
Receive the PO
Responsible
S1 Inventory
Description
on the PO and order currency is JPY. Check that ShipTo for order line should be the German customer.
Approve PO.
Send the PO to the customer.
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.
Cost the transactions
Create Intercompany AR
invoices
S1 Costing
T1 Costing
M1 Costing
S1 Inventory
T1 Inventory
Run Auto Invoice Master
VJ Receivables
You can view the logical transactions by checking the

flag View Logical Transactions in the Material
Transactions form.
All the logical transactions need to be costed.
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.
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.
This program will create AR invoice from the data
16
Step
Process
Program
Responsible
V1 Receivables
Create AP intercompany
invoices
T1 Inventory
M1 Inventory
Run Expense Report

Import
VJ Payables
V1 Payables
Description
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.
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.
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:

Time
Transaction
T1 Receipt in S1 Inv Org

T2 Run 'Cost Manager'
T2 Deliver in S1 Inv Org
Description
Vision China (CNY)

Particulars
Debit Credit
Receiving Transaction Processor runs and creates

'Receive' Transaction
Does accounting for the receipt transaction
VC Clearing
Accural
Receiving Transaction Processor runs and creates
'Deliver' Transaction
Material Transaction Processor runs and creates
'Logical PO receipt'
If the flag 'Defer Logical Transactions' in S1 is Yes,
MMT creates following logical transactions:
Logical Intercompany issue in S1

Logical Intercompany receipt in T1
Logical Intercompany issue in T1
Logical Intercompany receipt in M1
Logical Sales Order issue in M1
Does accounting for logical PO receipt created in VC Inventory
T3 Run 'Cost Manager'
VC Accural
S1
Does accounting for logical intercompany issue
I/C COGS
VC Inventory
created in S1
Does accounting for logical intercompany receipt
created in T1
Does accounting for logical intercompany issue
created in T1
Does accounting for logical intercompany receipt
created in M1
Does accounting for logical sales order issue
created in M1
T4 Run 'Auto Invoice Master Program' in
I/C Receivable
I/C Revenue
T5 Run 'Expense Report' in T1
T1
T7 Run 'Expense Report' in M1
M1 for raising a customer invoice
2.
Vision Japan (JPY)
Particulars
Debit Credit
Vision Operations (USD)

Particulars
Debit Credit
100
100
100
100
100
100
VJ Inventory
I/C Accural
I/C COGS
VJ Inventory
150
150
I/C Accural
I/C Payable
I/C Receivable
I/C Revenue
1500
1500
1500
1500
V1 Inventory
I/C Accural
V1 COGS
V1 Inventory
20
I/C Accural
I/C Payable
M1 Receivable
M1 Revenue
20
20
20
20
1500
1500
2000
2000
20
25
25
Exchange Rate is as follows:

From
USD
CNY
CNY
USD
To
JPY
JPY
THB
EUR
Exchange Rate
100.00
10.00
4.00
0.80
Overview of ntercompany Invoicing
18
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
Overview of ntercompany Invoicing 19
Central Procurement business flow depicted in Figure 14 - Central Procurement is summarized in the following
table:
Step
A
B
C
D
E
F
G
H
Description
VC raises a purchase requisition resulting in a PO in VS
VS communicates the PO to the supplier with S1 as Ship To. Purchase Price is 700 JPY.
Supplier supplies goods to the manufacturing plant (S1) of VC.
Supplier sends the invoice VS.
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.
VJ issues an intercompany payable to VS.
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.
VC issues an intercompany payable to VJ.
System Transactions

Step Process
Responsible
Description
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.
Approve PO
VS Purchasing
Receive the material
S1 Inventory
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.
VS checks the supplier, Ship To, PO price and approves
the PO. Ship To should be S1.
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
Run Create Intercompany

AR invoices
VC Costing
VJ Costing
VS Costing
VS Inventory
VJ Inventory

Program
VS Receivables
VJ Receivables
Run Create Intercompany

AP invoices
VJ Inventory
VC Inventory
Run Expense Report

Import
VJ Payables
VC Payables
Description
organizations associated in Intercompany Transaction
Flow (i.e., S1, T1 and S2) to create the logical
transactions.
Transactions form.
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.
on date the invoice date.
following reasons:
This successfully populates AR interfaces tables. Check
for freight and tax codes.
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.
This program populates AP interface tables. Only those
records that were successfully processed in step 6 can be
imported.
This program generates intercompany AP invoice and
you will see the intercompany AP invoice in Oracle
Payables.
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.

From
To
SGD
SGD
JPY
CNY
Exchange Rate
70.00
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
A
B
C
D
E
F
G
H
Description
V1 receives customer order and books it. Sales price is 25 EUR.
V1 pick releases the sales order to S1 in operating unit VC.
S1 ships the goods to the customer.
V1 invoices the customer. Currency of the invoice is EUR.
VC issues an intercompany receivable invoice to VJ at transfer price of 150 CNY.
VJ issues an intercompany payable invoice to VC at transfer price.
VJ issues an intercompany receivable invoice to V1 at transfer price of 20 USD.
V1 issues an intercompany payable invoice to VJ at transfer price.
System Transactions

Step Process
Responsible
Description
1
Enter, book the customer
V1 Order
Record the order header and order line. Order currency
order
management
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
V1 Order
This program creates a move order in S1 for shipping
Order
management
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.
Transactions form.
4
invoices
VC Costing
VJ Costing
V1 Costing
VC Inventory
VJ Inventory

Program
VC Receivables
VJ Receivables
VJ 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.
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.
following reasons:
AutoInvoice will use AR grouping rules to group
various AR invoices and orders the invoice lines using
line-ordering rules.
This program populates AP interface tables. Only those
Step
Process
invoices
Responsible
V1 Inventory
Run Expense Report

Import
VJ Payables
V1 Payables
Description
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.
Payables.

From To
USD JPY
CNY JPY
USD EUR
Exchange Rate
100.00
10.00
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
A
B
C
D
E
Description
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).
VC pick releases the internal sales order to Suzhou manufacturing plant (S1)
S1 ships the material to M1. M1 receives the material.
VC issues an intercompany receivable invoice to V1 at transfer price. Currency of the invoice is USD.
V1 issues an intercompany payable to VC.
System Transactions

Step Process
Responsible
Description
1
Run Mi-Max Planning
M1 Inventory
Min-Max planning will generate an internal requisition
Report
depending on the Min-Max setting and on-hand
quantity.
2
Run Import Requisition
V1 Purchasing
Import the internal requisition.
request
Step
3
Process
Approve Internal
Requisition
Run Create Internal Order
Run Order Import request
Responsible
V1 Purchasing
Description
Approve Internal Requisition.
V1 Purchasing
VC Order Entry
Pick Release the Sales

Order
S1 Shipping
This will populate OE interface tables.

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.
The internal sales order is pick released. Pick release
creates a move order and then allocate the material.
Confirm shipment of the

goods
S1 Shipping
8
9
Receive the goods

M1 Inventory
S1 Costing
10
invoices
S1 Inventory
11

Program
invoices
Run Expense Report
Import
S1 Receivables
4
5
12
13
M1 Inventory
M1 Payables
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.
Receive the goods.
Check that the cost manager is running and has costed
the internal sales order issue.
Run Create Intercompany AR invoices.
on the parameter Currency Code for in intercompany
relation line.
following reasons:
4. You have defined multiple intermediate nodes.
This program populates AP interface tables.
Payables.
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 noninvoicable.
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 units 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.

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

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Overview of Intercompany Invoicing

Uploaded by

Copyright:

Available Formats

Overview of Intercompany