Cross Charge

This chapter describes accounting within and between operating units and legal entities.

This chapter covers the following topics:

Overview of Cross Charge
Processing Flow for Cross Charge
Processing Borrowed and Lent Accounting
Processing Intercompany Billing Accounting
Adjusting Cross Charge Transactions

Overview of Cross Charge

Enterprises face complex accounting and operational project issues that result from centralized project management through sharing of resources across organizations.

Oracle Projects provides the following cross charge features to address these issues:

Borrowed and Lent Accounting: This feature creates accounting entries to pass costs and revenue across organizations without generating internal invoices.
Intercompany Billing Accounting: This feature creates internal invoices and accounting entries to pass costs and share revenue across organizations.

In addition to these two features that enable you to charge costs across organizations, Oracle Projects inter-project billing features enable you to charge costs between projects. For detailed information on this feature, see Inter-Project Billing, Oracle Project Billing User Guide.

Cross charge features depend on multiple organization support in Oracle Projects and other Oracle Applications. In addition, these features support multinational projects, which also call for other currency exchange management functionality. See: Providing Data Access Across Business Groups, Oracle Projects Fundamentals.

Note: To use the intercompany billing feature (for cross charge) you must implement both Oracle Project Costing and Oracle Project Billing.

Related Topics

Setting Up for Cross Charge Processing: Borrowed and Lent, Oracle Projects Implementation Guide

Setting Up for Cross Charge Processing: Intercompany Billing, Oracle Projects Implementation Guide

Cross Charge Business Needs and Example

When projects share resources within an enterprise, it is common to see those resources shared across organization and country boundaries. Further, project managers may also divide the work into multiple projects for easier execution and management. The legal, statutory, or managerial accounting requirements of such projects often present complex operational control, billing, and accounting challenges.

Oracle Projects enables companies to meet these challenges by providing timely information for effective project management. Project managers can easily view the current total costs of the project, while customers receive bills as costs are incurred, regardless of who performs the work or where it is performed.

Project Structures Example

To provide a better understanding of cross charge concepts and the difference between cross charge and inter-project billing options, the scenarios shown in the following example illustrate how projects can be structured.

Note: The project in this example is a contract project and is used for illustrative purposes only. You can apply most of the features described in this document to other types of projects.

The following illustration shows Company ABC, an advertising company with the following organization structure:

Company ABC has two ledgers: US and Japan.
The legal entity US is assigned to the US ledger and the legal entity Japan is assigned to the Japanese ledger.
The legal entity US is comprised of three operating units: Los Angeles, San Francisco and New York
The legal entity Japan is comprised of the Tokyo operating unit.
The legal entity US and the Japanese ledger belong to the business group BGI.

Organization Structure of Company ABC

the picture is described in the document text

The Los Angeles operating unit, ABC's headquarters, receives a contract from a customer in the United Kingdom (UK). The customer wants ABC to produce and air live shows in San Francisco, New York, and Tokyo to launch its new line of high-end women's apparel. The customer wants to be billed in British Pounds (GBP). ABC calls this project Project X and will track it using Oracle Projects. ABC will plan and design the show using resources from the Los Angeles operating unit. Employee EMPJP from its Japan subsidiary will act as an internal consultant to add special features to suit the Japanese market. The San Francisco, New York, and Tokyo operating units are each responsible for the successful execution of these live shows with their local resources.

Based on this scenario, each operating unit can incur costs against Project X. Consider the following labor transaction, which is summarized in the table that follows.

Employee EMPJP of Japan worked 10 hours meeting with the customer in Japan to learn about the new product.
Employee EMPJP's cost rate is 5,000 JPY per hour.
Employee EMPJP's standard bill rate is USD 400 per hour.
Employee EMPJP's internal bill rate, if applicable, is USD 200 per hour, or 50% of the standard bill rate.

Note: Currency conversion rates: 1 USD = 100 JPY; 1 USD = .75 GBP

Sample Transaction (10 hours of labor)	Transaction Currency Amounts	Functional Currency Amounts	Project Currency Amounts
Cost	50,000 JPY	50,000 JPY	500 USD
Revenue	4,000 USD	4,000 USD	4,000 USD
Invoice	3,000 GBP	4,000 USD	4,000 USD
Internal Billing Revenue	2,000 USD	200,000 JPY

Project Structure: Distinct Projects by Provider Organization

The illustration Distinct Projects By Provider Organization shows the following structure:

Company ABC divides Project X into four distinct contract projects: Project X-1, Project X-2, Project X-3 and Project X-4.
Each operating unit owns its respective project (Los Angeles owns X-1, San Francisco owns X-2, New York owns X-3, and Tokyo owns X-4) and bills the project customer directly.

Distinct Projects by Provider Organization

Requirements:

Oracle Project Costing
Oracle Project Billing

Advantages: Simplicity, since the operating units create and process their projects independently.

Disadvantages: The company must divide the project work properly, and each resulting project requires an agreement, funding, and a budget to generate customer invoices. In addition, the customer may not want to receive separate invoices from different organizations in your enterprise. Communication and control across the projects for collective status can be difficult.

Project Structure: Single Project

The following illustration shows a structure where the Los Angeles operating unit (the project owner, or receiver organization) centrally manages Project X. All four operating units (the provider organizations) incur project costs and charge them directly to Project X.

Single Project

the picture is described in the document text

Requirements:

Oracle Project Costing
Oracle Project Billing
Implementation of the cross charge feature
Depending on the method you choose to process cross charge transactions (borrowed and lent accounting or intercompany billing accounting), this solution may also require intercompany billing for the automatic creation of internal invoices.

Advantages: Simple project creation and maintenance, since this solution requires a single project. All of the expenditures against ProjectX, cross charged or not, are available for external customer billing and project tracking via Project Status Inquiry. The customer receives timely, consolidated invoices from Los Angeles for all the work performed regardless of which operating unit provides the resources.

Disadvantages: Requires additional initial overhead for implementing the cross charge feature and creating intercompany billing projects to collect cross charge transactions within each provider organization.

Project Structure: Primary Project with Subcontracted Projects

The following illustration shows how Company ABC divides Project X into several related contract projects. The Los Angeles operating unit owns the primary customer project, or receiver project, and bills the external customer. The related projects, or provider projects, are subcontracted to their respective internal organizations and internally bill the Los Angeles organization to recoup their project costs.

Primary Project with Subcontracted Projects

the picture is described in the document text

Requirements:

Oracle Project Costing
Oracle Project Billing
Implementation of inter-project billing features

Advantages: Flexibility in managing the provider projects. Each provider project is treated and processed the same way as any external customer contract project.

Disadvantages: As with the distinct project structure, this solution requires additional overhead in creating and managing three additional provider projects. The receiver project's status and external customer invoicing depend upon timely completion of the internal billing from all provider projects.

Cross Charge Types

Oracle Projects provides three types of cross charge transactions as shown in the following table. A transaction's cross charge type depends on whether the provider operating unit, organization, and legal entity are different from those of the receiver.

Cross Charge Type	Conditions
Intercompany	Operating units and legal entities are different
Inter-operating unit	Operating units are different, but legal entities are the same
Intra-operating unit	Operating units and legal entities are the same, but the organizations are different

Note: You can charge intercompany cross charge transactions only to indirect and contract projects. You cannot charge intercompany cross charge transactions to capital projects.

Note: You cannot change the provider or receiver operating unit, but you can use the Provider and Receiver Organizations Override client extension to override the default provider organization and receiver organization. For more information on this client extension, see: Oracle Projects APIs, Client Extensions, and Open Interfaces Reference.

