3Financial Reporting Structures

This chapter contains the following:

Define your enterprise structures in your chart of accounts to track and report on your financial objectives and meet your reporting requirements. The benefit of representing your enterprise in the chart of accounts is the functionality which includes multidimensional reporting with its Essbase tool. Segments included in the chart of accounts become dimensions in Essbase. The recorded data is automatically loaded into the Essbase cube when you post your journal entries. The Essbase tool includes powerful functionality for analysis and reporting on your financial data.

Chart of Accounts

Overview of Chart of Accounts

The chart of accounts is the underlying structure for organizing financial information and reporting. An entity records transactions with a set of codes representing balances by type, expenses by function, and other divisional or organizational codes that are important to its business. The chart of accounts facilitates aggregating data from different operations, from within an operation, and from different business flows, thus enabling the organization to report using consistent definitions to their stakeholders in compliance with legislative and corporate reporting standards and aiding in management decisions.

In Oracle Fusion General Ledger, the chart of accounts model is framed around the concept of a chart of accounts structure, under which one or more chart of accounts structure instances can be created. Consider the critical choices list here when creating your hart of accounts instances and structures.

Chart of Accounts Structure

When creating the segments for the chart of accounts structure, you must enter segment sequence numbers that are consecutive and begin with the number one.

Chart of Accounts Structure Instance

For segments in your chart of account structure instance that you expect to contain a large number of distinct values, you must perform the following steps:

  • In the chart of accounts definition, mark the segment query required option as selectively required. To perform searches in the transactional user interface, you have to specify the following segment as a mandatory search criteria.

  • Create required indexes in the GL_CODE_COMBINATIONS table for segments that are selectively required.

Caution: For the Accounting Key Flexfield value sets used in your chart of accounts structure and instance, you must use independent validation only. If you use other validations, you may not be able to use the full chart of accounts functionality, such as data security, reporting, and account hierarchy integration.

Overview of Creating and Configuring Chart of Accounts Structure and Instances

In Oracle General Ledger, the chart of accounts model is framed around the concept of a chart of accounts structure, for which one or more chart of accounts structure instances can be created. A chart of accounts structure defines the key attributes for your chart of accounts. These attributes include the number of segments, the segment sequences, the segment names, segment prompts, segment labels, for example natural account and primary balancing, and default value sets.

FAQs for Manage Charts of Accounts

How can I use future accounting segments?

To plan for future growth in the business organization that requires additional segments in the chart of accounts. Extra segments can be added to the chart of accounts structure during your original implementation. All segments of the chart of accounts are required and have to be enabled. The unused segments can be assigned value sets that have a single value in the chart of accounts structure instance. The value is set as a default for that segment so that the extra segments are automatically populated when an account account combination is used.

Overview of Value Sets

A value set is a group of valid values that you assign to a flexfield segment to control the values that are stored for business object attributes.

A user enters a value for an attribute of a business object while using the application. The flexfield validates the value against the set of valid values that you configured as a value set and assigned to the segment.

Account Hierarchies

Trees are hierarchical data models that you can use to organize data, apply business rules, control data access, and improve performance while querying. For example, an application maintains data of an organization called Vision Corporation that has two departments: Marketing and Finance. The Finance department has two functional divisions: Receivables and Payables. You can define a tree for Vision Corporation to establish a hierarchy across its departments, and their respective functional divisions. You can use the hierarchy to manage data at various levels of the organization.

To work with trees, in the Setup and Maintenance work area, use any of the following tasks:

  • Manage Tree Structures: To create and update tree structures. You must first define a tree structure to create a tree.

  • Manage Trees and Tree Versions: To create and update trees and their versions.

  • Manage Tree Labels: To create and update tree labels.

Tree Structures

As the name suggests, tree structures provide you the framework to organize data such that you can establish a hierarchy for use by the tree. So, similar to a template, a tree structure guides the creation of a tree.


A tree is an instance of the tree structure. The root node is the highest nodal point of a tree. Child nodes branch off from the root node. Child nodes at the same level, branching off from a common parent node, are called siblings. Leaves are details branching off from a node but not extending further down the tree hierarchy. You can create trees for multiple data sources and share them across applications.

