Internal Drop-Shipping: Multi-Org Inter-company invoicing in Rel. 11.5.

10

David S. McCurry
McCurry and Company, Inc.

Introduction
Many large and multi-national enterprises are composed of numerous organizations that belong to different
operating units and legal entities that conduct business in multiple sets of books. It is common that the
legal and reporting structures of these enterprises are complex and do not match the transactional structure
of the business. Multiple Organization functionality is designed to accommodate multiple organizations and
legal entities within a single installation of the Oracle Applications and serves to define these organizations
and their logical relationships to each other so that business transactions can occur efficiently between
them. Multi-Org functionality was first introduced with the release of version 10.6 of the Oracle
Applications and the advent of Order Management, Advanced Pricing, and Workflow in Rel. 11i has
broadened its extendibility. Now with the release of 11.5.10, yet further enhancements have been added
that allow the functionality to be tailored to meet the most complex of business requirements.

Inter-company invoicing functionality is a component of Multi-Org that facilitates the sourcing of

shipments from physical warehouses, reducing stocks, freight and inventory carrying costs at distribution
and service locations without legal structure complications and redundant procurement, inventory order
fulfillment processes. It can reduce order lead times by removing “corporate obstacles” to global inventory
planning, making the legal structure of the enterprise transparent to the end-customer. It also automatically
generates inter-company receivables and payable invoices based on the logical transaction flow of the
business by using established transfer pricing policies, mitigating the risk of unbalanced inter-company
transactions that delay closings and consolidations. Most importantly, it can accomplish this in a way that
preserves a clear, documented audit trail for inter-company transactions that complies with GAAP and
Sarbanes-Oxley.

Scope of this paper

The scope of this paper is to demonstrate how Multi-Org Inter-company Invoicing functionality can be
utilized to automate the inter-company accounting and streamline the entire order process where orders are
taken in one operating unit but physically shipped from another. The standard functionality will be
discussed in detail as well as how and where it can be modified to customize the functionality to fit specific
business requirements. The topics covered include an overview of the Inter-company Invoicing
functionality, and an outline of the process, business events, and accounting impact in each entities set of
books. Required configurations and setups are discussed in detail as well as how Transfer Pricing, the
CoGS Workflows, and the generation of Accounts Receivable and Account Payables invoices can be
customized to meet specific enterprise requirements. Global inventory planning is discussed and sample
SQL for creating reconciling inter-company transactions is provided. Enhancements to the functionality
included in Release 11.5.10 of the applications are also discussed. Finally, this paper attempts to address
constraints and limitations of this functionality and suggests ways to mitigate possible risks and
contingencies.

The target audience includes functional and technical resources that are involved in the implementation of
the Oracle Applications. A basic understanding of Oracle Workflow and Advanced Pricing is
recommended. This paper is primarily aimed toward the functional user but sample PL/SQL packages and
discussion of certain APIs are presented for reference. This paper is not intended to cover in detail the
functionality of these applications and the reader is encourage to reference the Workflow, Multi-Org, and
the Application User’s guides.

OAUG Connection Point® 2006 Copyright 2006 by McCurry & Company, Inc. Page 1 of 21
Business Requirement
Many large and multi-national enterprises are composed of numerous organizations that belong to different
operating units and legal entities that conduct business in multiple sets of books. The merger-mania of the
80’s-90’s created many business enterprises that appear to be one to the outside but still retained the legal
structure of many smaller companies on the inside. With the growth of the global economy in the last
decade, many companies have grown beyond national borders and operate with multi-national business
structures. Many un-related companies have attempted to leverage synergies by creating joint venture
corporations. Quite often, these JVs are managed by one of the JV partners using its production facilities
and personnel but require separate transactional reporting. Finally, many corporations are simply comprised
of complex legal entity structures intentionally for tax benefits and liability limitation. Despite whatever
complex and sometimes convoluted legal and reporting structure, the physical or literal structure of the
business has become very different from the legal structure. Many public-traded companies are broken
down into divisions based upon external reporting requirements that are based upon industry or market
segment divisions, even though the products manufactured and sold into different business segments are
produced in the same location. As a result, it is not uncommon for a single enterprise in a single installation
of the Oracle ERP applications to operate several companies, legal entities, production, and distribution
operations as independent organizations. Transactions are/must be handled as if they were 3rd party
transactions even though the products that are “manufactured and sold” by the different “child
corporations” are in fact produced and shipped from the same production facility using the same personnel
and transaction channels. The difficulty comes in where these transactions must captured and processed
based upon legal structure considerations.

With the advent of Sarbanes-Oxley, there is a greater need to maintain accuracy and transparency for inter-
company activities. Recent history has seen the abuse of these complex, convoluted, multi-national
structures to create fragmented business transactions that hide the true condition of the enterprise. The
resulting requirement of Sarbanes-Oxley is that a clear and auditable trail of these inter-company
transactions must exist while at the same time support the “legal spaghetti” that make these business
transactions appear legally to have occurred “arm’s length” between 3rd Party companies.

The literal and obviously in-efficient process would be for these “companies” to generate transactions
between them that suggest totally different organizations. Consider an example of an enterprise operates a
manufacturing business and a distribution business under a legal structure of separate companies but are
located that the same physical facility. Company X gets an order from a third party customer and in
response, generates a purchase order to Company Y, who acknowledges by creating a sales order to
Company X. When Company Y physically ships to the end customer, they must first “logically ship” the
product to Company X, who “receives” it into inventory on the books and then executes a shipping
transaction to represent the transfer of ownership to the true customer. This is done strictly to simulate an
arm’s length transaction with conveyance of title from Y to X to the customer when it literally did not
occur. But a paper trail of Purchase Order, Sales Order, Receiving Transaction, and Invoice are required.
But this paper trail is fraught with pot holes and detours like duplicate or lost transactions, mis-matched
accounting, unapproved and/or un-matched invoices, timing issues between AR and AP or between
company X and company Y, and many other types of dis-connects. This configuration becomes
increasingly problematic as a considerable number of inter-company transactions are carried out on a day-
to-day basis between the two “companies”. The distribution and service organization (company X) sources
a great many of their inventory items from the production organization (company Y). Because these
organizations reside at the same physical location and use the same shared-personnel to receive, stock, and
ship inventory, redundant transactions occur when the items are shipped from the production organization
directly to the customer of the service organization.

