You are on page 1of 6

Applies to: Oracle Project Costing: E- Business Suite and Fusion PPM

Simplifying Oracle Project Accounting- Cross charges and inter-


company billing.
These functionality provided by Oracle’s project accounting application (In Ebiz and FUSION) are
aimed to help project transactions in multi- org, multi- operating unit (Business Unit) and multi- legal
entity setup. There are scenarios where a resource is owned functionally by a different organization
and a project from a different organization wants to use the same resource for completion of
activities. Hence either a cross charge is used to keep track of transactions within a legal entity and if
the organizations are in different legal entity, inter- company billing is used.

This article would keep the focus on E- Business suite to explain each of these transactions.

The organization that provides the resources is called a provider organization and the one which
owns the project for which the resource is used called a receiver organization.

There are four scenarios where this kind of transaction may take place. These are as follows:

1. Intra Operating Unit- Both the organizations are under the same Operating unit.
2. Inter Operating Unit- Both organizations are in different operating unit but under the same
legal entity.
3. Inter- company- Both organizations are in different legal entities OR in different Operating
Units.
4. Inter- project: As the name suggests the transaction occur between two projects

Intra and inter operating unit transactions are called as borrowed and lent (B & L ) transactions. As
the name suggests, one organizations borrows and other one lends the resources.

On the other hand, Inter- Company billing, as the name suggests, is used to bill the organization
which uses the resources for its projects. Proper AR and AP invoices are generated in provider and
receiver organizations respectively.

Borrowed and Lent transactions


For both intra and inter operating unit transactions, the process is more or less the same with very
little variation. The primary aim of the B&L process is to create a debit and credit entry for the
receiver organizations expenditure item:

Accounts Debit Credit


Receiver Org Charge Account 1000 USD
Provider Org Clearing Account 1000 AED
The project is owned by the receiver organization. When transactions are made in one of various
sources, the provider organizations name is entered against the project owned by the receiver
organization.

Example 1- Time Cards: Let us see the case for an inter OU transaction. A project “B&L Project 1”
belongs to organization Services- West. The resource, Marlin Amy, belongs to Services- East (Both
Services- West and Services- East fall under the OU: Vision Services)

A Straight Time expenditure batch is entered for the following combination:

Project: B&L Project 1


Employee Name: Marlin Amy
Organziation: Services- East.

Example 2- Supplier Cost: While entering the supplier cost, expenditure type is entered against the
provider organization.

Project: B&L Project 1


Task: <Name and number of chargeable task>
Expenditure Type: <Enter expenditure type name>
Expenditure Organization: Services- East.
Setup
Setup for both Intra and inter operating unit Borrowed and lent are the same except for an extra
step in the Inter OU process.

1. Setup Transfer Price Rule


2. Enable Cross Charge at project and task level- set transfer price rule for labor and non- labor
resources.
3. Implementation Option: Cross Charge Tab- Set default values for intra and inter OU cross
charge transactions.
4. Define Auto Accounting Functions:
a. Borrowed and Lent debit accounts
b. Borrowed and Lent debit credit accounts
c. Labor Revenue Borrowed account
d. Usage Revenue Borrowed account
5. Additionally for inter operating unit, processing method should be set in the “Provider and
Receiver Controls” for the Provider Operating unit. The processing method should be set to:
BORROWED AND LENT for inter- operating unit transactions.

Concurrent Processes
The list of concurrent processes that need to be run are also same:

1. PRC: Distribute Labor Cost (for the type of transaction that is made)
2. PRC: Distribute Borrowed and Lent Amounts
3. PRC: Generate Cost accounting events
4. PRC: Generate Cross charge accounting events.
5. PRC: Create Accounting.

The process results in creation of expenditure items which can be easily identified. For any borrowed
and lent transaction, the cross charge processing method= Borrowed and Lent

But the cross charge type, respectively for intra OU and inter OU transactions would be - “Intra
Operating Unit” and “Inter Operating Unit”

Intercompany Billing
Before moving to the actual setup and transactions a mention about the relation between legal
entities and operating units:

There is no direct relation between Operating Unit or Legal Entity. OU is associated to a ledger and
so is the Legal Entity. Hence, multiple legal entities and a single operating unit can be placed under a
single ledger.
For inter- company billing, the provider and receiver operating units must be in different legal
entities.