Tree Versions

A tree by default has only one version. If required, you can create and maintain more than one editable tree version. At any point, only one tree version must be active. If you edit an existing version, it changes from active to draft. To use it again, you must set it to active. Similar to any other version control system, versions of trees are maintained to track all the changes that a tree undergoes in its life cycle.

Tree Labels

Tree labels are short names given to trees and tree structures. You can label the tree versions for better accessibility and information retrieval. When nodes are created in a tree, the existing tree labels are automatically assigned to the new tree nodes. You can use any table to store the labels and register the label data source with the tree structure.

Overview of Managing Account Hierarchies

Account hierarchies are defined in Oracle Fusion applications using tree functionality. Each account hierarchy is defined as a tree with one or more versions. Tree versions are used to track account hierarchies as they change over time. For example, an account hierarchy to summarize cost of goods has different accounts for 2011, versus 2010. The changes are in the business operations and affect the chart of accounts values.

Chart of accounts values can be associated with multiple hierarchies by defining multiple trees. Using multiple trees enable create financial reports for different target audiences. For example, you can use different hierarchies to track cost centers either by geography or line of business.

Before setting up hierarchies, you may want to consider different hierarchy requirements for financial reporting, allocations, cross validation rules, revaluations, and chart of accounts mapping.

Overview of Maintaining Account Hierarchies

This topic describes the best practices of maintaining and publishing the account hierarchies. Account hierarchies are used throughout Oracle Fusion General Ledger for creating financial reports, Smart View inquiries, allocation definitions, cross validation rules, and revaluation definitions.

FAQs for Manage Account Hierarchies

How can I manage and review account hierarchies?

View segment value descriptions when creating, editing, or reviewing account hierarchies online. You can also export account hierarchies to a spreadsheet to review, analyze, and report offline.

To export all nodes in the hierarchies to a spreadsheet, expand all nodes first from View -> Expand All in the Manage Account Hierarchies: Specify Nodes page.

When do I manually submit row and column flattening for tree versions?

Row Flattening and Column Flattening for tree versions must be manually submitted in the following scenarios.

  • A new tree or tree version is defined

  • If the tree or tree version has any change made to it that would alter the flattened hierarchy data. For example, adding, moving, and duplicating members. Basically, anything that impacts the flattened hierarchy data.

  • If Data Relationship Management (DRM) is used with Oracle Fusion General Ledger, after running the Load Account Values and Hierarchies process from the Scheduled Process work area to load chart of accounts reference data from DRM to Oracle Fusion General Ledger.

  • When range based hierarchy assignments are supported, if new values are added that are within the account range assigned to the hierarchy.

    Note: In this case, try submitting the flattening programs using the Online Mode first. If the newly inserted child account value does not appear to be included in the flattened hierarchy data, then the flattening program has to be submitted using the Force Flattening Mode, instead of Online Flattening. An issue with the incremental flattening programs can prevent them from picking up this type of hierarchy change, so full flattening can be required.
Note: Column flattening processed data is primarily relevant to Oracle Fusion Transactional Business Intelligence, but there should not be any adverse impact to run both row and column flattening processes.

Overview of Managing Tree Structures

A tree structure defines the hierarchy for creating trees and prescribes rules based on which trees are created, versioned, and accessed. You can associate multiple data sources with a tree structure. A tree is an instance of this hierarchy. Every tree structure can contain one or more trees.

You can create tree structures specific to an application but you can share tree structures across applications. If you apply version control to the tree structure, it's carried over to the trees that are based on the tree structure. Each tree version contains at least one root node. Occasionally, a tree version may have more than one root node.

An administrator controls the access to tree structures through a set of rules that are periodically audited for validity.

Tree labels are tags that are stored on tree nodes. You can store labels in any table and register the label data source with the tree structure. When a labeling scheme is used for trees, the selected labels are stored in the tree label entity, and each tree node contains a reference to a tree label in the labeling scheme.

The following table lists the three ways in which tree labels are assigned to the tree nodes.

Labeling Scheme Description