OAUG Connection Point® 2006 Copyright 2006 by McCurry & Company, Inc. Page 2 of 21
The Objective
The objective is to utilize functionality resident within the Oracle applications to eliminate these duplicate
transactions and streamline the shipping process. Inter-company Invoicing is standard Oracle functionality
that leverages the fact that these related parties exist in the same instance of the ERP applications. This
functionality significantly streamlines the business process by eliminating the generation of redundant
purchase orders, inventory transactions, and sales orders between the related parties by automating the
inter-company transaction flow by creating an internal customer-supplier relationship between the two
companies that allows Company Y to internally drop-ship product for Company X.

“Internal” versus “External” Drop-Shipping: What’s the difference?

External Drop-Shipping functionality in Oracle Order Management uses purchase orders to outside
suppliers that are automatically generated from sales orders for goods supplied directly from the supplier.
The “external” supplier ships the goods directly to the 3rd Party customer and confirms the shipment
through the use of an Advanced Shipment Notice. Oracle uses this ASN to record a receiving transaction
into inventory followed by an immediate logical shipping transaction. From these transactions, conveyance
of title takes place and the customer can be invoiced and the supplier’s invoice can be processed. “Internal”
Drop-Shipping functions in a similar fashion. The key difference is that no inventory transactions take
place on the books of the selling operating unit; transfer of ownership of the goods from shipper to seller to
customer with the only physical movement of the goods being out of the shipping organization.

Overview of Inter-company Invoicing

Inter-company invoicing has been available in the Oracle applications since Multi-Org was first introduced
in Release 10.6. Multi-Organization functionality enables an enterprise to operate independent business
units within a single installation of the software and still maintain segregation of the data by business units.
These are called “Operating Units” in Multi-Org and are used to segregate Sales Orders, Purchase Orders,
Receivables, Payables transactions by business units while leveraging the use of global item, customer, and
supplier registries. As it is discussed here, the purpose of Inter-company Invoicing is to “fill-in” the
accounting gap that occurs when goods are internally drop-shipped against a sales order from a warehouse
that is part of a separate operating unit in a different set of books. When the shipping inventory
organization is not part of the same operating unit as the selling entity, a gap is created as each operating
unit is “missing” half of the transaction. Inter-company invoicing fills in that gap by generating accounting
transactions in the form of inter-company receivable and payables invoices. Consider the example of
Company X and Company Y presented above:

3rd Party Customer

Sales Order

Intercompany
Relationship Product Shipment
Company X Company Y
Set of Books Set of Books
AP Invoice

Operating Unit X Operating Unit Y

(Seller) (Shipper)

AR Invoice

Warehouse

OAUG Connection Point® 2006 Copyright 2006 by McCurry & Company, Inc. Page 3 of 21
Company X, operating as an Operating Unit, enters an order to a third party customer. The order is fulfilled
by a warehouse (inventory organization) belonging to company Y, operating as an Operating Unit. Both
company X and company Y are on separate sets of books. The Sales Order and the shipping of the product
represent the physical flow of transaction while the generation of the inter-company transactions represents
the logical transaction flow. The advantage of inter-company invoicing is quite clear when you consider
the what steps would be involved in manually creating the logical transaction flow as opposed to using the
inter-company invoicing functionality :

Without Inter-company Functionality Inter-company Functionality Process

Customer Service enters the Order for the end Customer Service enters the Order in the
customer in the Company X Operating Unit. Company X Operating Unit and selects
Company Y’s warehouse as the Ship From.
With no stock on hand, Order goes on back- Company Y Stockroom then picks the part
order sends a notification to the Planner and ships the product to the end customer.
Company X Planner creates a Purchase Order Automated process generates and posts
in the Company X Operating Unit and submits invoice between Company X and Y.
to Company Y Customer Service
Customer Service enters a sales order in the
Company Y Operating Unit with Company X
as the customer
Company Y Stockroom receives demand
notification and picks and ships the product to
Company X.
Company X Stockroom receives the product
into inventory against their purchase order
Company X Stockroom then picks and ships
the part to the end customer.
Company Y generates invoice and sends to
Company X Payables
Company Y enters the invoice and matches it
to the PO and receipt.

The benefits of using Internal Drop-Shipping are very obvious when the two approaches are compared.
Several redundant processes have been eliminated by not having to generate purchase orders, sales orders
and “bogus” inventory transactions. This reduces the overall order fulfillment time and gets the product to
the end customer faster. The planning and procurement activities have been centralized with company Y, as
they function as a single source of supply for the enterprise and product demand is flattened into a global
view for the whole enterprise. This also provides for the consolidating of inventory with one organization
and reduces overall inventory carrying costs. Because the creation of the Inter-company AR and AP
invoices is automatic, it eliminates the risk of timing differences between the two companies and makes the
financial consolidation process easier. This also eliminates the risk of transfer pricing errors as well as
transaction errors or lost transactions.

How Internal Drop-Shipping Works