The following illustration shows the potential cross charge type relationships for the four organizations shown in the illustration Organization Structure of Company ABC when they charge costs to Project X in the Los Angeles operating unit.

Potential Cross Charge Types for Company ABC

the picture is described in the document text

The following table summarizes the characteristics of the potential cross charge type relationships shown in the illustration Potential Cross Charge Types for Company ABC.

Cost Transactions from the following Provider Operating Units	Expenditure Organization Equals Project Organization	Same Legal Entity	Same Business Group	Cross-Charge Type Relationship
Los Angeles	Yes	Yes	Yes	Non Cross-Charged Transactions
Los Angeles	No	Yes	Yes	Intra-Operating Unit Transactions
San Francisco	No	Yes	Yes	Inter-Operating Unit Transactions
New York	No	Yes	Yes	Inter-Operating Unit Transactions
Tokyo	No	No	Yes	Inter-Company Transactions

Cross Charge Processing Methods and Controls

This section describes cross charge processing methods and processing control options.

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)

Borrowed and Lent Accounting

When you use this method, Oracle Projects creates accounting entries to pass costs and revenue across organizations without generating internal invoices. Oracle Projects determines the appropriate cost or revenue amounts based on the transfer price rules of the provider and receiver organizations.

Borrowed and lent accounting entries provide a financial view of an organization's performance. This processing method is generally used to measure organizational financial performance for management reporting purposes. For more information, see: Processing Borrowed and Lent Accounting.

Intercompany Billing Accounting

Companies choose the intercompany billing method largely due to legal and statutory requirements. When you use this method, Oracle Projects generates physical invoices and corresponding accounting entries at legal transfer prices between the internal seller (provider) and buyer (receiver) organizations when they cross a legal entity boundary or operating units. For more information, see: Processing Intercompany Billing Accounting.

No Cross Charge Process

Companies generally process cross charges in Oracle Projects using the borrowed and lent or intercompany billing method. However, companies may not need to process cross charge transactions, if, for example, intercompany billing has been performed manually in General Ledger or automatically by an external system. You can use cross charge controls to identify which cross charge transactions will undergo cross charge processing. See: Cross Charge Controls.

Cross Charge Controls

Cross charge controls specify:

Which projects and tasks in which operating units can receive transactions from a provider operating unit
How Oracle Projects processes these cross charged transactions

Cross-charge controls affect all cross charge transactions, regardless of how you enter them. For maximum control, you can use a combination of cross charge and transaction controls to ensure that only valid cross charges are charged to a specific project and task.

Cross charge controls are defined at the operating unit, project, and task levels. Oracle Projects applies these controls based on a transaction's cross charge type and cross charge processing method.

Intra-Operating Unit Cross Charge Controls

You can charge intra-operating unit cross charges (that is, charges within an operating unit) to any project and task owned by your expenditure operating unit. You can modify the transaction control extension to restrict intra-operating unit cross charge transactions.

Inter-Operating Unit Cross Charge Controls

Oracle Projects provides controls to identify:

Which projects and tasks in a receiver operating unit can receive inter-operating unit cross charges from a provider operating unit
Which cross charge processing method to apply to these transactions.

Steps performed by the provider operating unit:

Define cross charge implementation options: Specify whether to allow cross charge and select a default processing method.
Define internal billing implementation options: Specify whether the operating unit is a provider for internal billing.
Define provider controls: Select a processing method and specify the name of the intercompany billing project.

Steps performed by the receiver operating unit:

Define internal billing implementation options: Specify whether the operating unit is a receiver for internal billing.
Define receiver controls: Specify the name of each provider operating unit that can charge transactions to the specified receiver operating unit.
Enable cross charge for projects: In the Projects window (Cross Charge option), select Allow Charges from other Operating Units.

Intercompany Cross Charge Controls

Oracle Projects provides flexible controls to identify:

Which projects and tasks in a receiver operating unit can receive intercompany cross charges from a provider operating unit
Which cross charge processing method to apply to these transactions.

Note: You can charge intercompany cross charge transactions only to indirect and contract projects. You cannot charge intercompany cross charge transactions to capital projects.

Steps performed by the provider operating unit

Define internal billing implementation options: Specify whether the operating unit is a provider for internal billing.
Define provider controls: Specify the name of each receiver operating unit that can receive transactions from the specified provider operating unit. Also, select a processing method and specify the name of the intercompany billing project.

Steps performed by the receiver operating unit

Define internal billing implementation options: Specify whether the operating unit is a receiver for internal billing.
Define receiver controls: Specify the name of each provider operating unit that can charge transactions to the specified receiver operating unit.
Enable cross charge for projects: In the Projects window (Cross Charge option), select Allow Charges from other Operating Units.

Note: If Cross Business Group Access is enabled, the provider and receiver operating units can be in different business groups. See: Oracle HRMS Configuring, Reporting, and System Administration Guide.

Cross Charge Processing Controls

Cross charge processing controls determine which cross charge method and transfer price rule should be applied to the cross charged transaction. This section describes the cross charge process controls.

Implementation Options

For each provider operating unit or receiver operating unit involved in the cross charge, the Implementation Options window Cross Charge and Internal Billing tabs specify:

The default transfer price conversion attributes
The default cross charge methods for intra-operating unit and inter-operating unit cross charges
Attributes required as the provider of internal billing
Attributes required as the receiver of internal billing

See: Define Cross Charge Implementation Options, and Defining Internal Billing Options in the Oracle Projects Implementation Guide.

Provider and Receiver Controls Setup

For each provider operating unit or receiver operating unit involved in the cross charge, the Provider/Receiver Controls window Provider Controls and Receiver Controls tabs specify:

The cross charge method to use to process intercompany cross charges and to override default cross charge method for inter-operating unit cross charges.
Attributes required for the provider operating unit to process intercompany billing to each receiver operating unit. This includes the Intercompany Billing Project and Invoice Group.
Attributes required for the receiver operating unit to process intercompany billing from each provider operating unit. This includes the supplier site, expenditure type and expenditure organization.

See: Defining Provider and Receiver Controls, Oracle Projects Implementation Guide.

Transfer Price Rules and Schedule Setup

Transfer price rules control the calculation of transfer prices for labor and non-labor cross charged transactions. To drive transfer price calculation for cross charge transactions between the provider and receiver, use the Transfer Price Schedule window to assign labor or non-labor (or both) transfer price rules to the provider and receiver pair on a schedule line. See: Transfer Pricing.

Multiple lines in a transfer price schedule could potentially apply to a cross charged transaction.

Oracle Projects performs the following steps to identify the appropriate schedule line:

If a schedule line exists for the transaction expenditure organization (provider) and the project/task owning organization (receiver), then the corresponding rule is used to calculate the transfer price.
If a schedule line is not located, Oracle Projects checks for a line with the provider organization and a receiver parent organization that is included in the expenditure/event organization hierarchy associated with the operating unit on the Expenditures/Costing tab of the Implementation Options form. When searching for receiver organization parents, the Project/Task Owning Organization Hierarchy defined in the Implementation Options of the receiver operating unit is used.
If the receiver organization has multiple intermediate parents and schedule lines are defined for more than one of the parents, the schedule line defined for the lowest level parent takes precedence over schedule lines defined for parents higher in the organization hierarchy.
If a schedule line is not located, Oracle Projects checks for a line with a provider parent organization and the receiver parent organization. When searching for provider organization parents, the Expenditure/Event Organization Hierarchy defined in the Implementation Options of the provider operating unit is used.
If the provider organization has multiple intermediate parents and schedule lines are defined for more than one of the parents, the schedule line defined for the lowest level parent takes precedence over schedule lines defined for parents higher in the organization hierarchy.
If there is a schedule line with only the provider organization, and another schedule line with both provider and receiver organizations, the schedule line with both the provider and receiver organizations takes precedence.
If there is a schedule line with only provider organization, and another schedule line with the provider organization and the receiver parent organization, then the schedule line with the provider organization and the receiver parent organization takes precedence.