Labels that are automatically assigned based on the data source to which the tree node belongs. A level label points to a specific data source. For example, in a tree that reflects the organizational hierarchy of an enterprise, all division nodes appear on one level and all department nodes on another.


Labels that you can arbitrarily assign to tree nodes.


Labels that are automatically assigned based on the depth of the tree node within the tree. No manual assignment is performed.

Note: In an unbalanced hierarchy, a level may not be equal to depth.

Overview of Managing Tree Versions

You can create and edit trees and tree versions depending upon the requirement. A tree can have one or more tree versions. When you change an existing tree, a new version is created and published. You can use the tree version audit results to verify the tree version's correctness and data integrity.

Segment Value Attributes

Segment Labels

Segment labels identify certain segments in your chart of accounts structure and assign special functionality to those segments. Best practice is to assign each segment label one time within the chart of accounts structure. Here are the segment labels that are available to use with the chart of accounts structure.

Caution: Validations aren't performed when segment labels are assigned, so verify that all are assigned correctly before using your chart of accounts.


Ensures that all journals balance for each balancing segment value or combination of multiple balancing segment values. You can secure access to your primary balancing segment values only with data access sets. The General Ledger application automatically calculates and creates balancing lines as required in journal entries. For example, recognizing an entity's receivable and the other entity's payable. The three balancing segment labels are primary, second, and third balancing. The primary balancing segment label is required.

Cost Center

Represents the smallest segment of an organization for which costs are collected and reported. Facilitates grouping of natural accounts by functional cost types, accommodating tracking of specific business expenses across natural accounts. As cost centers combine expenses and headcount data into costs, they're useful for detailed analysis and reporting. Cost centers are optional, but required for:

  • Tracking depreciation, additions, and other transactions in Oracle Fusion Assets.

  • Storing expense approval limits in Oracle Fusion Expense.

Natural Account

Determines the account type (asset, liability, expense, revenue, or equity), whether posting is allowed, and other information specific to the segment value. The natural account segment is mapped to the Financial Category dimension in the balances cube to enable ad hoc reporting and transactional dashboards. This functionality uses Oracle Fusion Business Intelligence Enterprise Edition to analyze and drill into expense and revenue transactions. The natural account segment label is required.


Optionally, assign the segment to be used in intercompany balancing functionality. You can't use the primary balancing or natural account segments as the intercompany segment. You can assign the same values to both the primary balancing and intercompany value sets. You can also assign the same value set to the primary balancing segment and the intercompany segment. The sharing of the value set or values:

  • Enables clear visibility of the due to and due from relationships inherent in intercompany accounting across the entire organization.

  • Saves maintenance and ensure completeness.

However, sharing value sets can cause problems when applying segment value security rules because the rules applied to both segments. The rules can restrict access to certain values which may complicate entering intercompany entries. For example, you might have access to company 01 at the balancing segment level but not company 02. As a result, you can't enter an intercompany entry for transactions between 01 and 02.

Example of Segment Labels

For a chart of accounts, each segment can be qualified by a label to distinctly indicate its purpose. The label designation is used by Oracle Fusion General Ledger processes to determine how to display and process transactions and balances that are recorded.


You are creating your chart of accounts with six segments. General Ledger permits selection of up to thirty segments for your chart of accounts. You must have a minimum of three required segments, as determined by the number of required segment labels (qualifiers). Required segment labels are:

  • Primary Balancing Segment: Main balancing segment typically used to represent the company dimension of the organization. The segment set with this label can't be set with another label.

  • Cost Center Segment: Smallest segment of an organization for which you collect and report costs. You are required to create this segment if you're implementing Oracle Fusion Assets.

  • Natural Account Segment: Classification of transactions and balances according to distinct account types: asset, liability, equity, revenue, and expense accounts. The segment set with this label can't be set with another label.

The following optional segment labels are available, and you are implementing all of them:

  • Second Balancing Segment: Used to balance transactions, as needed, by an additional dimension beyond the primary balancing segment.

  • Third Balancing Segment: Used to balance transactions, as needed, by an additional dimension beyond the primary and second balancing segments.

  • Intercompany Segment: Used to track intercompany due to and due from balances by identifying the specific trading company. The intercompany qualified segment cannot be set with any of the three balancing segment qualifiers. The values in this segment's value set must be the same as the primary balancing segment.