As mentioned earlier, the intercompany billing follows the line of procure to pay cycle, i.e, one
project organization procures the services of personal/ equipment of other organization and the one
selling the services bills the organization which buys the service. Transfer price schedule is th e
governing factor for rates if the organization which want to bill the services sold wants to make a
profit on the transaction. The organization that buys the services interfaces the AR invoice from the
organization that sells the services as an AP invoice into projects directly, thus accounting for the
costs.

Let us begin by taking the example of an operating unit X which is actually executing the project. The
project in question procures services and materials of contractors to complete the actual work and
result in an output that is tangible or otherwise. Now, since this operating unit is a part of a bigger
organization which has other business interests, specific services can be procured or contracted
from other operating units. Now, the other operating unit Y which provides the specialist services,
maintains a separate accounting book and has a business reporting model different than the
operating unit X which actually owns the project.

Provider OU- Y Receiver OU- X


- Provides services Invoice receiver OU
- Receives services
- Owns dummy from other Ous
project - Invoices clients

Now in the example stated above, Operating Unit X is the receiver OU and the Operating Unit Y is
the provider OU. OU X is associated to LE- X and OU Y is associated to LE- Y.

Setup and preparation for Intercompany Billing


Before starting the intercompany transactions, please complete the following:

1. The receiver OU- X should be marked as ‘Receiver for Internal Billing’ in the implementation
option’s ‘Internal Billing’ tab. The provider OU- Y should be marked as ‘Provider for Internal
Billing’ in the implementation option’s ‘Internal Billing’ Tab
2. Setting up of transfer price schedule
3. Define Auto Accounting Function: Intercompany Invoice Accounts
4. Receiver Project:
a. Once the contract project, say ‘Customer Billing Project’ is created in the receiver
OU- X for capturing transaction and invoicing external clients, enable cross charge at
project and task level to receive the transactions from OU- Y.
b. Define the transfer price schedule that needs to be used when executing the step
above for labor and non- labor transactions.
5. Provider Project:
a. Create Project under OU- Y to associate to ‘Provider Controls’ in ‘Provider and
Receiver Controls’. The project should be of ‘Contract’ project type and enabled for
intercompany billing [Intercompany Flag= Yes, in the project type]. As informed
earlier, this is just a dummy project and used to bill the project in OU- X.
b. Assign the internal customer to the project under the ‘Customer and Contacts’
form. The internal customer is the receiving projects operating unit- OU- X
c. This project should have a funding. The funding is automatically baselined as the
flag: Intercompany is set as yes in project type. The funding limit is not checked once
the invoice generation starts.

Provider and Receiver Controls for Receiver Operating Unit


Let us start by understanding the receiver OU- X and the projects it owns. Receiver operating unit
may own multitude of projects because it is the organization that does the “PROJECTS” business. The
complete setup for Oracle project’s module will be done around the OU X.

For better understanding, let us setup the provider and receiver control for the receiving operating
unit- X, first.

Navigate to Setup> Costing> Provider and Receiver Controls

Select Operating Unit X and click on ‘Receiver Controls’- It will be the second tab in the form.

Define the following:

1. Provider Operating units (Operating Unit X in this case)


2. The legal entity of the (LE of Operating Unit X)
3. Supplier Name- the Operating unit should be setup as an internal supplier as a pre-requisite
before intercompany billing is executed.
4. Supplier Site
5. Expenditure Type: Since the cost borne by the provider organization is treated as a supplier
invoice, there should be a separate expenditure item of expenditure item class ‘Supplier
Invoice’ that should be associated with the inter- company transactions.
6. Expenditure Organization: As with any project accounting transactions, there should be a
project expenditure organization for the expense. Since OU X is set as a project organization
the same should be used as the expenditure organization (or any other organization that is
required by the setup)

Provider and Receiver controls for Provider Operating Unit:


Provider operating unit owns the services that it wants to sell. The customer can be an internal
organization, like OU- Y or external. There will be a mark- up in the transfer price schedule if the
provider operating unit( OU- Y) seeks to make profit even from the inter- company transactions
between OU X and OU Y.

Let us now discuss the setup for the provider operating unit- Y.

Navigate to Setup> Costing> Provider and Receiver Controls

Select Operating Unit Y and click on ‘Provider Controls’- It will be the first tab in the form.