The definition of the “internal” customer-supplier relationship in Oracle between the two operating units
enables the selection of Company Y’s warehouse locations on the Sales Orders in Company X. This places
demand on Company Y and allows them to execute shipping transactions directly against company X’s
sales order. The “transaction gap” that is created between the two companies, specifically the COGS entry
for company X and the revenue transaction for company Y is filled by running two inter-company
invoicing processes: the “Create Inter-company AR Invoice (INCIAR)” process and the “Create Inter-
company AP Invoice (INCIAP)” process. The INCIAR process creates an AR invoice on Company Y’s
books for the customer Company X and the INCIAP creates a “mirror” AP invoice on Company X’s books

OAUG Connection Point® 2006 Copyright 2006 by McCurry & Company, Inc. Page 4 of 21
for the supplier Company Y. Consider the example above based upon the chronology of events and the
accounting impact of process:

Set of
Event Debit Credit
Books
Company X books order to a 3rd X None
party with a warehouse
Y None
designation of Company Y
Trade Receivables
X
Company Y picks and ships the Revenue, Freight, and Tax
goods against Company X’s (based on 3rd Party Pricing)
sales order Cost of Goods Sold
Y (Based on Standard Cost)
Inventory
None
The Create Inter-company AR X
None
Invoice Process Runs. Auto-
Inter-company Receivables
invoice is run for Inter-
Y Revenue, Freight, and Tax
company Invoices
(Based on Transfer Pricing)
Cost of Goods Sold
The Create Inter-company AP X (Based on Transfer Pricing)
Invoice Process Runs. Expense Inter-company Payable
Import is run for Inter-company
None
AP Invoices Y
None

The INCIAR and INCIAP processes use the Inter-company Relationship as well as other customer/supplier
setups in Oracle to create AR and AP invoices on both sides that are consistent in date, amount, currency,
taxes, etc. Again, this functionality has been available in Oracle since the release of multi-org in 10.6 and
has been continually enhanced and expanded as newer versions of the applications have been released, but
it’s basic conceptual functionality remains the same. With the release of 11i, the introduction of Advanced
Pricing expanded the flexibility in deriving the transfer price. The replacement of Flex-builder with the
Workflow-based COGS Account Generator expanded the flexibility in deriving the COGS Account for the
shipping transaction. The release of 11.5.10 has brought yet more enhancements to the functionality.

Enhancements to the functionality included in Release 11.5.10

With the release of 11.5.10 of the applications, procurement flows have been added to the established
shipping flows. Procurement Flows provides for and inter-company invoicing for global procurement.
This addition allows for the generation of Purchase Orders in one operating unit with the receipt of goods
into the inventory organization belonging to another. Invoicing for inter-company procurement can be done
at either the PO price or the transfer price, and accounting is done to represent a transfer of ownership
between the operating units.

The Inter-company Relations form (INVSDICR) has been changed to support the global procurement
business flows. Several new fields have been added for global procurement to the form. In addition, this
form is now only accessible through the new Inter-company Transactions Flow definition form. The Inter-
company Transaction Flow (INVSICTF) form is a new form used for creating transactions flows to support
advanced inter-company invoicing for both selling and procuring transaction flows. IC Transaction Flows
defines the relationship relative to the movement of goods and the accounting impact between “chains” of
operating units. Chains of inter-company relationships can now be created to support the flow of logical
transactions through a chain of operating units through which ownership must pass when transacting
between selling and shipping operating units, or between procuring and receiving operating units. Inter-

OAUG Connection Point® 2006 Copyright 2006 by McCurry & Company, Inc. Page 5 of 21
company invoices are generated between all operating units, and. the accounting is done to represent and
ownership transfer between each operating unit in the chain.

3rd Party Customer

Sales Order

Product Shipment

Operating Unit X Operating Unit Y

Logical Flow
(Seller) (Shipper)

AP Invoice AP Invoice
Org 327

AR Invoice
AR Invoice

Operating Unit Z
(Intermediary)

This is example presented previously modified to show the functionality of “Advanced” inter-company
invoicing. The new Inter-company Transaction Flow form supports the additions of operating units
between the selling and shipping operating units. These are referred to as “intermediate” operating units
and create a chain between the two ends. In this example, Company Z, has been inserted between
companies X and Y. The physical flow remains the same as before; company X takes the order and
company Y ships the product. But now, company Y is shipping the product on behalf of company Z, who is
acting as the supplier for company X.

Setting up for Internal Drop Shipping

In order to use inter-company invoicing for selling and shipping across multiple operating units, several
GL, AR, AP, PO, OM, and INV setups are required. Many of these setups most likely have been completed
as part of your implementation but may have an impact of implementing inter-company invoicing. Setups
such as General Ledger account code combinations, inventory items, launching Cost and Transaction
managers are considered pre-requisite and will not be discussed here. To verify that everything has be setup
correctly and completely, you should run the Setup Validation Report. In addition to these fundamental
setups, there are approximately 17 separate set-up steps specifically for the Inter-company invoicing
functionality. These are as follows:

Step 1: Profile Options related to Inter-company Invoicing

There are several profile options that are used by Inter-company invoicing. Many are controlled strictly at
the site level and must be set for the entire enterprise:

OAUG Connection Point® 2006 Copyright 2006 by McCurry & Company, Inc. Page 6 of 21
INV: Inter-company Currency Conversion
This profile option determines conversion type for foreign currency invoices.

INV: Inter-company Invoice for Internal Orders

This YES/NO profile option can only be set at the Site level and controls whether or not the “Create Inter-
company AR Invoice” process generates invoices for shipments between organizations through Internal
Requisitions and Internal Orders.

INV: Advanced Pricing for Inter-company Invoice

This Yes/NO profile option can only be set at the Site level and controls whether or not the INCIAR
process uses the Advanced Pricing Engine to determine the Transfer pricing for Inter-company Invoices.

QP: Pricing Transaction Entity

This profile indicates the current Pricing Transaction Entity in use. Only contexts and attributes assigned to
the current Pricing Transaction Entity will be available in the LOVs on the setup forms. The default is “Order
Fulfillment”.