Segment labels can only be assigned once within a chart of accounts. The following table shows the segment labels that are assigned to each segment in the chart of accounts.

Segment Label


Primary Balancing Segment

Cost Center

Cost Center and Second Balancing Segment


Third Balancing Segment


Natural Account Segment

Product Line

Not Applicable


Intercompany Segment

Note: Validations aren't performed when segment labels are assigned, so verify that all are assigned correctly before using your chart of accounts.

For Oracle Transactional Business Intelligence reporting, all labeled segments of the chart of accounts are automatically maintained in the data that reporting is based on. The granularity of information stored in the nonqualified segments is summarized and Oracle Transactional Business Intelligence isn't able to provide detailed reporting by segments. To maintain the ability to perform detailed reporting on such segments, create user-defined labels to qualify these segments.

For example, one of the segments of the chart of accounts is based on product line, and none of the segment labels are applicable. The organization must derive product line-based Oracle Transactional Business Intelligence reports. Create a user-defined label called Product Line to use to qualify the Product Line segment of the chart of accounts.

Overview of Balancing Segments

Balancing segments ensure that all journals balance for each balancing segment value or combination of multiple balancing segment values. You can secure access to your primary balancing segment values only with data access sets. The General Ledger application automatically calculates and creates balancing lines as required in journal entries. By enabling multiple balancing segments for your chart of accounts, you can produce financial statements for each unique combination of segment values across one, two, or three qualified balancing segments. This ability provides you greater insights into your operations as it affords you visibility along the critical fiscal dimensions you use to plan, monitor, and measure your financial performance.

Examples of Segment Value Inheritance

The Inherit Segment Value Attributes process simplifies the chart of accounts maintenance. When the characteristics of values in the value sets are updated, such as changes to enabled status, effective date, posting allowed status, or natural account type, all previously created account combinations that referenced such values aren't automatically updated by these changes. The Inherit Segment Value Attributes process lets you run a controlled process to update such existing account combinations. This process maintains and corrects the current attribute settings for those account combinations that contain the account values that were changed.

For account combinations where the present settings must be retained and not impacted by account attribute changes, activate the option to preserve the account combination's attributes. The Preserve Attributes option can be found on the Manage Account Combinations page. Activating the option prevents those account combination's attributes from being updated when the Inherit Segment Value Attributes process is run.


For example, there are three inactive account combinations that share a common inactive cost center value of 110. The following table lists each account combination, indicates whether the account combination is enabled, and indicates how the Preserve Attributes option is set.

Company-Cost Center-Account Account Combination Enabled Preserve Attributes










Cost center 110 is enabled and the segment value inheritance process is run. The following table shows how the status of the account combinations changes.

Company-Cost Center-Account Account Combination Enabled Preserve Attributes










Note: After you disable a segment value and sign out of the application and back in, all account combinations containing that segment no longer work, even if the account combination still shows enabled in the account combination page. Use the Inherit Segment Value Attribute process to correctly set the enable option on the affected account combinations.

FAQs for Maintain Segment Values Attributes

The chart of accounts structure and structure instance are fundamental constructs in General Ledger accounting setup and can't be altered once they're used. The number of segments, the segments' order, each segment's label, length, type, and value set assignment can't be updated. These components set the foundation upon which accounting data is recorded for ledgers that use them. Careful and thoughtful planning must precede all decisions pertaining to defining the chart of accounts.

Overview of Deploying Flexfield

Deployment generates or refreshes the Application Development Framework (ADF) business component objects that render the flexfield in a user interface. The deployment process adds user-defined attributes to the Web Services Description Language (WSDL) schemas exposed by Oracle ADF services and used by SOA composites. Flexfields are deployed for the first time during the application provisioning process. After you configure or change a flexfield, you must deploy it to make the latest definition available to users.

If a descriptive flexfield is enabled for business intelligence, the deployment process redeploys the flexfield's business intelligence artifacts.