Project and Task Setup

For each project or task, you can decide whether to process labor and non-labor cross charge transactions, and which transfer price schedules are used for transfer price calculation. See: Cross Charge, Oracle Projects Fundamentals.

Transaction Source Setup

To cause the cross charge processes to skip a transaction source, deselect the Process Cross Charge option in the Transaction Sources window. See: Transaction Sources, Oracle Projects Implementation Guide.

Expenditure Item Adjustments

You can mark an expenditure item to be skipped by the cross charge processes by choosing Mark for No Cross Charge Processing from the Tools menu on the Expenditure Items window.

Client Extensions

Oracle Projects provides following client extensions that you can use to implement your business rules to control cross charge processing:

Provider and Receiver Organizations Override Extension
Cross Charge Processing Method Override Extension
Transfer Price Determination Extension
Transfer Price Override Extension
Transfer Price Currency Conversion Override Extension

For more information, see: Oracle Projects APIs, Client Extensions, and Open Interfaces Reference.

Related Topics

Oracle Financials Implementation Guide

Oracle HRMS Implementation Guide

Transfer Pricing

Legal transfer price refers to the legally accepted billing prices for internal sales. In Oracle Projects, transfer price refers to the billing price that two organizations agree upon for cross charge purposes.

Transfer Price Rules

You can define transfer price rules that determine the transfer price amount of cross charge transactions that require borrowed and lent or intercompany billing processing. Oracle Projects provides flexible transfer pricing rules for transfer price calculations. The calculations are based on the:

Transfer price basis. Base your transfer price on a cross charged transaction's raw cost, burdened cost, or revenue.
Cross-charge calculation method. You can optionally perform an additional calculation and apply a markup or discount to the amount determined by the transfer price basis. For the additional calculations, you can apply any burden schedule or standard bill rate schedule in your business group.

Note: Using a standard bill rate schedule allows you to define the schedule in a single operating unit and enforce it across all operating units in your business group.

You can configure transfer price amounts to be calculated based on revenue amounts for cross-charged transactions independent of revenue generation. Oracle Projects determines the revenue of the receiver project as part of transfer price calculation. You do not have to generate the revenue in the receiver operating unit. In addition, the cost transaction does not have to be billable. You can use the potential revenue amount as a basis and apply a transfer price markup percentage even when the cost transaction is not billable from the perspective of the receiver project.

Oracle Projects automatically converts transfer price amounts to the functional currency of the provider operating unit using the transfer price currency conversion attributes defined in that operating unit. You can use the Transfer Price Currency Conversion Override Extension to adjust these conversion attributes. For more information, see: Oracle Projects APIs, Client Extensions, and Open Interfaces Reference.

Transfer Price Schedules

Once you define your transfer price rules, you create a transfer price schedule to associate these rules to pairs of provider and receiver organizations. In the simplest transfer price schedule, an enterprise would have a single transfer price rule that every organization follows. Oracle Projects supports more complex schedules so your organizations can negotiate their own transfer price rules. You can also define a schedule with one rule that applies to cross charges to a particular organization and another rule for cross charges to all other organizations. You can define one transfer price schedule consisting of different rules for different organization pairs or multiple schedules consisting of different rules for the same pair of organizations.

You can assign labor and non-labor transfer price schedules to both a project and its tasks. If you assign a transfer price schedule to a lowest-level task, then Oracle Projects uses that transfer price schedule to process labor or non-labor cross-charged transactions for that task. If you do not assign a transfer price schedule at the lowest task level, then Oracle Projects uses the transfer price schedule that you assign at the project-level.

Related Topics

Cross Charge, Oracle Projects Fundamentals

Defining Transfer Price Rules, Oracle Projects Implementation Guide

Defining Transfer Price Schedules, Oracle Projects Implementation Guide

Processing Flow for Cross Charge

This section describes the processing flow for cross charge transactions.

The following illustration shows the processing flows for cross charge transactions that require either borrowed and lent or intercompany billing processing. For a description of these flows, see: Borrowed and Lent Processing Flow, and Intercompany Billing Processing Flow.

Overview of Cross Charge Processing Flow

the picture is described in the document text

Related Topics

Creating Cross Charge Transactions

Borrowed and Lent Processing Flow

Borrowed and lent processing requires the following steps:

The provider operating unit enters or imports cross charge transactions.
The provider operating unit distributes the costs of the cross charges, which are identified as cross charge transactions by the cost distribution processes. The cross charge distribution process is independent of revenue generation. The process distributes the costs even if revenue has not been generated.

The provider operating unit also imports project-related supplier costs from Oracle Purchasing and Oracle Payables, and project-related expense report costs from Oracle Payables.
The provider operating unit runs the process PRC: Distribute Borrowed and Lent Amounts to determine the transfer price amount and generate the borrowed and lent accounting entries.
The provider operating unit runs the process PRC: Generate Cross Charge Accounting Events.
The provider operating unit runs the process PRC: Create Accounting to create accounting entries for the cross charge accounting events in Oracle Subledger Accounting. When you run the process in final mode, you can optionally choose to transfer the accounting to Oracle General Ledger. If you select this option, the create accounting process initiates Journal Import in Oracle General Ledger.
(Optional) You can require the receiver operating unit to run additional customized processes to create additional accounting entries in Oracle Subledger Accounting and transfer the accounting entries to Oracle General Ledger. For example, your implementation team can develop customized processes to handle organizational profit elimination to satisfy your company's accounting practices.
(Optional) The provider operating unit may adjust cross charge transactions or perform steps resulting in the reprocessing of borrowed and lent transactions. See: Adjusting Cross Charge Transactions.

Intercompany Billing Processing Flow

Intercompany billing processing requires the following steps:

The provider operating unit enters or imports cross charge transactions.
The provider operating unit distributes costs of the cross charges, which are identified as cross charge transactions by the cost distribution processes. The distribution of the costs is independent of revenue generation and are distributed even if revenue has not been generated.

The provider operating unit also imports project-related supplier costs from Oracle Purchasing and Oracle Payables and project-related expense report costs from Oracle Payables.
The provider operating unit runs the process PRC: Generate Intercompany Invoices for a Single Project, or the process PRC: Generate Intercompany Invoices for a Range of Projects, to generate draft intercompany invoices with the associated intercompany receivable and revenue accounts, and the transfer price.
The provider operating unit reviews, approves, and releases the intercompany invoices.
The provider operating unit interfaces the approved intercompany invoices to Oracle Receivables. You can include the following activities in this process:
- Accounting for invoice rounding
- Creation of receivable invoices including sales tax
The provider operating unit runs the process PRC: Tieback Invoices from Receivables, which automatically creates corresponding intercompany invoice supplier invoices ready to be interfaced to Oracle Payables in the receiver operating unit.