QP: Source System Code

This profile whether common or separate price lists are used for regular sales orders and inter-company
invoices. The default is “Oracle Pricing”.

Tax: Allow over-ride of Tax Code

This YES/NO profile option determines whether tax code information should be passed to AR for freight.

Tax: Invoice Freight as Revenue

This profile option determines whether freight lines should be invoiced as revenue lines.

Tax: Inventory Item for Freight

This profile option determines the inventory item that is used when freight lines are invoiced as revenue
lines.

Step 2: Receivable Systems Options

Receivable Systems Options have most likely been already setup but the “Require Salesperson Flag” is
important to ICI functionality. This flag MUST BE set to NO in the Shipping Operating Unit. The
INCIAR process generally does not pass Sales Credit information to Receivables and the process will fail if
this flag is checked.

OAUG Connection Point® 2006 Copyright 2006 by McCurry & Company, Inc. Page 7 of 21
Step 3: Inter-company AR Transaction Source (Batch Source)
Batch Sources control how receivables information is interfaced from Order Management to Oracle
Receivables. The INCIAR process uses the transaction source “Inter-company” that comes seeded with the
application to create the AR Invoice using Auto-accounting. The Inter-company Transaction source is
seeded with the appropriate values and it is generally recommended that you do not modify it with two
possible exceptions: the Allow Sales Credit Flag and the Transaction numbering.

It is important that the Inter-company AR Transaction Source be setup with a number sequence in the “Last
Number” field which is unique from Batch Sources used by other AR documents. Difficulties in querying
AR invoices can occur when the numbering sequence conflicts with the sequence of other AR transaction
types. It is best to define your other batch sources using a different range of numbers. But if you have
already begun to use this numbering sequence elsewhere, you may need to update the “Last number” value
directly. This value is drawn from the sequence “AR.RA_TRX_NUMBER_X_YYY_S”, where the “X”
refers to the Batch_Source_ID and “YYY” refers to the Organization_id for the Operating Unit. You
should contact Oracle support for assistance for re-setting this numbering sequence.

If your Auto Accounting configuration uses the Accounting Flexfield segment values from the Sales
Representative record to build the accounting flexfield combination for revenue, receivable, etc., it is
important that the “Allow Sales Credit Box” on the “Autoinvoice Options” tab of the Transaction Sources
form be checked.

OAUG Connection Point® 2006 Copyright 2006 by McCurry & Company, Inc. Page 8 of 21
Step 4: Auto-Accounting
The INCIAR process uses the Auto-Accounting setup in the Shipping Operating Unit to build the accounts
for the AR Invoice. Auto-Accounting allows to configure the build of the combinations for Receivables,
Revenue, Freight, Tax, etc. based upon Values from Inventory Item Attributes, AR Transaction Types, the
Internal Customer site, Salesreps, etc. The process uses these accounting flexfield combinations when it
creates the records in the AR interface table to be picked by the Auto-Invoice process. Based on how the
Auto-accounting has been defined, you must be mindful of the following considerations: If you are using
account segments from the Sales Representative Record in your Auto-accounting configuration, note that
Auto-Accounting will use the values from the “No Sales Credit” sales rep for these values. If you are using
account segments from the Standard Lines, Auto-Accounting will use the values from the Sales Account
Item Attribute in the OM Item Validation organization. Account segments using the transaction type will
pull from the AR Transaction type specified on the Inter-company Relations form.

Customizing the account generation for Inter-company AR Invoices.

The Auto-Accounting functionality has changed very little in the last several years and lacks the flexibility
of those processes that have been re-designed to use Workflow. It may be the case that the existing Auto-
Accounting configuration is too limited to derive the accounting required for the Inter-company AR
invoices. In this case, it may be necessary to update interface records before the Auto-invoice process is
run. One approach is to use a custom trigger to derive the necessary accounts for the generation of the
various accounts on the Inter-company AR Invoice. An example might look like this :

CREATE OR REPLACE TRIGGER APPS.XYZ_RA_INTERFACE_LINES_ALL_T1

BEFORE INSERT
ON AR.RA_INTERFACE_LINES_ALL
REFERENCING NEW AS NEW OLD AS OLD
FOR EACH ROW
WHEN (
new.interface_line_context in ('ORDER ENTRY','INTERCOMPANY') and new.line_type =
'LINE' and new.org_id in (123,456,789)
)
. . .
If :new.interface_line_context = 'INTERCOMPANY' then

. . .

OAUG Connection Point® 2006 Copyright 2006 by McCurry & Company, Inc. Page 9 of 21
Step 5: AR Transaction Types for the Inter-company Transactions
Transaction Types are assigned to invoices and credit memos and default key data such as payment terms,
accounts, tax, freight, posting and receivable information, etc. AR transaction types for Inter-company
transactions must be setup for each operating unit which contains inventory organizations that act as
shipping warehouses for selling operating units. Inter-company Invoicing between the operating units uses
the Auto-Accounting Rules. Depending on how these rules are defined, some of the accounting flexfield
segments may be derived from the accounts specified on the AR transaction type. It is advisable to create
AR transaction types for Inter-company Invoices and Credit Memos not only for the sake of providing
Account values for Auto-Accounting but also to provide visibility in AR to inter-company transactions.

Step 6: Transfer Pricing

There are three methods available to derive the price to be used as the transfer price for inter-company
invoices: Static, Advanced, and Custom. The most basic method is Static pricing, which pulls the transfer
price from the Price List specified on the internal customer. Advanced Pricing provides more flexibility by
using the Advanced Pricing Engine to derive the transfer price based upon its rules-based functionality. The
third method is to modify the pricing API to call a custom code to return the transfer price.