You can deploy a flexfield to a sandbox for testing or to the mainline metadata for use in a test or production run time environment. You can deploy extensible flexfields as a background process.

After deployment, the user-defined attributes are available for incorporating into the SOA infrastructure, such as business process and business rule integration. For example, you can now write business rules that depend on the user-defined attributes. You must sign out and sign back in to Oracle Applications Cloud to see the changes you deployed at run time.

Cross-Validation Rules

Overview of Creating Cross-Validation Rules in a Spreadsheet

The rapid implementation solution provides a template for defining cross-validation rules in a spreadsheet. Cross-validation rules determine whether a selected value for a particular segment of an account combination can be combined with specific values in the other segments to form a new account combination.

In the Setup and Maintenance work area, use the following:

  • Offering: Financials

  • Functional Area: General Ledger

  • Task: Create Cross Validation Rules in Spreadsheet

Note: The spreadsheet can only create cross-validation rules. To update existing cross-validation rules, use the Manage Cross-Validation Rules task in the Setup and Maintenance work area.

Overview of Managing Cross-Validation Rules

You can use cross-validation rules to determine the valid account combinations that can be dynamically created as users enter transactions or journal entries. You can also control the creation of new key flexfield code combinations by defining cross-validation rules. Once enabled, a cross-validation rule determines whether a selected value for a particular segment of an account combination can be combined with specific values in other segments to form a new account combination.

The chart of accounts mapping feature supports the ability to correlate a source chart of accounts to a target chart of accounts to allow for the processing of balances or amounts. Use either segment rules, account rules, or a combination of both. A chart of accounts mapping is used by the posting process in propagating transactions from the primary ledger to its secondary ledger. The mapping feature is used by both balance transfer processes for balance level secondary ledgers as well as cross ledger transfers. The balances are copied from one ledger to another ledger in both processes.

Segment Rules

Segment rules serve to map each segment of the target chart of accounts to an account value or segment in the source account. Three different mapping actions are available:

  • Assign a constant value for a segment in the target chart of accounts.

  • Copy the value from the source segment to the corresponding target segment.

    Note: To use this action, the paired target and source segments must share identical values in their value sets.
  • Use rollup rules to aggregate source accounts to a corresponding target segment or account

    • Create a single value mapping when a specific detail source segment value is given a detail target segment value.

    • Use hierarchical rollup rules when a specific parent source value and all of its child segment values, are mapped to a given detail target segment value. This provides the ability to process groups of source segment values in one single rollup rule.

    • Define parent source values in rollup rules when date effective versions of the hierarchy are used with the accounting date of the transactions by the processes that reference the chart of accounts mapping. The additional benefit of self-maintaining mappings is that if the hierarchies referenced change with time the applicable child values are updated automatically.

Account Rules

In addition to segment rules, define account rules for the chart of accounts mapping. Account rules map a complete target account combination against one or more source account combinations. The source account combinations can be defined segment by segment using:

  • Single detail account values.

  • Detail account value ranges.

  • Parent values for primary balancing and the natural account segments.

    Note: When using parent values, its child values for the date effective version of the hierarchy, are processed when the mapping is called.

FAQ for Manage Chart of Accounts Mapping

What's the difference between mapping with segment rules and mapping with account rules?

Segment rules map target chart of accounts segments to an account value or segment of the source account of a secondary chart of accounts. A segment is only one part of the account combination.

Account rules map a complete target account combination against one or more source account combinations.

Note: Segment and account rules can be used alone or both types of mapping rules can be used in the same mapping set.

When do account rules override segment rules in a chart of accounts mapping?

You can create a chart of accounts mapping using only segment rules, only account rules, or a combination of both segment and account rules. If an overlap exists between the two types of rule, the account rule supersedes. Segment rules are used to broadly define the relationship between two charts of accounts on a segment by segment basis. Account rules can be used to more precisely map specific source account combinations to their target accounts.

Overview of Defining Calendars

Define an accounting calendar to create your accounting year and the periods it contains. Specify common calendar options that the application uses to automatically generate a calendar with its periods. Specifying all the options makes defining a correct calendar easier and more intuitive with fewer errors.

FAQs for Define Calendars