Use Oracle Receivables to print the invoice as well as to create accounting for Oracle Subledger Accounting.
If cost reclassification is enabled, the provider operating unit performs the following processing steps:
1. Runs the process PRC: Generate Cross Charge Accounting Events to generate accounting events for the provider cost reclassifications.
2. Runs the process PRC: Create Accounting to create accounting entries for the provider cost reclassification accounting events in Oracle Subledger Accounting. When you run the process in final mode, you can optionally choose to transfer the accounting to Oracle General Ledger. If you select this option, the create accounting process initiates Journal Import in Oracle General Ledger.
The receiver operating unit imports the intercompany supplier invoices into Oracle Payables. This import process calculates recoverable and non-recoverable tax amounts. Upon review and approval in Oracle Payables, the receiver operating unit runs the process Create Accounting to create subledger accounting entries for the supplier invoices in Oracle Subledger Accounting. When you run the process in final mode, you can optionally choose to transfer the accounting to Oracle General Ledger.
The receiver operating unit interfaces the supplier invoice to Oracle Projects, which pulls in the non-recoverable tax amounts as additional project costs.
(Optional) You can require the receiver operating unit to run additional customized processes to create additional accounting entries in Oracle Subledger Accounting and transfer the accounting entries to Oracle General Ledger. For example, your implementation team can develop customized processes to handle organizational profit elimination to satisfy your company's accounting practices.
(Optional) The provider operating unit can adjust cross charge transactions or perform steps resulting in the reprocessing of intercompany transactions. See Adjusting Cross Charge Transactions.

Creating Cross Charge Transactions

To create cross charge transactions, you enter expenditures and distribute costs.

Enter Expenditures

Enter or import the cross charge transactions as you would for any project transactions. Oracle Projects enforces cross charge controls and transaction controls to ensure that you charge valid transactions to a project or task. See Cross Charge Controls.

Distributing Costs

In addition to determining the raw and burden cost amounts and the accounting information for project transactions, the cost distribution processes also determine the following information for cross charge transactions:

Provider and receiver operating units and organizations
Cross-charge type indicates if a transaction is an intra-operating unit, inter-operating unit, or intercompany cross charged transaction or not a cross charged transaction
Cross-charge processing method, which indicates whether a transaction is subject to cross charge processing and which processing method to use

Determining the cross charge type

Oracle Projects determines a transaction's cross charge type as follows:

Default provider organization is the expenditure or non-labor resource organization
Receiver organization defaults to the task organization
Call the Provider and Receiver Organizations Override extension to determine whether to override these values

Cross charge type is based on the values above and logic in the following table:

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

Determining the cross charge processing method

A transaction can have one of the following cross charge processing methods:

Borrowed and lent accounting
Intercompany billing
No cross charge processing

Oracle Projects determines the cross charge processing method for a transaction, based on how you have implemented the following items:

Transaction source options.If you enable the option Process Cross Charge for the transactions source, Oracle Projects performs cross charge processing for transactions originating from that transaction source.
Project attributes for processing labor and non-labor cross charge transactions. If you do not enable cross charge processing for cross charge labor transactions at the project level, no labor transactions for that project will be subject to cross charge processing. The same applies to non-labor transactions.
Cross-charge options for provider operating unit
- Intra-operating unit transactions. Implementation options determine processing method.
- Inter-operating unit transactions. If you have enabled users to charge to all operating units within the legal entity, the implementation options determine the default processing method.
Provider and receiver controls
Cross Charge Processing Method Override extension

Related Topics

Defining Legal Entities Using the Legal Entity Configurator, Oracle Financials Implementation Guide

Oracle HRMS Implementation Guide

Processing Borrowed and Lent Accounting

The borrowed and lent processing method creates accounting entries to pass costs or share revenue (cost and revenue amounts are determined by the transfer price amount) between the provider and receiver organizations within a legal entity.

If costs are being passed from the provider to the receiver, this processing method:

Debits the cost from the receiver (or lent) organization
Credits the cost account of the provider (or borrowed) organization

Similarly, if revenue is being shared, this method:

Debits the revenue from the receiver organization
Credits the revenue to the provider organization

You can view these accounting entries in the corresponding ledgers.

Oracle Projects provides AutoAccounting functions for borrowed and lent processing.

If you define your own detailed accounting rules in Oracle Subledger Accounting, then Oracle Subledger Accounting overwrites default accounts, or individual segments of accounts, that Oracle Projects derives using AutoAccounting. See: Accounting for Costs, Oracle Projects Implementation Guide.

Determining Accounts for Borrowed and Lent Transactions

An inter-operating unit cross charge transaction against a contract project results in the borrowed and lent accounting entries shown in the following two tables.

The following table show the entries generated for the provider operating unit.

Process	Accounting	Debit (Dr) Credit (Cr)	Transaction Currency	Functional Currency
Cost	Labor Expense	Dr	500 USD	500 USD
	Labor Clearing	Cr	500 USD	500 USD
Borrowed and Lent	Lent	Dr	2,000 USD	2,000 USD
	Borrowed	Cr	2,000 USD	2,000 USD

The following table show the entries generated for the receiver operating unit

Process	Accounting	Debit (Dr) Credit (Cr)	Transaction Currency	Functional Currency
Client Revenue	UBR/UER	Dr	4,000 USD	4,000 USD
	Revenue	Cr	4,000 USD	4,000 USD
Client Invoice	Accounts Receivable	Dr	3,000 GBP	4,000 USD
	UBR/UER	Cr	3,000 GBP	4,000 USD

An intra-operating unit cross charge transaction against a contract project results in the borrowed and lent accounting entries shown in the following table for the receiver operating unit.

Process	Accounting	Debit (Dr) Credit (Cr)	Transaction Currency	Functional Currency
Cost	Labor Expense	Dr	500 USD	500 USD
	Labor Clearing	Cr	500 USD	500 USD
Borrowed and Lent	Lent	Dr	2,000 USD	2,000 USD
	Borrowed	Cr	2,000 USD	2,000 USD
Client Revenue	UBR/UER	Dr	4,000 USD	4,000 USD
	Revenue	Cr	4,000 USD	4,000 USD
Client Invoice	Accounts Receivable	Dr	3,000 GBP	4,000 USD
	UBR/UER	Cr	3,000 GBP	4,000 USD

Note: Oracle Subledger Accounting uses intracompany balancing rules to create balancing lines on journal entries between balancing segment values. You set up this functionality in the Accounting Setup Manager in Oracle General Ledger.

Generating Accounting Transactions for Borrowed and Lent Accounting

Running the standard cost distribution processes in the provider operating unit identifies which transactions require borrowed and lent processing. Oracle Projects provides a separate process, PRC: Distribute Borrowed and Lent Amounts, to compute the transfer price of these transactions and determine the default GL accounts for borrowed and lent accounting entries.

The provider operating unit runs this process to perform the following steps on cross charge transactions identified for borrowed and lent processing:

Calculate the Transfer Price Amount

Distribute Borrowed and Lent Amounts calculates the transfer price amount of a given cross charge transaction, as follows:

Note: If the process cannot determine a transfer price for the cross charge transaction, Oracle Projects flags the transaction with an error and proceeds to the next item. The transfer price is stored in the transaction and ledger currencies.

Call the Transfer Price Determination extension.

Oracle Projects calls the Transfer Price Determination extension at the beginning of the process in case you want to bypass the standard transfer price calculation for certain borrowed and lent transactions. If you implement this extension, Oracle Projects calculates the transfer price amount based on the extension logic and generates borrowed and lent accounting entries based on this amount. See: Transfer Price Determination Extension, Oracle Projects APIs, Client Extensions, and Open Interfaces Reference.
Identify the applicable transfer price schedule.

