Oracle R12 Projects – Cross Charge Billing options : Inter-Project Billing, Intercompany Billing, Direct Charge etc

Over the past several implementations we have dealt with we have encountered more than a few variations as to how customers want to handle their cross charge transactions.  And as you can well imagine this always leads to numerous questions as to how the functionality works and what exactly the options are.  It is often difficult as an implementer to get across to the client just what the best fit is because they often aren’t sure of what their future structure could look like post implementation.

Basically there are some key questions you will need to take into consideration when addressing cross charging within Oracle Projects.  First thing you will need to determine is are there separate ledgers involved.  If there are then your options are going to be limited.  But before we get into that let’s discuss all of the options first.

Per the Oracle documentation there are three TYPES of cross charging transactions (see below) which use either Borrowed and Lent, Intercompany Billing or No Cross Charge Process as METHODS of cross charging.

Cross   Charge Type Conditions
Intra-operating unit Provider operating unit equals receiver operating unitProvider organization does not equal receiving organization
Inter-operating unit Provider operating unit does not equal receiver operating unitProvider legal entity equals receiver legal entity
Intercompany Provider legal entity does not equal receiver legal entity

Cross Charge Processing Methods

You can choose one of the following processing methods for cross charge transactions.

  • Borrowed and Lent Accounting (inter-operating unit and intra-operating unit cross charges)
  • Intercompany Billing Accounting (intercompany and inter-operating unit cross charges)
  • No Cross Charge Process (intercompany, inter-operating unit, and intra-operating unit cross charges)

The Borrowed and Lent method allows you to cross charge between organizations (intra-operating unit) or between operating units (inter-operating unit).  You can only charge between operating units if the legal entities (ledgers) are the same, which they typically are not.  This method creates accounting entries to pass costs and revenue without generating internal invoices.  Transfer pricing can be defined for this method.

The Intercompany method allows you to cross charge between legal entities (intercompany) or between operating units (inter-operating unit).  This method is typically chosen when companies are required to generate internal invoices due to legal and/or statutory requirements.

The No Cross Charge Method is used if there is not a requirement to process the cross charge transactions, but there is still a requirement to reflect charges or revenue from one project to another project.

Direct Charge – This functionality basically supports charges across Operating Units (OU) by implementing the proper Provider/Receiver controls (set Cross Charge Process Method to None)  users can book time and or other charges directly to a project in a different OU than they reside in.  This option would not use Transfer Price rules to process cost/revenue relief.  The AutoAccounting setups would have to be configured to properly account the transactions to support the client’s business rules.  In addition, this option will not support charging across ledgers.

Borrowed and Lent – This functionality works exactly like the standard Direct Charge with the exception that it uses Transfer Price Rules to address cost relief/revenue award for the providing organization.  In addition the Provider/Receiver controls would need to be set to have a Cross Charge Process Method of Borrowed and Lent.  You will have to setup AutoAccounting Functions for Borrowed and Lent processing for this functionality. This option will not support charging across ledgers.

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 as a guide to get you there; think of cross charging in terms of the following matrix, which will provide you with a rule of thumb approach for making your decision.

Cross Charge Option Cross Ledgers? Requires Multiple Projects? Single Project for   Costs/Billing Provides Intercompany   Transactions Requires OU’s as   Suppliers/Customers
Direct Charge N N Y/Y N N
Borrowed & Lent N N Y/Y Y N
Inter-Project Billing Y Y N/Y Y Y
Intercompany Billing Y Y N/N Y Y

Oracle R12 Projects – Contingent Worker Functionality

The Contingent Worker functionality available from Oracle allows you the ability to setup contingent workers as sub-contract employees in the HR system.  Thus, allowing them to enter time in OTL.  The integration with Oracle Projects allows these transactions to be interfaced as labor transactions rather than supplier invoice transactions.  In addition, you may also implement additional AutoAccounting rules to derive further detailed accounting for these transactions.  PO/AP integration allows for the automatic generation of receipts based upon approved timecards and additionally, allows for the automatic creation of supplier invoices.