Oracle Fusion General Ledger identifies erroneous entries online as you enter a new calendar or change data on an existing calendar. The application also automatically validates the data when you save the calendar.

The period naming format determines the year that's appended to the prefix for each period in the calendar. For the example, your accounting year has a set of twelve accounting period with:

  • Start date of September 1, 2014.

  • End date is August 31, 2015.

  • Period's date range following the natural calendar month date range.

Calendar period naming format: Select the calendar period format to append the period's start date's year to the prefix. For the period covering September 1, 2014 to December 31, 2014, then 2014 or just 14, depending on the period format selected, is appended to each period's name. For the remaining periods covering January 1, 2015 to August 31, 2015, then 2015 or 15, is appended to each period's name.

Fiscal period naming format: Select the fiscal period format to always append the period's year assignment to the prefix. If the accounting periods in the set of twelve are all assigned the year of 2015, then 2015 or just 15, depending on the period format selected, is appended to the period name of all 12 periods.

Update an existing calendar before the new periods are needed as future periods, based on the future period setting in your accounting configuration. If a complete year has been defined and validated, use the Add Year button to add the next year quickly. Accept or change the new rows as required. For example, with the Other frequency type calendar, dates may differ from what the application generates.

What happens if I upgrade my calendar from Oracle E-Business Suite Release 12?

The migration script assigns a period frequency that most closely matches your Oracle E-Business Suite Release 12 calendar. When you use the Oracle Fusion applications Add Year functionality for the first time, you have an opportunity to review and change the period frequency. The Calendar Options page opens only for calendars upgraded from Release 12 to allow one time modification.

Make your changes to the period frequency, adjusting period frequency, and period name format, including the prefix and separator, as needed. Changes cannot conflict with the existing upgraded calendar definition. Update the calendar name and description in the calendar header, as needed, for all calendars. Period details for a new year are generated automatically based on the latest calendar options. You can also manually update the calendar. The modified calendar options affect future years only.


When creating or editing currencies, consider these points relevant to entering the currency code, date range, or symbol for the currency.

Currency Codes

You can't change a currency code after you enable the currency, even if you later disable that currency.

Date Ranges

You can enter transactions denominated in the currency only for the dates within the specified range. If you don't enter a start date, then the currency is valid immediately. If you don't enter an end date, then the currency is valid indefinitely.


Some applications support displaying currency symbols. You may enter the symbol associated with a currency so that it appears along with the amount.

Use the Derivation Type, Derivation Factor, and Derivation Effective Date fields to define the relationship between the official currency (Euro) of the European Monetary Union (EMU) and the national currencies of EMU member states. For each EMU currency, you define its Euro-to-EMU fixed conversion rate and the effective starting date. If you have to use a different currency for Euro, you can disable the predefined currency and create a new one.

Derivation Type

The Euro currency derivation type is used only for the Euro, and the Euro derived derivation type identifies national currencies of EMU member states. All other currencies don't have derivation types.

Derivation Factor

The derivation factor is the fixed conversion rate by which you multiply one Euro to derive the equivalent EMU currency amount. The Euro currency itself must not have a derivation factor.

Derivation Effective Date

The derivation effective date is the date on which the relationship between the EMU currency and the Euro begins.

FAQs for Manage Currencies

Create or enable any currency for displaying monetary amounts, assigning currency to ledgers, entering transactions, recording balances, or for any reporting purpose. All currencies listed in the International Organization for Standardization (ISO) 4217 standard are supported.

The default currency is set to United States Dollar (USD).

Precision refers to the number of digits placed after the decimal point used in regular currency transactions. For example, USD would have 2 as the precision value for transactional amounts, such as $1.00.

Extended precision is the number of digits placed after the decimal point and must be greater than or equal to the precision value. For calculations requiring greater precision, you can enter an extended precision value such as 3 or 4. That would result in the currency appearing as $1.279 or $1.2793.

Minimum accountable unit is the smallest denomination for the currency. For example, for USD that would be .01 for a cent.

You can set these values for a currency using the Manage Currencies task in the Application Extensions functional area in the Setup and Maintenance work area.

Conversion Rate Types