Oracle Projects identifies the labor or non-labor transfer price schedule that you specified for the lowest-level task to which you charged the transaction. If you do not assign a transfer price schedule at the lowest task level, then Oracle Projects uses the transfer price schedule that you assign at the project-level.

Note: You can define transfer price overrides at the assignment level. For additional information, see: Project Assignments, Oracle Projects Fundamentals and Defining Work Types, Oracle Projects Implementation Guide.
Identify the applicable transfer price schedule line.

If the transfer price schedule identified by the Distribute Borrowed and Lent Amounts process contains more than one line, Oracle Projects must determine which line to apply. Oracle Projects first selects all schedule lines whose effective dates contain the Expenditure Item Date of the cross charge transaction. Oracle Projects then selects the appropriate line based on the provider and receiver organization, operating unit, legal entity, or business group.
Calculate the transfer price amount.

The process then calculates the transfer price amount by applying the transfer price rule and any additional percentage you have specified in the schedule line.

The actual transfer price calculation is carried out like this:
- Determine the transfer price basis (raw cost, burdened cost, or revenue) identified in the transfer price rule.
  
  Note: If you use cost amounts as your transfer price basis, Oracle Projects verifies that you have performed the appropriate cost distribution programs. If you have not run the prerequisite programs, then Oracle Projects marks the transaction with an error.
- Apply a burden schedule or standard bill rate schedule to the basis, as indicated in the transfer price rule. If the process identifies a rate in the specified bill rate schedule, it applies the rate to the quantity of the transaction.
- Apply any additional percentage specified in the rule.
- Apply any additional percentage specified for labor or non-labor transactions in the schedule line.
Call the Transfer Price Override extension.

You can use this extension to override the transfer price amount calculated by the Distribute Borrowed and Lent Amounts process. See: Transfer Price Override Extension, Oracle Projects APIs, Client Extensions, and Open Interfaces Reference.
Perform required currency conversions.

If the functional currency is different from the transfer price basis currency, the process performs the required currency conversion to generate functional currency amounts. The conversion uses the currency conversion attributes that are defined in the provider operating unit's cross charge implementation options. You can override these attributes using the Transfer Price Currency Conversion Override extension.
Call the Transfer Price Currency Conversion Override extension.

You can use this extension to override the default transfer price currency conversion attributes defined in the cross charge implementation options. See: Transfer Price Currency Conversion Override Extension, Oracle Projects APIs, Client Extensions, and Open Interfaces Reference.

Run AutoAccounting

After the Distribute Borrowed and Lent Amounts process calculates the transfer price amounts for each selected borrowed and lent transaction, it runs AutoAccounting to determine the default account code for each distribution line that it will create. Oracle Projects provides the functions Borrowed Account and Lent Account for borrowed and lent transactions.

Oracle Subledger Accounting uses intracompany balancing rules to create balancing lines on journal entries between balancing segment values. You set up this functionality in the Accounting Setup Manager in Oracle General Ledger. You must also enable the Balance Cross-Entity Journal flag in the ledger definition to enable the application of the balancing rules. You must also set up the accounts to ensure that Oracle Subledger Accounting generates the balancing journal entries.

Create Cross Charge Distribution Lines

After the Distribute Borrowed and Lent Amounts process runs AutoAccounting, it creates cross charge distribution lines. Next, you generate cross charge accounting events for the cross charge distribution lines and create accounting for the accounting events in Oracle Subledger Accounting.

The PA date for the distribution lines is determined based on the ending date of the earliest open PA period on or after the expenditure item date.

You can use the View Accounting window to view cross charge distributions for a specific item. (To do so, query an invoice transaction in the Expenditure Items window and choose View Accounting from the Tools menu. See: Viewing Accounting Lines.) The following transaction attributes support cross charge distributions:

Provider organization and operating unit
Receiver organization and operating unit
Cross charge processing method and type

Note: Before you can view the accounting entries, you must create subledger accounting entries for the accounting events associated with the cross charge distribution lines.

Related Topics

Accounting for Costs, Oracle Projects Implementation Guide

Oracle Financials Implementation Guide

Processing Intercompany Billing Accounting

This section covers the following topics:

Determining Accounts for Intercompany Billing Accounting

Intercompany billing accounting entries are based on documents generated by the provider and receiver organizations. The provider and receiver organizations can be in the same ledger or in different ledgers with different charts of accounts. If Cross Business Group Access is enabled, the provider and receiver organizations can also be in different business groups. You can view intercompany billing accounting entries in the corresponding ledgers. As this processing method may require input from multiple organizations and employees in your organization, you should establish clear user procedures to ensure the successful completion of the entire process flow. Failure to follow these procedures can result in out of balance intercompany accounts.

Determining Accounts for Intercompany Receivables Invoices

Oracle Projects provides two AutoAccounting functions to determine the default revenue and invoice accounts of a provider operating unit's intercompany Receivables invoice. See: AutoAccounting Functions, Oracle Projects Implementation Guide.

Intercompany Revenue. This function determines the default account that receives the credit entry of an intercompany billing Receivables invoice.
Intercompany Invoice Accounts. This function includes the function transactions Intercompany Receivables and Intercompany Rounding.
- Intercompany Receivables determines the default account that receives default debit entry of an intercompany billing Receivables invoice.
- Intercompany Rounding determines the default accounts for the pair of debit and credit entries due to intercompany billing invoice currency rounding.

Determining Accounts for Intercompany Payables Invoices

You can modify the Supplier Invoice Charge Account Workflow process to determine the default accounting entries for a receiver operating unit's intercompany Payables invoice. The process usually debits an internal cost or construction-in-process account and credits the intercompany payables account in the receiver operating unit. See Workflow: Project Supplier Invoice Account Generation, Oracle Projects Implementation Guide.

Intercompany Billing Accounting Examples

An intercompany cross charge transaction against an indirect project results in the intercompany billing accounting entries shown in the following two tables.

The following table shows entries for the provider operating unit.

Process	Accounting	Debit (Dr) Credit (Cr)	Transaction Currency	Functional Currency
Cost	Labor Expense	Dr	50,000 JPY	50,000 JPY
	Labor Clearing	Cr	50,000 JPY	50,000 JPY
Intercompany Accounts Receivable -Invoice	Intercompany Accounts Receivable	Dr	200,000 JPY	200,000 JPY
	Intercompany Revenue	Cr	200,000 JPY	200,000 JPY

The following table shows entries for the receiver operating unit.

Process	Accounting	Debit (Dr) Credit (Cr)	Transaction Currency	Functional Currency
Intercompany Accounts Payable -Invoice	Intercompany Cost	Dr	200,000 JPY	2,000 USD
	Intercompany Accounts Payable	Cr	200,000 JPY	2,000 USD

An intercompany cross charge transaction against a contract project results in the intercompany billing accounting entries shown in the following two tables.

The following table shows entries for the provider operating unit.

Process	Accounting	Debit (Dr) Credit (Cr)	Transaction Currency	Functional Currency
Cost	Labor Expense	Dr	50,000 JPY	50,000 JPY
	Labor Clearing	Cr	50,000 JPY	50,000 JPY
Intercompany Accounts Receivable -Invoice	Intercompany Accounts Receivable	Dr	200,000 JPY	200,000 JPY
	Intercompany Revenue	Cr	200,000 JPY	200,000 JPY

The following table shows entries for the receiver operating unit