OAUG Connection Point® 2006 Copyright 2006 by McCurry & Company, Inc. Page 10 of 21
The INCIAR process uses the API called MTL_INTERCOMPANY_INVOICES.get-transfer_price to
derive the transfer price. The open architecture of this API allows the user to develop custom logic to
derive the transfer price using whatever rules and logic they require. If this API is not used, the process
progresses to determine whether static or advanced pricing will be used. The process uses the profile
option, INV: Advanced Pricing for Inter-company Invoice to determine the desired path to take. If the
profile option is set to “YES”, the Advanced Pricing Engine will be used. If the profile option is set to
“NO”, the transfer price will be taken from the static price list referenced on the Internal Customer record.

Inter-company Invoicing with Advanced Pricing

Oracle Advanced Pricing is a new application module introduced with Release 11i that is designed to be
flexible to support the pricing requirements of all kinds of business scenarios. It is an application that uses
rule-based components to determine the transfer price that goes well beyond the capabilities of static price
lists. Oracle Advanced Pricing uses rule-based components to accommodate the many pricing concepts
through standard configuration; and more specialized, complex pricing schemes through custom APIs and
PL/SQL procedures. To accomplish this, Advanced Pricing employs the use of a “pricing engine” that
calculates and returns a transfer price to the line based upon the parameters supplied to it. Depending on
how the pricing rules have been setup in Advance Pricing, these parameters can include whatever data
components drive the pricing of the item, such as Shipping or Selling Organization, Customer, Item, Item
Category, etc.

Oracle Advanced Pricing provides several seeded Qualifiers and Pricing Attributes that can be used to
derive the transfer price. The pricing engine selects the eligible list lines (Qualifiers and Modifiers) that
apply to the transfer price calculation. It should be noted that however the pricing engine is configured API
customized, it should be designed to always return a non-zero value. While it is possible to create AR
invoices with a price of zero, it is not possible to do so on the AP invoice and the INCIAP process will fail

Step 8: Payment Terms for AR and AP

The same payment terms must exist and must match in spelling and case in AR as in AP. Payment Terms
are assigned to both the internal customer and supplier so that the terms of the invoices created by the
INCIAR and INCIAP processes are the same.

OAUG Connection Point® 2006 Copyright 2006 by McCurry & Company, Inc. Page 11 of 21
Step 9: AR and AP Tax Codes
Tax Codes are setup in each operating unit. Tax names or tax codes are use on invoices to record invoice
taxes paid to suppliers and tax authorities. Each tax code has a tax type, a tax rate, and the account to which
tax amounts are charged. AR and AP tax codes and tax rates must be the same in order for the Inter-
company invoice generation processes to function properly. Separate tax codes should be created for inter-
company invoicing based on the inter-company accounting requirements. Each Tax Code has a different
GL account that is specific to the Selling Organization. It is important to assign the correct AP Tax code to
the Inter-company vendor in order to have the correct GL account represented.

Step 10: Internal Customer

Customer Address Information is maintained in each operating unit. Only the header information is
maintained at the Application Level and is shared across operating units. The internal customer is defined
in the shipping operating unit and is used by the INCIAR process based upon the inter-company relations
form. Payment terms and the Tax Code must be same as those used on the internal supplier in the selling
operating unit.

OAUG Connection Point® 2006 Copyright 2006 by McCurry & Company, Inc. Page 12 of 21
 If advanced pricing or a custom logic is not being used to derive the transfer pricing. The static price list to
be used by the INCIAR process for the AR inter-company invoice is specified on the internal customer
record. The INCIAP process will also use this price for the creation of the AP inter-company invoice.

Step 11: Internal Supplier

Supplier Address Information is maintained in each operating unit. Only the header information is
maintained at the Application Level and is shared across operating units. The internal supplier is defined in
the selling operating unit and is used by the INCIAP process based upon the inter-company relations form.
Payment terms and the Tax Code must be same as those used on the internal customer in the shipping
operating unit.

Step 12: Inter-company Transaction Flows

Transaction Flows outline the linkages between operating units and inventory organizations that define the
flows of financial transactions when inventory transactions take place the shipping organization and the
selling organization. This transactional flow can be quite different from the physical flow of goods due to
the presence of other operating units in between the shipping organization (source) and the selling
organization (destination), known as “intermediate” operating units. The addition of Transaction Flows in
Release 11.5.10 has greatly expanded the functionality of the Inter-company relations component of Inter-
company invoicing. The addition of these intermediate operating units has created a “transactional chain”
through which cost, revenue, and the transfer of liability can flow. The intermediate operating units serve as
links in the chain that can be sequenced as required to reflect the desired transaction flow without having to
perform manual transactions at each link. The Oracle Inventory Users guide calls these “Logical
Transactions” and defines them as “an accounting event that represents the financial transaction between
two operating units without the physical movement of goods”.

The Inter-company Transaction Flow (INVSICTF) form is a new from in Release 11.5.10 that is used for
creating transactions flows to support advanced inter-company invoicing for both selling and procuring
transaction flows. You must now define the Transaction Flow before defining the Inter-company relations.

OAUG Connection Point® 2006 Copyright 2006 by McCurry & Company, Inc. Page 13 of 21
First define the “ends of the chain”, the starting and ending operating units. For a selling relationship, these
are the Shipping and Selling Organizations. There are two transaction flow types, Selling and Procuring.
As the procurement part of the inter-company invoicing is outside the scope of this paper, the value
selected here is “Shipping”. Optionally enter the Ship-From Inventory Organization. Optionally enter a
Category Qualifier to use items that belong the Inventory Category Set. Check the Advanced Accounting
box if the transaction flow will include intermediate operating units. The intermediate operating units can
then be added into the Nodes region of the form.

Step 13: Inter-company Relations