Define the following:

1. Receiver Operating: Select OU- Y


2. Receiver Legal Entity: Select the LE of OU- Y
3. Allow cross- charge: Set to YES
4. Processing Method: Set to Intercompany Billing. Since we are transacting between two
operating units belonging to different legal entities.
5. Inter- company billing project: A project needs to be defined in the OU Y which will be used
for transactions only. This is a dummy project and used only for accounting any
intercompany transactions between OU X and OU Y. If a second operating unit belonging to a
different legal entity needs OU Ys services and invoice OU Y for the same, then a second line
should be defined in the provider controls for the new operating unit. A new project should
be created in OU- Y for capturing the transactions between the new operating unit and OU -
Y.
6. Enter invoice grouping method.

Transactions

Provider OU incur costs and charges to receiver project directly.

1. Login with OU- Y responsibility and create an expenditure item for the project: ‘Customer
Billing Project’ in OU- X.
2. Distribute and account the cost entered above.
3. With OU – Y responsibility run PRC: Generate Intercompany Invoices for a single project.
4. Approve and release the invoice.
5. Run PRC: Interface Invoices to Receivables
6. Login with receivables responsibility for OU- Y, and execute Auto Invoice import to create
receivables invoice.
7. Account the receivables invoice.
8. Tieback from receivables.
9. Login with OU- X payables responsibility and run the Payables Open Interface import
program
10. Login with OU- X projects responsibility and run the program: PRC: Import Supplier Costs.
This completes the costing process for the project: Custom Billing Project.

Inter-Project Billing
The main difference between inter- company billing and inter- project billing is that when costs are
incurred in the first case, the transactions are booked against the receiving operating unit’s project
where as in the latter, the costs are booked against the provider operating unit’s projects.

Inter- project Billing- is used if invoices are needed for work done between two projects.

Unlike intercompany invoicing, the project owned by the provider organization is a full- fledged
project in itself. Each provider operating unit should create a project and own it completely. The
project should have an agreement and baselined funding to generate inter- project invoice. Funding
limit is checked for inter- project billing as in a normal contract project.

User does not have to setup the provider and receiver controls for the operating unit that acts as the
provider. Instead of setting up provider and receiver control, user has to add the project in the
'Customer and Contacts' form in the projects.

When transactions are incurred, the expenditure item is booked against the respective provider
project. These costs are distributed against the provider organization. Even though the cost is
accounted after distribution, the external client associated to the receiver project cannot be billed
unless the receivables invoice is generated and transferred as AP invoice to the receivables project.

The project invoice is generated using the process PRC: Generate Draft Invoice for a single project.
This process is same in case when the project customer is external. The project invoice for inter-
project invoices are treated as normal invoice to generate the AR invoices.
Once the AR invoices are generated and tie back to the Provider OUs Project, the process to import
supplier invoice from open invoice interface is run from the account payables responsibility of the
receiving project's operating unit.

Once this cost is imported fully, accounted in GL and treated as a supplier invoice in the receiving
operating unit, the same is transferred to projects as actual costs.

Now the receiving project can invoice the external customer based on the actual cost/ work
incurred.

Transfer Price Schedules (TPS)


Transfer price schedules are rule based schedules. User can establish separate TPS for labor and
non- labor transactions or use separate ones.

The transfer price rules can be set to pick up raw cost, burdened cost or revenue amount as the
basis to transfer the cost to the receiving organization. Additional mark- up can be provided to the
rule if the provider organization wants to incur a profit. The rule can use burden schedule or bill - rate
schedule to calculate the cost that needs to transferred.

The rules are then associated to the transfer price schedule. Additional mark- up or discount can be
entered in the TPS for defining the cross charges between two organizations.

References

Cross-Charge: Borrowed & Lent and Inter-Company Processing in Oracle Projects (Doc ID
1351653.1):
https://support.oracle.com/epmos/faces/DocumentDisplay?parent=DOCUMENT&sourceId=135165
3.1&id=1552582.1

Difference between Inter-Project Billing and Intercompany Billing (Doc ID 273091.1):


https://support.oracle.com/epmos/main/downloadattachmentprocessor?parent=DOCUMENT&sour
ceId=273091.1&attachid=273091.1:IP-IC_DIFFERENCES&clickstream=yes

You might also like