Maintain different conversion rates between currencies for the same period using conversion rate types. The following conversion rate types are predefined:

You can use different rate types for different business needs. During journal entry, the conversion rate is provided automatically based on the selected conversion rate type and currency, unless the rate type is User. For User rate types, you must enter a conversion rate. You can define additional rate types as needed. Set your most frequently used rate type as the default. Conversion rate types can't be deleted.

Assign conversion rate types to automatically populate the associated rate for your period average and period end rates for the ledger. For example, you can assign the conversion rate type of Spot to populate period average rates, and the conversion rate type of Corporate to populate period end rates. Period average and period end rates are used in translation of account balances.

Conversion rate types are used to automatically assign a rate when you perform the following accounting functions:

  • Convert foreign currency journal amounts to ledger currency equivalents.

  • Convert journal amounts from source ledgers to reporting currencies or secondary ledgers.

  • Run revaluation or translation processes.

When creating conversion rates, decide whether to:

  • Enforce inverse relationships

  • Select pivot currencies

  • Select contra currencies

  • Enable cross rates and allow cross-rate overrides

  • Maintain cross-rate rules

Enforce Inverse Relationships

The Enforce Inverse Relationship option indicates whether to enforce the automatic calculation of inverse conversion rates when defining daily rates. The following table describes the impact of selecting or not selecting the option.

Action Results


When you enter a daily rate to convert currency A to currency B, the inverse rate of currency B to currency A is automatically calculated and entered in the adjacent column. If either rate is changed, the application automatically recalculates the other rate.

You can update the application calculated inverse rate, but once you do, the related rate is updated. The option enforces the inverse relationship is maintained but doesn't prevent you from updating the rates.

Not Selected

The inverse rate is calculated, but you can change the rate and update the daily rates table without the corresponding rate being updated.

Select Pivot Currencies

Select a pivot currency that's commonly used in your currency conversions. A pivot currency is the central currency that interacts with contra currencies. For example, you set up a daily rate between the US dollar (USD) and the Euro currency (EUR) and another between the USD and the Canadian dollar (CAD). USD is the pivot currency in creating a rate between EUR and CAD. EUR and CAD are the contra currencies. Select the pivot currency from the list of values which contains those currencies that are enabled, effective, and not a statistical (STAT) currency. The description of the pivot currency is populated automatically based on the currency definition.

If you want the application to create cross rates against a base currency, define the base currency as the pivot currency. Selected pivot currencies can be changed in the Rate Types page.

Select Contra Currencies

Select currencies available on the list of values as contra currencies. The available currencies are those currencies which are enabled, effective, not STAT currency, and not the pivot currency selected earlier. The description of the contra currency is populated automatically based on the currency definition. Add or delete contra currencies in the Contra Currencies region of the Rate Types page.

Enable Cross Rates and Allow Cross Rate Overrides

Check the Enable Cross Rates check box to calculate conversion rates based on defined currency rate relationships. General Ledger calculates cross rates based on your defined cross rate rules. Associate your cross rate rules with a conversion rate type, pivot currency, and contra currencies. Cross rates facilitate the creation of daily rates by automatically creating the rates between contra currencies based on their relationship to a pivot currency. If the Enable Cross Rates option is deselected after entering contra currencies, the application stops calculating cross rates going forward for that particular rate type. All the earlier calculated cross rates for that rate type remain in the database unless you manually delete them.

For example, if you have daily rates defined for the pivot currency, USD to the contra currency, EUR, and USD to another contra currency, CAD, the application automatically creates the rates between EUR to CAD and CAD to EUR. You don't have to manually define the EUR to CAD and CAD to EUR rates.

Select the Allow Cross Rates Override check box to permit your users to override application generated cross rates. If you accept the default of not selected, the application generated cross rates can't be overridden.

Maintain Cross Rate Rules

Define or update your cross rate rules at any time by adding or removing contra currency assignments. Add a contra currency to a cross rate rule and run the Daily Rates Import and Calculation process to generate the new rates. If you remove a cross rate rule or a contra currency from a rule, any cross rates generated previously for that contra currency remain unless you manually delete them. Changes to the rule aren't retroactive and don't affect previously stored cross rates. The Cross Rate process generates as many rates as possible and skips currencies where one component of the set is missing.