Inter-company Relations are defined at the business group level to define relations between two operating
units and create the linkage between the internal customer (seller) and supplier (shipper). When a sales
order is entered in an operating unit and shipped from a shipping organization in a separate operating unit,
the inventory asset account for the shipping organization is credited and the cost of goods sold account is
debited. The sales revenue is recognized in the selling organization. The system performs the accounting
distributions to record the inter-company revenue, receivable, and payable entries.

Note: This is the 11.5.9 version of the form

OAUG Connection Point® 2006 Copyright 2006 by McCurry & Company, Inc. Page 14 of 21
This step is central to the Multi-org Inter-company invoicing functionality. Inter-company relations must be
defined for each selling/shipping relationship in the instance. Note, only one relationship can be defined in
one direction. It is possible to have multiple inter-company relation records where the shipping operating
unit and the selling operating unit are the same.

In the 11.5.10 version of the inter-company relations form, the Currency Code Field can be used to define
the currency code to be used in the Inter-company AR invoice. This field is only used when the profile
option “INV: Advanced Pricing for Inter-company Invoice” is set to YES. When the profile option is set to
“NO”, the INCIAR process uses the currency of the Price List used by the Inter-company customer.
Options for the field when FI Type is “Shipping” are: Shipping Operating Unit, Selling Operating Unit, and
Order Currency.

Step 14: Inventory COGS Account Generator

The account generator uses Oracle Workflow to derive General Ledger Accounting Flexfield combinations
for different applications. The INCIAP process uses the Inventory COGS Account Generator to derive the
COGS account for the selling operating unit. Oracle Workflow is a very open architecture and allows you
to customize the account generation process as needed. Workflow is an application that manages business
processes according to pre-defined set of rules. The Oracle Applications Suite comes with many standard
workflow processes embedded to provide better control and visibility of transactions. These processes
include activities that are linked together in a logical order to control how transactions are processed.
These activities are composed of functions, notifications, business events, and sub-flows and can be
modified or re-arranged to meet the specific requirements of the business. Functions, notifications, item
types, and messages are linked together to create processes using a tool called Workflow Builder.
Workflow Builder uses “drag and drop” functionality in an Editor Window and a long list of seeded
activities to enable the user to add, delete, or modify various processes. New activities can be easily
created by copying and modifying any of the seeded components. Functions, Messages, and Lookup Types
are powerful building blocks in defining workflow processes because they are very flexible and easily
customized. Workflow functions call stored PL/SQL procedures or external functions to do the work of the
process. This provides a very open environment to allow the user to address the specific requirements of
the business process. Workflow processes are initiated when an Oracle application calls the Workflow
engine. The application instructs the engine which workflow process to run. The engine is embedded in
the database server and coordinates and monitors the activities in the process, determining which activities
are eligible to run, executing the activities, and progressing to the next activity.

The Inventory COGS Account Generator is used by the INCIAP process to derive the COGS account for
the selling operating unit. The Account Generator dynamically creates a COGS Account for order and
return lines which go the INCIAR process. This is different workflow from the OM COGS Account
Generator. The seeded Inventory COGS workflow can derive the COGS account from the COGS Item
Attribute in the Shipping Organization or from the Order Type. If you need to build account code
combination based on a more complex logic using other attributes, you can copy the Workflow and modify
it as needed.

OAUG Connection Point® 2006 Copyright 2006 by McCurry & Company, Inc. Page 15 of 21
Step 15: Order Transaction Types
While separate order transaction types are not required for Inter-company invoicing, it is recommended to
create them in order to segregate orders shipped from another operating unit from “regular” orders. Also, if
the selling organization processes orders that are shipped from different shipping organization, it may be
helpful to segregate orders. Depending on how the Auto-Accounting rules and/or Inventory COGS account
generator are defined, it may be required to create separate order transaction Types to drive the correct
accounting for your inter-company invoicing transactions.

Step 16: Release Rules

Separate Release Rules are recommended for internal drop-ship orders. Rules are defined at the application
level and used as a LOV for selecting a Default at the Shipping Organization level. Default pick release
rules are applied at pick release in the Release Sales Orders window. Each rule can be set up with its own
set of unique pick release parameters depending on the pick release criteria required.

Step 17: Inter-Company AR and AP Processes – INCIAR & INCIAP

The Create Inter-Company AR Process - INCIAR
The INCIAR process generates the Inter-company receivable invoice for the Shipping operating unit from
the internal customer. It creates the receivable transaction and loads it into the AR open interface table.
Auto-invoice picks up this transaction and creates the actual AR invoice. The AR Transaction date is the
same as the inventory shipping confirmation transaction date. The transfer price and currency for the
invoice is either drawn from the inter-company price list or derived using Advanced Pricing. It should be
noted as a reconciliation tool that the ID of the record in the Create INCIAR request log will equals the
material transaction ID.

The Create Inter-Company AP Process- INCIAP

The INCIAP process generates an Inter-company payables invoice for the Selling operating unit from the
internal supplier , the shipping operating unit. INCIAP uses the AR invoice created by the INCIAR process
to create an AP invoice that “mirrors” the AR Invoice. The INCIAP process records the AP invoice in the
same currency as the Inter-company AR invoice. If this currency is different from the functional currency
in the set of books used by the Selling operating unit, Oracle will convert the invoice using the exchange
rates based on the GL date of the invoice line. The INCIAP Process uses the Inventory COGS Account
Generator workflow to derive the COGS Account. Please refer to step 14 above. The INCIAP Process uses
the freight account from the Inter-company relations form. Pleases refer to step 13 above. The INCIAP
Process uses the AP Liability Account from the inter-company supplier site (Shipping organization)
specified on the Inter-company relations form. INCIAP creates the payable transaction and loads it into the
Expense Report open interface table. The Expense Report import program picks up this transaction and
creates the actual AP invoice.

Creating Report-Sets for the INCIAR & INCIAP processes