Process	Accounting	Debit (Dr) Credit (Cr)	Transaction Currency	Functional Currency
Intercompany Accounts Payable -Invoice	Intercompany Cost	Dr	200,000 JPY	2,000 USD
	Intercompany Accounts Payable	Cr	200,000 JPY	2,000 USD
Client Revenue	UBR/UER	Dr	4,000 USD	4,000 USD
	Revenue	Cr	4,000 USD	4,000 USD
Client Invoice	Accounts Receivable	Dr	4,000 USD	4,000 USD
	UBR/UER	Cr	4,000 USD	4,000 USD

Determining Accounts for Provider Cost Reclassification

Oracle Projects provides a pair of debit and credit AutoAccounting functions to support the reclassification of cost in the provider operating unit upon generating intercompany invoices. For example, a provider operating unit may need to reclassify project construction-in-process costs against a contract project using cost accrual as intercompany costs upon billing the receiver operating unit. Oracle Projects provides the following AutoAccounting functions for this purpose:

Provider Cost Reclass Dr. This function determines the default account that receives the debit entry of the cost reclassification.
Provider Cost Reclass Cr. This function determines the default account that receives the credit entry of the cost reclassification.

A provider cost reclassification results in the intercompany billing accounting entries shown in the following two tables.

The following table shows entries for the provider operating unit.

Process	Accounting	Debit (Dr) Credit (Cr)	Transaction Currency	Functional Currency
Cost	Construction - In - Process	Dr	50,000 JPY	50,000 JPY
	Labor Clearing	Cr	50,000 JPY	50,000 JPY
Provider Cost Reclassification	Labor Expense	Dr	50,000 JPY	50,000 JPY
	Construction - In - Process	Cr	50,000 JPY	50,000 JPY
Intercompany Accounts Receivable -Invoice	Intercompany Accounts Receivable	Dr	200,000 JPY	200,000 JPY
	Intercompany Revenue	Cr	200,000 JPY	200,000 JPY

The following table shows entries for the receiver operating unit.

Process	Accounting	Debit (Dr) Credit (Cr)	Transaction Currency	Functional Currency
Intercompany Accounts Payable -Invoice	Intercompany Construction - In - Process	Dr	200,000 JPY	2,000 USD
	Intercompany Accounts Payable	Cr	200,000 JPY	2,000 USD
Client Revenue	UBR/UER	Dr	4,000 USD	4,000 USD
	Revenue	Cr	4,000 USD	4,000 USD
Cost Accrual	Cost Accrual	Dr	500 USD	500 USD
	Construction - In - Process Contra	Cr	500 USD	500 USD
Client Invoice	Accounts Receivable	Dr	3,000 GBP	4,000 USD
	UBR/UER	Cr	3,000 GBP	4,000 USD
Close Project	Cost Accrual	Dr/Cr (see note)	1,500 USD	1,500 USD
	Intercompany Construction - In - Process	Cr	1,500 USD	1,500 USD

Note: The examples in the previous two tables show that the provider operating unit originally posted a cross charge transaction to a construction-in-process account during the cost distribution process. The intercompany billing process then transfers the construction-in-process amount with a markup to the receiver operating unit.

After you run the process PRC: Tieback Invoices from Receivables, you run the process PRC: Generate Cross Charge Accounting Events to generate accounting events for the provider cost reclassification journal entries. Next, you run the process PRC: Create Accounting to create accounting entries for the provider cost reclassification accounting events in Oracle Subledger Accounting. When you run the process in final mode, you can optionally choose to transfer the accounting to Oracle General Ledger. If you select this option, the create accounting process initiates Journal Import in Oracle General Ledger.

Generating Intercompany Invoices

Running the standard cost distribution processes in the provider operating unit identifies which transactions require intercompany billing processing. Oracle Projects provides separate processes to compute the transfer price of the intercompany billing transactions and generate draft intercompany invoices and (optionally) provider cost reclassification entries.

To use the intercompany billing processing method, you must perform several setup steps, including creating an intercompany billing project. See: Setting Up for Cross Charge Processing: Intercompany Billing, Oracle Projects Implementation Guide.

The Generate Intercompany Invoice processes (The PRC: Generate Intercompany Invoices for a Single Project and PRC: Generate Intercompany Invoices for a Range of Projects) carry out the following steps:

See: Generate Intercompany Invoices, Oracle Projects Fundamentals.

Calculate the Transfer Price Amount

The Generate Intercompany Invoices processes calculate the transfer price amount using the same steps as described for the Distribute Borrowed and Lent Amounts process.

Run AutoAccounting

After the process calculates the transfer price amounts for each selected intercompany billing transaction, it runs AutoAccounting to determine the default intercompany revenue account for each cross charged transaction, using the Intercompany Revenue function.

Determine Tax Classification Codes

The Generate Intercompany Invoices process uses the Application Tax Options hierarchy that you define in Oracle E-Business Tax to derive the default tax classification code for each transaction. The process also determines the intercompany tax receiving task for the transaction.

Create Intercompany Invoice Details

The process then creates intercompany invoice details for each transaction with the transfer price amount, intercompany revenue account, and tax classification code.

Create Invoices and Invoice Lines

The Generate Intercompany Invoice process groups the invoice details of cross charged transactions into invoices and invoice lines.

The Generate Intercompany Invoice process:

Verifies intercompany billing projects
Creates invoice
Creates invoice lines

Verify intercompany billing projects

The process verifies that each specified intercompany billing project meets the following criteria before generating an invoice and invoice lines:

(Mass generation only) Billing cycle criteria have been met.
Invoice details exist that have not yet been included in an invoice.
The project customer, and customer bill and ship to sites must all be active. Otherwise, Oracle Projects creates an invoice marked with generation error.
The project customer must not be on credit hold. Otherwise, Oracle Projects creates an invoice marked with generation error.
The status of the intercompany billing project must not be Closed.

Create invoice

Depending on how the provider operating unit has implemented the provider controls, this step creates:

A consolidated intercompany invoice for all cross charged projects of a receiver operating unit. In other words, one draft invoice for each intercompany billing project.
One intercompany invoice for each cross charged project. In other words, multiple invoices for an intercompany billing project when multiple cross charged projects exist for a receiver operating unit. Oracle Projects orders such invoices by generating status and the project number of the cross charged project.

The process uses the date of the invoice as the GL date.

Create invoice lines

The process uses the following criteria to group invoice details to generate invoice lines:

Cross-charged project
Tax attributes
Intercompany revenue account
Invoice format components

Invoice lines are then created for the invoices based on the grouped invoice details.

Note: If an invoice line amount is zero due to offsetting invoice details, the process does not create the invoice line and includes the invoice details for that line in an exception report.

Approving and Releasing Intercompany Invoices

Approving and releasing intercompany invoices consists of the following actions:

Review intercompany invoices in the Invoice Review window.

From this window, you can drill down from a draft intercompany invoice to draft intercompany invoice lines to the underlying cross charged transactions.
Approve intercompany invoices as you would a customer invoice.
Release intercompany invoices as you would a customer invoice.

Note: Oracle Projects generates the invoice number for intercompany invoices and customer invoices from different sequences because different batch sources are used to interface these invoices to Oracle Receivables.
(Optional) Delete unapproved intercompany invoices as you would a customer invoice.

Interfacing Intercompany Invoices to Receivables

The PRC: Interface Intercompany Invoices to Receivables process interfaces released intercompany invoices to Oracle Receivables. You can run this process separately or as a streamline process (choose the XIC: Interface Intercompany Invoices to AR parameter). The streamline process includes the following processes:

Interface Intercompany Invoices to Receivables

This process interfaces intercompany invoices with active Bill To and Ship To address to the Oracle Receivables interface table. It identifies the following debit accounts for intercompany invoices:

Intercompany Receivables
Intercompany Rounding

Oracle Projects provides the AutoAccounting function Intercompany Invoice Accounts to determine the default receivables and rounding accounts. The default intercompany revenue account is already available on the invoice lines for intercompany invoices.

Once in Oracle Receivables, intercompany invoices are identified with a batch source of PA Internal Invoices and a transaction type of either Internal Invoice or Internal Credit Memo. You can query receivables information by project-related query data. Project information in Oracle Receivables is located in the Transaction Flexfield and Reference field. The fields in Oracle Receivables which hold project-related data for intercompany invoices (reference field of the PA Internal Invoices batch source) are shown in the following table:

Oracle Receivables Field Name	Oracle Projects Data
Transaction Flexfield Value 1	Project number of the intercompany billing project
Transaction Flexfield Value 2	Draft invoice number from Oracle Projects
Transaction Flexfield Value 3	Receiving operating unit
Transaction Flexfield Value 4	Project manager
Transaction Flexfield Value 5	Project number of the cross charged project
Transaction Flexfield Value 6	Line number of the invoice line
Transaction Flexfield Value 7	Invoice type of the invoice

Line grouping rule and line ordering rule in Oracle Receivables for intercompany invoices are as follows:

Line grouping. Uses Transaction Flexfield Values 1 through 4.
Line ordering. Uses Transaction Flexfield Values 5 through 7.

Decentralized invoice collections are not enabled for intercompany invoices.

AutoInvoice

The Oracle Receivables Invoice Import process pulls invoices from the Oracle Receivables interface tables. See: Oracle Receivables User Guide.

Tieback Invoices from Receivables

The Tieback Invoices from Receivables process verifies the successful interface of intercompany invoices to Oracle Receivables. Intercompany invoices successfully interfaced to Oracle Receivables are also automatically interfaced to the Oracle Payables system of the receiver operating unit. See: Tieback Invoices from Receivables, Oracle Projects Fundamentals.

Generate Provider Cost Reclassification Entries

After you run the process PRC: Tieback Invoices from Receivables, run the process PRC: Generate Cross Charge Accounting Events to generate accounting events for the provider cost reclassification journal entries.

Next, run the process PRC: Create Accounting to create accounting entries for the provider cost reclassification accounting events in Oracle Subledger Accounting. When you run the process in final mode, you can optionally choose to transfer the accounting to Oracle General Ledger. If you select this option, the create accounting process initiates Journal Import in Oracle General Ledger. If you define your own detailed accounting rules in Oracle Subledger Accounting, then Oracle Subledger Accounting overwrites default accounts, or individual segments of accounts, that Oracle Projects derives using AutoAccounting.

You can review the entries from the View Accounting window. See Create Cross Charge Distribution Lines for more information on using the View Accounting window.

Note: Before you can view the accounting entries, you must create subledger accounting entries for the accounting events associated with the provider cost reclassifications.

Interfacing Intercompany Invoices to Oracle Payables

Interfacing intercompany invoices to the invoice tables in Oracle Payables consists of the following steps:

Interface intercompany invoices to the Payables interface table

When the provider operating unit runs the Tieback Invoices from Receivables process, the intercompany invoices are automatically copied into the interface table of the receiver operating unit's Payables. Intercompany invoices interfaced to Payables are identified with the following attributes:

Source. All intercompany invoices have a source of Oracle Projects Intercompany.
Supplier. The supplier is identified by the provider operating unit's internal billing implementation options.
Supplier Site. The supplier site is based on how the provider operating unit defines the receiver controls for the receiver operating unit.
Invoice Amount. The Payables invoice amount is the amount of the related Receivables invoice, including taxes.

The interface process populates the project-related attributes for intercompany Payables invoice distributions, as indicated below:

Project Number. The number of the cross charged project indicated in the invoice line.
Task Number. The number of the task specified in the Intercompany Tax Receiving Task field on the cross charged project.
Expenditure Item Date. The invoice date of the intercompany Receivables invoice.
Expenditure Type. The expenditure type specified by the receiver operating unit in the Receiver Controls tab.
Expenditure Organization. The expenditure organization specified by the receiver operating unit in the Receiver Controls tab.

The Payables Open Interface process creates invoice distributions for the entire invoice.

Run the Open Interface Import process in Payables

The receiver operating unit runs the Open Interface Import process in Payables to create intercompany Payables invoices. Payables Open Interface Import performs the following steps:

Convert amounts from the transaction currency to the functional currency of the receiver operating unit based on the default conversion attributes defined in the receiver operating unit's Payables system options. (The Receivables invoice amounts are copied as the transaction currency amounts on the Payables invoice.)

You can customize the Payables Open Interface workflow process to override the default currency conversion attributes for the invoice and distribution amounts.
Derive the default intercompany Payables account from supplier information. You can either associate supplier types for internal suppliers with intercompany cost accounts or otherwise modify the Workflow-based account generation process to determine the appropriate intercompany cost account. Payables Invoice Import generates the following sample accounting entries:

DR Intercompany Cost

CR Intercompany Payables

If you define your own detailed accounting rules in Oracle Subledger Accounting, then Oracle Subledger Accounting overwrites default accounts, or individual segments of accounts, that Oracle Payables derives using the Account Generator.
Generate recoverable and non-recoverable tax lines based on the tax classification code associated with each invoice line and the percentage you specify for recoverable tax amounts.

Interface Tax Lines from Oracle Payables to Oracle Projects

After the Payables Invoice Import process generates non-recoverable tax lines for the intercompany invoice, you must run the Interface Supplier Costs process to interface these non-recoverable tax lines to Oracle Projects as project costs.

Tax lines interfaced from Oracle Payables are not subject to any cross charge processing.

Adjusting Cross Charge Transactions

This section provides an overview and a description of the processing flow for adjustments to cross charge transactions.

Overview of Cross Charge Adjustments

Processing Flow for Cross Charge Adjustments

Overview of Cross Charge Adjustments

Due to data entry errors or changes in your organization or business rules, you may need to adjust certain attributes of cross charged transactions. Doing so causes Oracle Projects to reprocess the transactions or to skip the cross charge processes completely. You can adjust a cross charged transaction by:

Marking transactions for cross charge reprocessing
Marking transactions to skip cross charge processing
Changing transfer price conversion attributes
Making the following miscellaneous adjustments
Changing transfer price base amounts
Changing the provider or receiver organization using the mass update feature
Recompiling burden schedules
Performing splits and transfers
Performing adjustments on the Receivables or Payables invoices

Marking transactions for cross charge reprocessing

You can mark one or more transactions for cross charge reprocessing in the Expenditure Items window. For example, if you have changed cross charge setup data and want this new information reflected in the affected transfer price amounts and accounting entries, select the Reprocess Cross Charge option in the Reports menu of the Expenditure Items window.

Marking a transaction for cross charge reprocessing:

Resets the cross charge type to Null
Resets the cross charge processing method to Pending
Resets the cross charge processing status to Never Processed
Resets the transfer price amount in all currencies to Null
Redetermines the cross charge type and processing method

The next time you run the cross charge processes, they will process these transactions as new cross charged transactions.

You should mark affected transactions for cross charge reprocessing if you have changed any of the following information:

Provider or receiver organization. Modifying the Provider and Receiver Organizations Override extension or changes in your organizational structure can result in changes to the provider or receiver organization of a cross charged transaction, which could affect the cross charge type, the processing method, or the transfer price rules.
Transfer price setup data. Any change to your transfer price rules could result in a new transfer price amount determined for cross charged transactions that have already been processed.
Cross-charge setup data. Any change to your cross charge or internal billing implementation options, provider and receiver controls, or cross charge project and task information can affect how Oracle Projects processes cross charged transactions.
Account codes. Changes to the provider reclassification accounting options can result in changes to the provider cost reclassification accounts. Any changes to the AutoAccounting setup for cross charge functions can also affect existing cross charge accounting entries.
Billable flag. For cross charged transactions processed by intercompany billing with the provider cost reclassification feature enabled, changes to the Billable flag of a transaction on a contract project can result in new provider cost reclassification accounting entries.
Tax classification codes. The Generate Intercompany Invoice processes determine the appropriate tax classification code for each invoice line. If you modify the logic used to derive the tax classification codes and have already released invoices, you must mark the affected transactions for cross charge reprocessing. Oracle Projects automatically creates a credit memo for the original invoice and a new invoice with the new tax classification codes.

Marking transactions to skip cross charge processing

You can mark one or more transactions so that the cross charge processes skip the specified transactions. To do this, choose Mark For No Cross Charge Processing in the Reports menu of the Expenditure Items window.

Marking a transaction as not requiring cross charge processing resets the cross charge processing method to No Cross Charge Processing and the cross charge processing status to Never Processed.

Changing transfer price conversion attributes

You can reconvert transfer price amounts from the transaction currency if you change the transfer price exchange rate date type and exchange rate type, which govern how Oracle Projects converts the transfer price amount from the transaction currency to the functional currency. To do this, you choose the Change Transfer Price Currency Attributes option from the Reports menu in the Expenditure Items window. A change in these conversion attributes may result in a change to the transfer price amount in the functional currency.

Both provider and receiver operating units can change the transfer price conversion attributes.

Changing your transfer price currency conversion attributes:

Replaces conversion attributes for the functional currency
Resets existing transfer price amounts in the functional currency to Null
Resets the cross charge processing status to Never processed

Making miscellaneous cross charge adjustments

You can perform the following adjustments to cross charged transactions. These adjustments automatically mark the transaction for cross charge reprocessing.

Changing transfer price base amounts. If you recalculate raw or burdened cost or revenue amounts, the amount of the transfer price basis (and the final transfer price amount) of a cross charged transaction may also change. The respective cost distribution and revenue generation processes determine whether such recalculations affect the transfer price amount of any cross charged transactions and automatically mark the transactions for cross charge reprocessing.

The cost distribution and revenue generation processes automatically resets the cross charge processing status to Never Processed and blanks out the transaction's transfer price amount.
Changing the provider or receiver organization using the mass update feature. If you use the mass update feature to change the organization that owns a project or task, Oracle Projects marks all transactions (with an expenditure date after the effective date of the organization change) for cross charge reprocessing. A different project (or receiver) organization could result in a change to the transaction's cross charge processing method.

Oracle Projects automatically marks the affected items for cross charge processing.
Recompiling burden schedules. If the user changes and recompiles a burden schedule that has been used for determining the transfer price of some items, the recompile process will mark these items for cross charge reprocessing by resetting the cross charge type to Null, the cross charge processing method to Pending, and the cross charge processing status to Never Processed.
Performing transfers and splits. Transferring or splitting a cross charged transaction does not affect the cross charge processing method of the existing transactions. The reversing and new transactions will undergo the cross charge processes as usual.

The Generate Intercompany Invoice processes group the invoice details for all adjusting transactions by the invoice number and line number of the original transactions for credit memo processing.
Performing adjustments on the Receivables or Payables invoices. You can adjust invoice level accounting information for Receivables and Payables invoices, as described below:
- Intercompany Receivables account (for Receivables invoices). The Interface Intercompany Invoices to Receivables process determines the intercompany receivables account for each invoice. If you change the rules used to determine this account, you must manually cancel the invoice from the Invoice Review window. Oracle Projects automatically creates a credit memo with details reversing each line in the original invoice. All items on the cancelled invoice are eligible for intercompany rebilling. Once rebilled, the Interface Intercompany Invoices to Receivables process will determine the account for the new invoice using the modified rules.
  
  You cannot cancel an invoice if payments have been applied against it in Oracle Receivables or if an invoice has credit memos applied against it. You can cancel an invoice only if it is released and has no payments, adjustments, or crediting invoices applied against it. Once the cancellation is completed, you cannot delete the credit memo created by the cancellation action. That is, you cannot reverse an invoice cancellation.
- Intercompany cost account (for Payables invoices). In Oracle Payables, reverse the invoice distribution with the incorrect intercompany cost account and create a new line with the correct account information.

Processing Flow for Cross Charge Adjustments

After you mark an adjustment to a cross charged transaction for reprocessing, Oracle Projects processes these adjustments similarly to the original transactions. The processing flow for adjustments is described in further detail on the following pages.

The cross charge processes perform the following common steps on adjustments marked for cross charge reprocessing, regardless of whether the transactions require borrowed and lent or intercompany billing processing:

Recalculate the transfer price if no transfer price amount exists in the transaction currency
Reconvert the transfer price amount from the transaction currency to the functional currency if an amount exists in the transaction currency but not the functional currency

Processing Borrowed and Lent Adjustments

After the PRC: Distribute Borrowed and Lent Amounts process completes the common processing steps for cross charge adjustments, it performs the steps for borrowed and lent adjustments, as described below.

Regenerate accounting entries. If any of the accounts have changed for which you have already generated cross charge accounting events, the Distribute Borrowed and Lent Amounts process reverses the original cross charge distributions and creates new ones. The process also determines the PA dates for the reversing and new distributions. If you have not yet generated cross charge accounting events for the original accounting entries, and the accounts or amounts have changed, the process replaces them with the new entries.
Reverse existing distributions if processing method has changed. If the cross charge processing method for the transaction changes from borrowed and lent to intercompany billing or no cross charge processing, the process reverses existing entries for which you have already generated cross charge accounting events.

Processing Intercompany Billing Accounting Adjustments

After the Generate Intercompany Invoice process completes the common processing steps for cross charge adjustments, it performs the following steps:

Redetermine the intercompany revenue account and tax classification code.

The process determines the revenue account and tax classification code for the adjusted transactions. If intercompany invoice details exist for the transaction, the Generate Intercompany Invoice process compares the recalculated transfer price amount with the existing transfer price amount. If the transfer price amounts are different, you must reverse the existing invoice detail line and create a new one. Similarly, if the process detects a difference in the new intercompany revenue account or tax classification code and the existing values, then the process reverses the existing invoice details and creates new invoice details.
Create a credit memo.

The Generate Intercompany Invoice process creates a credit memo, in which reversing invoice details are grouped together by the invoice number and invoice line number on which the original invoice details are billed.
Create new invoices.

The process groups invoice details for changed values of the transfer price, revenue account, and tax classification code into the new invoice. You then interface the new invoices to Oracle Receivables.
(Optional) Regenerate provider cost reclassification accounting entries.

After you run the process PRC: Tieback Invoices from Receivables, if any of the accounts have changed from entries for which you have already generated accounting events, the Generate Intercompany Invoice process reverses the original distributions and creates new ones. The process also determines the PA dates for the reversing and new distributions. If you have not yet generated accounting events for the original accounting entries, and the accounts or amounts have changed, the process replaces them with the new entries.