Note: With a defined web service that extracts daily currency conversion rates from external services, for example Reuters, currency conversion rates are automatically updated for the daily rates and all cross currency relationships.

The four predefined conversion rate types are:


You are the general ledger accountant for Vision US Inc. You are entering a journal entry to capture three transactions that were transacted in three different foreign currencies.

  • Canadian Dollar CAD: A stable currency

  • Mexican Peso MXP: A fluctuating currency

  • Hong Kong Dollar HKD: An infrequently used currency

You enter two journal lines with accounts and amounts for each foreign currency transaction. Based on your company procedures, you select the rate type to populate the rate for Corporate and Spot rate types from your daily rates table. You manually enter the current rate for the User rate type.

The following table lists the currency, the rate type that you select, and the reasons for the rate type selection.

Selected Currency Selected Rate Type Reason



Entered a periodic type of transaction. Your company has established a daily rate to use for the entire month across divisions for all transactions in Canadian dollars, a stable currency that fluctuates only slightly over the month.



Entered a periodic type of transaction. Your company enters daily rates each day for the Mexican peso because the currency is unstable and fluctuates.



Entered a one time transaction. Your company doesn't maintain daily rates for Hong Kong dollars.

Your company doesn't currently use the Fixed rate type. From January 1, 1999, the conversion rate of the French franc FRF against the Euro EUR was a fixed rate of 1 EUR to 6.55957 FRF. Your French operations were started in 2007, so you maintain all your French business records in the Euro.

FAQs for Manage Conversion Rate Types

Spot, corporate, user, and fixed conversion rate types differ based on fluctuations of the entered foreign currency and your company procedures for maintaining daily rates.

  • Spot: For currencies with fluctuating conversion rates, or when exact currency conversion is needed.

  • Corporate: For setting a standard rate across your organization for a stable currency.

  • User: For infrequent entries where daily rates for the entered foreign currency aren't set up.

  • Fixed: For rates where the conversion is constant between two currencies.

If you have infrequent foreign currency transactions, the User rate type can simplify currency maintenance. The User rate type can also provide an accurate conversion rate on the date of the transaction.

The statistical unit currency type denotes the Statistical (STAT) currency used to record financial statistics in the financial reports, allocation formulas, and other calculations.

Daily Currency Rates

Oracle Cloud ERP has various options to load currency rates. In Oracle Cloud ERP, daily currency conversion rates can be maintained between any two currencies. You can enter daily conversion rates for specific combinations of foreign currency, date, and conversion rate type. Oracle Cloud ERP automatically calculates inverse rates. You can override the inverse rates that are automatically calculated.

The three different methods of loading currency rates are:

  1. Manual load using the Create Daily Rates spreadsheet.

  2. Manual load using the Import and Calculate Daily Rates file-based data import.

  3. Automatic load using web services.

You're required to change today's daily rates that were already entered. The rates you're changing are for currency conversion from Great Britain pounds sterling (GBP) to United States dollars (USD) for your company InFusion America.

Currency conversion rates were entered by an automatic load to the Daily Rates table. They can also be entered through a spreadsheet.

Updating Currency Rates

  1. Navigate to the Period Close work area.

    Use the Period Close work area to link to close processes and currency process.

  2. Click the Manage Currency Rates link.

    Use the Currency Rates Manager page to create, edit, and review currency rate types, daily rates, and historical rates.

  3. Click the Daily Rates tab.

    Use the Daily Rates tab to review and enter currency rates.

  4. Click the From Currency list. Select the GBP - Pound Sterling list item.

  5. Click the To Currency list. Select the USD - US Dollar list item.

  6. Enter the dates for the daily rates that you are changing. Enter today's date.

  7. Click the Rate Type list. Select the Spot list item.

  8. Click the Search button.

  9. Click in the Rate field. Enter the new rate of 1.7 in the Rate field.

  10. Click in the Inverse Rate field. Enter the new inverse rate of 0.58822 in the Inverse Rate field.

  11. Click the Save button.