As far back as Family Pack M for Oracle Projects Contingent Worker functionality has been in place.  And with the current release Oracle has made the functionality more robust, however, there still seems to be quite a number of basic questions as to how the functionality works and that’s what we’ll focus on today.

What are the advantages of implementing the Contingent Worker functionality? – There are several advantages to implementing this functionality

  • Invoice Reconciliation
    • By implementing Electronic Receipt Settlement (ERS) for your contingent worker vendors you can eliminate the tedious effort of reconciling vendor invoices to hours recorded to a project.  With ERS vendor invoices are automatically created based upon the approved timesheets for their contingent workers
  • Project Billing
    • By interfacing the contingent worker transactions as labor transactions to Projects, contingent workers can be billed the same as employees, thus eliminating any issues with converting vendor dollars to labor hours.
  • Project Performance
    • With contingent worker transactions processed as labor you will gain the benefits of being able to track all labor hours on the project against budget.  This will aid in the development of more accurate forecasts.
    • In addition, you will also be able to maintain a historical record of all labor charges for future bids and proposals.

Do we have to implement Accrue on Receipt functionality for the Contingent Worker functionality to work? – In a word, no.  The only thing that needs to be done is to make sure the matching level is set to three-way and the supplier is Pay on Receipt for the purchase order for the services.

What are the options for controlling the transactions and accounting for Contingent Worker transactions? – On the Costing tab of the System Implementation Options form you can select whether or not you want to import Contingent Worker transactions. This option will determine whether or not the costs are viewed in projects as labor transactions or as supplier invoice transactions.  In addition, you can also select whether or not you want to interface the Contingent Worker transactions from Projects to GL.  If this option is checked you will need to take into consideration the fact that the accounting lines from AP will post to GL and you do not want to double post the transactions.  As an example, your accounting from AP would look like the following:

  • DR = Expense
  • CR = AP Liability

While the accounting from Projects for the Contingent Worker labor could look something like this:

  • DR = Job Cost
  • CR = Expense (Same as account above)

Are remaining Purchase Order balances stored as Commitments? – As a matter of fact they are and depending upon your method of importing the costs to projects the commitments are relieved.

What types of adjustments are available in for Contingent Worker transactions?  The standard adjustments in Oracle Projects (Transfers, Splits, etc.) are available to use as with standard labor transactions.  In addition, options can be set in OTL to allow for the timecards to be adjusted even though it has already been approved.

Oracle : Chart of Account : Future Segments : Purpose and Usage

Many organizations ask them selves ‘how do we design our last chart of Accounts to last for the next 50 years’ The fact that it is almost impossible to predict future management and financial reporting over such a long time frame. One approach is too look at pains of the current financial and management reporting system and identify the root cause of the issue. Often times it may be a result of change in business direction that could not be adequately be represented in the chart of Account structure.

For example at one time Banking companies had limited products catering to retail and corporate customers but today you have complex products like derivatives and currency swaps due to globalization. Banks offer various sales channels like “In Branch”, “On Line services”, “Agent driven services” etc.Over time last 15 years, the internet has given rise to completely new channel of selling. A bank today without business channel segment
would have a difficult time determining profitability by channel. This would lead to expensive workarounds or inadequate reporting or both. The issue could have been avoided with some foresight to add a future segment to the structure. If the bank had a future segment, it could have been redefined as a channel or product segment when the need arose. Other examples where a future segment is useful is when a company expands from one product line to multiple product lines. Consider Oracle when it was once a database company. It now boasts several product lines.
The above examples demonstrate that changes in business direction over time are completely unpredictable.  Therefore the leading practice is to define two alphanumeric segments as future segments in your existing chart of accountsThus Future Segments in a chart of account are an insurance policy to be able to provide complete, effective financial reporting information even in the face of major changes in Strategic direction