Depending on the volume of inter-company transactions that take place on any given day, it is
recommended to create report sets that routinely run and create the AR and AP invoices. In this way,
running the INCIAR and INCIAP processes can be married with running the Auto-Invoice and Expense
Report Import processes. It should be noted that each Report Set must be setup in the correct operating unit
in order for the Auto-Invoice and Expense Report Import processes to run correctly. It is also
recommended that the two report sets always be set to run such that they complete on the same day to
insure that both invoices are created in the same accounting period.

OAUG Connection Point® 2006 Copyright 2006 by McCurry & Company, Inc. Page 16 of 21
Request Set for the Shipping Operating Unit

Request Set
Set XYZ Inter-company Invoices - Shipping
Set Code XYZ_INCIAR_SET
Application Oracle Inventory
Description Process Inter-company AR Invoice between Company Y
and X
Owner MCCURRYD

Set XYZ Inter-company Set Application Oracle

Invoices - Shipping Inventory
Display
Stage Description
Seq
10 INCIAR- Company Y Generate AR Invoice for Shipping O.U.
Auto-Invoice Inter-co Run Auto-invoice for Inter-company AR
20
Invoices invoices

Request Set for the Selling Operating Unit

Request Set
Set XYZ Inter-company Invoices - Selling
Set Code XYZ_INCIAP_SET
Application Oracle Inventory
Description Process Inter-company AP Invoice between Company X
and Y
Owner MCCURRYD

Set XYZ Inter-company Set Application Oracle

Invoices - Selling Inventory
Display
Stage Description
Seq
10 INCIAP- Company X Generate AP Invoice for Selling O.U.
Run Expense Report Import Inter-
20 Import Inter-co AP Invoices
company AP invoices

Reconciling Inter-company Transactions.

Because internal drop-ship orders create transactions that cross operating units, it can be problematic to
reconcile transactions in the event of an error somewhere in the process. Below is a SQL statement that
can be used to create reporting to aid in the reconciliation process.

SELECT

OAUG Connection Point® 2006 Copyright 2006 by McCurry & Company, Inc. Page 17 of 21
 (SELECT name FROM HR_ALL_ORGANIZATION_UNITS WHERE
organization_id = oeh.org_id) SELLER,
(SELECT organization_code FROM MTL_PARAMETERS WHERE
organization_id =oel.ship_from_org_id) WAREHOUSE,
oi.org_information3 SHIP_OU,
oett.name ORDER_TYPE,
oeh.order_number,
oel.line_number,
oel.ordered_item,
oel.request_date,
oel.actual_shipment_date,
oel.shipped_quantity,
oel.unit_selling_price,
ps_sell.trx_number,
ps_sell.trx_date,
ps_sell.amount_due_original,
ps_sell.invoice_currency_code,
ps_ship.trx_number ICAR_TRX_NUM,
ps_ship.trx_date ICAR_TRX_DATE,
ps_ship.amount_due_original ICAR_AMOUNT_DUE,
ps_ship.invoice_currency_code ICAR_CURRENCY,
pia.invoice_num ICAP_INV_NUM,
pia.invoice_date ICAP_INV_DATE,
pia.invoice_amount ICAP_INV_AMT,
pia.invoice_currency_code ICAP_CURRENCY
FROM oe_order_headers_all oeh,
oe_order_lines_all oel,
hr_organization_information oi,
oe_transaction_types_tl oett,
ra_customer_trx_lines_all ctl_sell,
ra_customer_trx_lines_all ctl_ship,
ar_payment_schedules_all ps_sell,
ar_payment_schedules_all ps_ship,
mtl_intercompany_parameters mip,
ap_invoices_all pia,
ap_invoice_distributions_all pid
WHERE oeh.header_id=oel.header_id
AND oel.shipping_interfaced_flag='Y'
AND oeh.order_type_id=oett.transaction_type_id
AND oett.language='US'
AND ctl_sell.org_id=oeh.org_id
AND ctl_sell.interface_line_context='ORDER ENTRY'
AND ctl_sell.interface_line_attribute1=to_char(oeh.order_number)
AND ctl_sell.interface_line_attribute6=to_char(oel.line_id)
AND ctl_sell.customer_trx_id=ps_sell.customer_trx_id
AND ctl_ship.org_id=oi.org_information3
AND ctl_ship.interface_line_context='INTERCOMPANY'
AND ctl_ship.interface_line_attribute1=to_char(oeh.order_number)
AND ctl_ship.interface_line_attribute6=to_char(oel.line_id)
AND ctl_ship.customer_trx_id=ps_ship.customer_trx_id
AND mip.sell_organization_id=oeh.org_id
AND mip.ship_organization_id=oi.org_information3
AND mip.customer_site_id=ps_ship.customer_site_use_id
AND pia.vendor_id=mip.vendor_id
AND pia.invoice_num=ps_ship.trx_number
AND pia.org_id=oeh.org_id
AND pid.invoice_id=pia.invoice_id
AND to_char(pid.reference_1)=ctl_ship.customer_trx_line_id
AND pid.reference_2=ctl_ship.interface_line_attribute7
AND oel.ship_from_org_id=oi.organization_id
AND oi.org_information_context='Accounting Information'
AND oel.org_id<>oi.org_information3

OAUG Connection Point® 2006 Copyright 2006 by McCurry & Company, Inc. Page 18 of 21
Limitations and Considerations
1. Business Practices
It will be necessary for the companies to standardize their policies regarding parts returns and
special charges. The inter-company invoicing functionality is not designed to accommodate
situations where the selling and shipping organizations apply different product return policies
and/or process, and charge each other expedite fees and special handling charges which are not
passed on to the customer.

2. Impact on Reporting
Standard and Custom Reporting may need to be modified or augmented to accommodate the
transactions across operating units. The CoGS transaction for Company Y will come from AP
rather than from Inventory. As a result, some standard COGS and Standard Margin reports may
not be usable for these transactions, so the Revenue and COGS transaction for Y may require
additional linking for reporting purposes.

