Cross Charging Options – An Alternative Approach

In my last posting we discussed the various options for cross charging within Oracle Projects.  Today I would like to focus on the options of Inter-Project Billing and Inter-Company Billing and the issues with utilizing either one.

As stated in my last blog, the cross charging options were broken down as follows

As you can see from the chart above the only way to cross ledgers (utilizing standard functionality) in R12 is with either Inter-Project Billing or Intercompany Billing.  Both of which were defined as follows:

Inter-Project Billing – Unlike Direct Charge and Borrowed and Lent functionality, this functionality will require the setup and maintenance of multiple projects. This method requires that the Provider/Receiver controls have the Cross Charge Process Method of None.  In this model one project will bill the customer while multiple other projects charge into it.  This method will support charging across ledgers.  In addition, this method also allows for multiple “Receiver” projects in the receiving OU.  In addition, this functionality will result in the generation of internal AR/AP invoices.  The providing projects will generate internal AR invoices that will result in internal AP invoices for the receiving project.  Therefore, this functionality will require that Provider OU’s be setup as suppliers and Receiver OU’s be setup as customers.  A key advantage to Inter-Project Billing is that even though costs are initially collected across different projects they are captured in the project that is billing the customer.  Additionally, the associated AP Invoice for the Receiving OU is created automatically via the PRC: Tieback Invoices from Receivables process that is run in the Provider OU.  These invoices will be imported into AP via the Open Invoice Interface.  The Supplier Invoice Account Generator will have to be modified to properly account for internal AP invoices.  In addition, the AutoAccounting in Projects will need to be configured as well to generate the appropriate accounting.  This option will support cross charging across ledgers.

Intercompany Billing – This functionality works the same as the Inter-Project Billing functionality with one key exception, there can only be one receiving project per organization.  In this case Provider OU’s will bill the Receiver OU’s Intercompany Billing project only.  In addition, the Provider/Receiver controls must have the Cross Charge Process method set to Intercompany Billing.  The project in the Receiver OU that is responsible for billing the customer will NOT have the costs from the various other projects that supported it as these costs are billed to the OU level Receiving Project.  In addition, you will need to configure the Intercompany Revenue and Intercompany Invoicing AutoAccounting functions.  The Supplier Invoice Account Generator will also have to be modified to properly account for internal AP invoices.  This option will support cross charging across ledgers.

So to keep it simple, Inter-Project Billing supports the utilization of multiple receiver projects; whereas Intercompany only allows for one receiver project at the operating unit level.   Another point to consider is that Intercompany Billing CANNOT be utilized with Capital Projects.  You must use Inter-Project Billing when utilizing Capital Projects.  As you can well imagine the requirement to utilize receiver projects no matter what model you choose will increase the number of projects that you will have to create and maintain.  If you are utilizing Inter-Project Billing the number of projects and the associated overhead could increase dramatically.

I have had a number of customers tell me they really don’t want to have to deal with the additional overhead related to creating and maintaining the additional projects to support Inter-Project Billing and want a way to maintain the accounting functionality that is delivered as a result of utilizing this functionality.

At a recent client we ran into this very scenario.  The client is a multiple OU/Ledger company that consistently has OU’s charging one another to support their Contract and Internal Projects (Non-Capital).

The IT Leader's Guide to Multicloud Readiness

This guide provides practical key insights and important factors to consider to make informed decisions in your multicloud journey.

Download the Guide

The solution we developed was to leverage standard cross charge functionality to allow the external OU’s to charge directly to the project.  Because we had controls in place that allowed only certain companies to charge to certain ledgers we had to configure AutoAccounting to address the situation.  The appropriate cost rules were modified to determine if the company charging the project was in the OU that owned the project and depending on the result of the comparison the company segment was then populated with a value that was acceptable to the Ledger being processed.  In addition, the Account segment rule had to be modified to utilize the same comparison to determine if the transaction should book to intercompany or expense.  If the result of the comparison determined the company charging the project was not within the OU of the company that owned the project then the charge is booked to an intercompany account.  This solution worked fine for building out the entries for the ledger being processed but we still needed to address the ledger that owned the project.

In order to generate the appropriate entries to offset the intercompany transactions we had to design a custom program in GL.  Basically the program locates the intercompany transactions that were posted to GL.  From this population of transactions the program builds the appropriate offsetting entries to the appropriate ledgers and loads them to GL via the Journal load functionality, this giving us the capability to cross ledgers with the proper accounting entries in the appropriate ledgers without invoking Inter-Project Billing and incurring the associated overhead.

To illustrate the solution:

Project A is in the UK Operating Unit with a Project Currency of GBP (assume conversion rate of 1.5).

Company Segment for US OU = 10

Company Segment for UK OU = 61

Intercompany Account = 11111

Expense Account = 33333

Labor Clearing Account = 22222

The US Operating Unit is providing resources to support this project.  Based upon the Provider/Receiver Controls setups the US Operating Unit can charge directly to the UK Operating Unit.

An US employee charges $100 worth of labor cost to the UK via OTL.  Because the cost for the labor transactions must be processed in the OU in which the resource resides, the PRC: Distribute Labor Costs Process must be run in the US OU in order to properly account the transaction.  Based upon the fact the transaction is from an OU outside of the OU that owns the projects the process returns the following results.

After the transactions has been posted to GL, the custom concurrent program for building the off-setting entries for the UK OU can be fired and will return the following results.

As you can see the proper accounting entries can be generated with the proper amounts reflected at the proper currency valuations with this approach – across ledgers and without implementing Inter-Project or Intercompany Billing.

Note this approach may not work in all instances and is definitely contingent upon your application footprint.  It is also important to note that this model will only work for Contract and Indirect projects.  It does not support Capital Projects and as stated previously the only model that will support Capital Projects is Inter-Project Billing.