3. Use of Inventory Transactions outside of Order Management

Miscellaneous transactions in inventory cannot be used in any way for transactions relating to
cross-operating unit sale order fulfillment. This functionality only works with transactions entered
through Order Management. Manual adjustments entered directly in inventory will not transact
across operating units.

4. Manual Adjustment to Inter-company Credit Memos

When returned parts are non-conforming and the Shipping organization denies credit to the Selling
organization, inter-company AR and AP invoices must both be manually updated in a coordinated
effort by both operating units.

5. Copying Orders
The use of this functionality is heavily dependant upon configurations and Workflows associated
with Order Types, both header and lines. Significant errors can occur if cross-operating unit
orders are created using “Normal” order types or standard orders are generated using the inter-
company order types. It is a requirement that Customer service be very mindful of the type of
order being generated and that the correct order and line type are being used. This is especially
true with Orders are created by the copying of others orders.

Standard Orders should NOT be copied to generate Inter-company orders and vice-versa. Each set
of Order types update different fields on the orders and defaulting rules may or may not be
correctly applied.

6. Maintaining an Inter-company Price List

The use of this functionality with advanced pricing requires that the inter-company price list be
maintained and kept in synchronization with the price list used by the sales order. The create inter-
company AR invoice process will fail for those orders where the item shipped is not on the inter-
company price list. An alternative approach would be to use Advanced pricing and create a
modifier that does not require the maintenance of the inter-company price list.

7. Non-Shippable Items
Intercompany invoicing is only possible for items that go thru the inventory interface and as such
only works for shippable items. At this point, there is no functionality available for inter-company
invoicing of Service items. The following Item Attributes must be enabled for items to be
transactable: Customer Ordered, Customer Order Enabled, Internal Ordered, Internal Order
Enabled, Invoicable Item, Invoice Enabled, Cost Enabled, Stockable, Transactable, and Inventory
Item.

OAUG Connection Point® 2006 Copyright 2006 by McCurry & Company, Inc. Page 19 of 21
 8. Profile Option INV:Intercompany Invoice for Internal Orders
The INCIAR process only uses the value set at the site level. This creates a problem when you
want to create inter-company invoices for internal drop shipments but not for regular internal
orders.

Conclusions
Inter-company invoicing functionality is a component of Multi-Org that facilitates the sourcing of
shipments from physical warehouses, reducing stocks, freight and inventory carrying costs at distribution
and service locations without legal structure complications and redundant procurement, inventory order
fulfillment processes. It can reduce order lead times by removing “corporate obstacles” to global inventory
planning, making the legal structure of the enterprise transparent to the end-customer. With the advent of
Sarbanes-Oxley, there is a greater need to maintain accuracy and transparency for inter-company activities.

Inter-company Invoicing is standard Oracle functionality that significantly streamlines the business process
by eliminating the generation of redundant purchase orders, inventory transactions, and sales orders
between the related parties by automating the inter-company transaction flow by creating an internal
customer-supplier relationship between related parties with customer orders are taken in one organization
but shipped from another. Several redundant process can be eliminated, reducing the overall order
fulfillment time and gets the product to the end customer faster. The planning and procurement activities
can also be centralized as a single source of supply for the enterprise. This also provides for the
consolidating of inventory with one organization and reduces overall inventory carrying costs.

Inter-company invoicing has been available in the Oracle applications since Multi-Org was first introduced
in Release 10.6. Multi-Organization functionality enables an enterprise to operate independent business
units within a single installation of the software and still maintain segregation of the data by business units.
With the release of 11i, the introduction of Advanced Pricing expanded the flexibility in deriving the
transfer price. The replacement of Flex-builder with the Workflow-based COGS Account Generator
expanded the flexibility in deriving the COGS Account for the shipping transaction. With the release of
11.5.10 of the applications, procurement flows have been added to the established shipping flows of the
inter-company invoicing functionality. Procurement Flows provides for and inter-company invoicing for
global procurement. This addition allows for the generation of Purchase Orders in one operating unit with
the receipt of goods into the inventory organization belonging to another.

While there are limitations and constraints to the functionality, Inter-company invoicing has evolved into a
very powerful yet flexible tool in handling complex business structures and the business transactions
associated with them. Because of its use of the Advanced Pricing and Workflow applications, open
interfaces and public APIs, it is designed to be open enough to accommodate any business situation.
Implementing inter-company invoicing can yield great rewards when applied to an environment where
physical transaction flows do not match the logical transaction flows and the logical transaction flows are
not at all logical.

Sources and Additional Reading

Oracle Inventory Users Guide – Release 11i, Part #A83507-09, Chapter 14 Inter-company Invoicing.
Oracle Workflow Users Guide – Release 11i,Part # B15854-04.
Oracle Advanced Pricing Implementation Manual- Release 11i, Part #B14385-03.
Overview of Inter-Company Invoicing, Oracle White Paper, July 2005

OAUG Connection Point® 2006 Copyright 2006 by McCurry & Company, Inc. Page 20 of 21
About the Author.
David McCurry is a senior consultant specializing the Oracle distribution and manufacturing applications.
He has worked for over ten years as a senior and implementation consultant in mid-size to large
manufacturing companies throughout the United States, Europe, Eastern Europe, and the Caribbean Basin.
Mr. McCurry also has over 20 years experience in multiple environments spanning the
Telecommunications, Textile, Aerospace, Electronics, Chemical, Transportation and Consumer/Industrial
products industries. Mr. McCurry has also previously presented papers at OAUG conferences in Europe
and the Asia/Pacific.

OAUG Connection Point® 2006 Copyright 2006 by McCurry & Company, Inc. Page 21 of 21