2Journals

This chapter contains the following:

Accounting Cycle
Journal Capture
Create Standard Journals
Create Journals in Spreadsheets
Reverse Journals
Post Journals
Approve Journals
FAQs for Journals

Accounting Cycle

Example of an Accounting Cycle

This example demonstrates the steps in completing the accounting cycle to achieve successful financial reporting for your enterprise. These steps may vary based on your business processes and enterprise structure.

Scenario

Your company, InFusion Corporation, is a multinational conglomerate that operates in the United States (US) and the United Kingdom (UK). InFusion Corporation:

Uses Oracle Fusion General Ledger and all of the Oracle Fusion subledgers.
Includes all the components to build and maintain air quality monitoring systems for homes and businesses in your business line.
Provides funding to your customers for the start up costs of these systems through your financial services organization.
Purchases raw materials from other countries, which requires you to record foreign currency transactions.
Consists of three subsidiaries.
- InFusion Financial Services
- InFusion UK Services
- InFusion America
Consolidates financials with all its subsidiaries monthly in the parent, InFusion Corporation ledger.

The following are the tasks that your staff performs to complete the accounting cycle and ensure accurate capturing of your accounting transactions.

Open the accounting period.
Enter manual journal entries: standard, statistical, and intercompany balancing journal entries between your parent company and your three subsidiaries.
Import journals from your subledgers. Correct or delete journal entries that failed the import process. If necessary, run the import process again.
Define journals that occur periodically and allocation journal formulas for transactions that have a common format, require allocation of amounts or accounts to other accounts, or that are entered frequently.
Generate recurring and allocation journal batches based on your defined formulas.
Review the details of the unposted journal batches.
Edit unposted journals to change or correct information, including the batch period and the journal currency.
Post journal batches manually or automatically.
Check for posting errors. Use the Posting Execution Report and the Automatic Posting Execution Report to check the results of your posting. These reports are created automatically when the posting programs are completed.
Reverse posted journals as needed. Assign a reversing period to the journal, generate the journal, and post the reversing batch.

Note: Journals can be set to automatically reverse when you open the period. Subsequent adjustments to the accounts are then based on balances net of those reversals.
Revalue foreign currency denominated balances to reflect conversion rate fluctuations at the end of the accounting period.
Translate actual account balances in your UK subsidiary to US dollars to report to your US parent. You consolidate the ledgers for all your subsidiaries in US dollars.
Consolidate ledgers by defining and running a consolidation for all your subsidiaries.
Produce financial reports and perform online inquiries to review current account balances.
Close the current accounting period.
Open the next accounting period.

How to Prevent a General Ledger Period from Closing When Open Subledger Periods Exist

You can prevent a General Ledger accounting period from closing when any, or some of the corresponding subledgers are still open, or the period has incomplete accounting entries or transactions. This can help ensure an effective period close process that validates all transactions are complete and aren't held up during the close.

Exceptions That Prevent a Period from Closing

Here are the period status exceptions.

Subledger accounting periods aren't closed

Here are the transaction exceptions.

Unprocessed and untransferred subledger transactions
Pending Intercompany transactions
Pending transactions in the General Ledger interface
Unposted transactions in General Ledger

Note: Currently, primary ledgers use this feature.

Benefits

Here are the benefits.

Brings the General Ledger period close process in line with corporate-wide business policy, if any.

Helps you comply with the general business practice of not allowing a closed General Ledger period to be reopened unless there are material changes. In general, periods aren't reopened unless there are strong justifications and related approvals. By using this feature, you might not need to reopen a closed period, because you already ensured that all unprocessed transactions and exceptions were duly resolved before closing it.
Provides more meaningful and accurate financial reporting, because all exceptions would have been resolved and accounted for, before reporting.
Helps you comply with audit requirements, if any.

How to Set It Up

Go to the following:
- Offering: Financials
- Functional Area: General Ledger
- Task: Specify Ledger Options, with the primary ledger scope set
In the Period Close section, select the Prevent General Ledger Period Closure When Open Subledger Periods Exist option.

Here's an image of the ledger option and field help on the Specify Ledger Options page.
Save the change.

How to Optionally Exclude Specific Subledgers

When you set the ledger option, by default the General Ledger Period Close process checks these subledgers for period status exceptions: Cost Management, Payables, Receivables, Projects Foundation, and Revenue Management. You can optionally exclude one or more of them, so the General Ledger period close process skips the period status exceptions encountered within the context of the excluded subledgers. The transaction exceptions previously listed are still checked and period close prevented if the process encounters such exceptions.

Note: You need to set up subledger exclusions and re-inclusions only once, to apply to every primary ledger for which the Prevent General Ledger Period Closure When Open Subledger Periods Exist option is enabled.

Go to the following:
- Offering: Financials
- Functional Area: General Ledger
- Task: Manage General Ledger Lookup Values
In the Lookup Type field, enter ORA_GL_INCLD_STRICT_PRD_CLOSE and click Search.

Here's an image of the search results with the list of subledgers.
Click in the Enabled field to deselect the subledger that you want to exclude.

Note: Select the Enabled field to reinstate a previously excluded subledger.
Save your changes.

Example of How It Works

Let's say you enabled the ledger option for your primary ledger Vision Corporation and you didn't exclude any subledgers. The December 2019 period is open for both General Ledger and the Payables subledger. When you go to close the December 2019 General Ledger accounting period from either the Manage Accounting Periods or Edit Accounting Period Statuses pages, an error message will appear telling you the option is enabled and that the Payables subledger is still open. Instead, if you submit the period close process from the Scheduled Processes page, this same message will appear in the process log files. The rest of the message helps get you started with processing the pending transactions and resolving exceptions.

Note: When you run the period close process from the application pages, an error message appears when the subledger periods aren't yet closed. Error messages for any other exception, and in all cases when the period close process is submitted from the Scheduled Processes page, appear in the close period process log files. This is to optimize the performance of the period close process.

Journal Capture

Journal Capture Options

The ledger and subledger transactions are captured in four ways:

Entering journals manually
Entering journals in spreadsheets
Importing journals
Creating journals automatically

Use of these methods varies depending on:

The application providing the data
The reason for the entry, such as error correction versus monthly entries
The tools available, such as the calculation engine used in the automation of journal entries

Entering Journals Manually

Enter journals manually that occur once or infrequently, such as journals to:

Correct errors
Reclassify account balances
Accrue balances for unusual transactions

This method requires the most time and is open to errors from human intervention.

Entering Journals in Spreadsheets

Enter manual and recurring journal entries through a spreadsheet interface. Then:

Load the completed spreadsheet into the import interface.
Schedule or manually submit the Journal Import process to import the data into the ledger.

Working in spreadsheets adds functionality such as the use of macros, formulas, and links to existing documents.

Note: Spreadsheets are created as templates for recurring entries and then each month, simply update the data and upload.

Importing Journals

Use Oracle Fusion Subledger Accounting to submit journal entries from subledger applications to the import interface to prepare for data transfer into the ledger. Subledger applications include both Oracle and non-Oracle. Then:

Schedule or manually submit the Journal Import process to perform the import.
Verify that the data is transferred completely and accurately.

This method efficiently and correctly populates the bulk of the data in the ledger.

Creating Journals Automatically

In Oracle Fusion General Ledger, create journal entries automatically to automate processes and reduce both errors and data entry time. For example:

Define allocation rules and rule sets in the Oracle Fusion Calculation Manager. Then:
- Generate your defined allocation formulas to automatically populate the allocated data to the import interface.
- Schedule or manually submit the Journal Import process to import the journal lines into the general ledger to create unposted allocation batches.
- Post automatically during the generate process or manually to allocate data from amounts or accounts to other accounts on a periodic basis.
Define journal reversal criteria sets for specific journal categories to automatically create reversal journal entries. Schedule or manually submit the AutoReverse process. The process creates journal entries when it reverses the journals that match the criteria specified.
Define revaluation definitions to properly account for unrealized gains and losses on currency exchange fluctuations. Then:
- Schedule or manually submit the Revaluation process.
- Post the revaluation journal batch.
The process adjusts the respective foreign currency denominated asset or liability to its current accounted value. The adjustment is offset to the unrealized gain or loss account.
Use the Balances Transfer process for generic cross ledger balance transfers. This process:
- Transfers copies of the data from your source ledgers to your target ledgers.
- Initiates this process at periodic intervals as needed.
- Automatically creates postable journal entries that update account balances in the target ledger with a journal source of Balance Transfer.
- Is used to transfer specifically from the primary ledger to its balance level secondary ledger.
- Uses the primary ledger as the journal source.

Create Standard Journals

Overview of Journal Entry and Actions

Journal entries are posted to the ledger to record data from accounting transactions that reflect your entity's business events. Journal creation, approval, posting, and editing work together in the recording process to produce accurate financial records.

Creating Journal Entries

The process begins with creating journals. You can create journals in several ways:

Enter manually directly in the ledger.
Use a spreadsheet interface.
Import journals into the ledger.
Create automatically from formulas or processes.

All methods produce a journal entry consisting of:

A batch that determines the accounting period of all journals associated with the batch.
One or more journals, with a category and a currency assigned to each.

Note: For cross-currency journals, the currency is assigned at the line level.
Lines that contain the accounting for the transaction.

Note: You can view the combined description for the entire account combination on all lines simultaneously during journal entry.

Save to create the journal entry. Complete the journal to submit it for posting. After creation, apply an optional journal approval process to the entry.

A journal entry that has been saved, completed, and, if necessary, approved, is available for posting.

Approving Journal Entries

If you're using journal approval, you can select the Request Approval action for the journal batch to initiate the approval process. After the batch is approved, you must then post it. If you skip the action of requesting approval, and instead select to post the batch, or if the batch is picked up for posting through an AutoPost criteria set, the batch proceeds through the approval process, after which posting is automatically submitted.

Note: You can edit approved journals that aren't posted. After you make your changes, you must resubmit the journal for approval. For more information, see this topic: Can I edit a journal that's approved and not yet posted?

Posting Journal Entries

You can post journal entries only in open accounting periods. Keep all but the current periods closed to prevent posting of amounts in incorrect periods. During the posting process, the journal entry is validated and, if successful, the credit and debit amounts are updated to their respective accounts in the ledger. You can't change a journal entry that's posted.

Once posting has finished successfully, run reports and performs queries on the updated account balances in the ledger.

Note: You can configure security using the Post privilege to allow certain users to review and post journals, but not create or modify them.

Editing Journal Entries

Edit journal entries as needed before they're posted. After posting, either reverse and enter the journal again, or enter a new journal to correct the amounts in question.

Journal Entry Components

Journal entries post accounting balances to the ledger for reporting and analysis.

Journal entries consist of three components: a batch, journals, and lines. You can organize journals with common attributes into batches. The journal information identifies common details for a single journal entry. The lines specify the accounting information for the journal entry. Batches can multiple journals and journals can have multiple lines.

The following figure shows the three journal components and the data required for each component.

This figure shows the components of a journal and
the data required for each component.

Batch

A batch can contain multiple journals, each of which can belong to a different ledger. All of the ledgers within a batch must have the same accounting calendar and chart of accounts. Batches require a name, source, and accounting period. All journal entries in a batch must share the same period. You can create a journal batch by entering a user-defined name in an open or future enterable accounting period. You must post batches in open accounting periods. If you don't want to enter the batch information, start by entering data in the Journals section on the Create Journal page. The batch name is created automatically using the following components:

Journal source name of manual
A unique batch
System date

Journals

A journal requires the following data:

Ledger name
Journal name
Accounting date
Source
Category
Currency

Note: The description and control total are optional.

To select the ledger from the choice list, your data access set must provide one of the following

Read and write access to the ledger
Read and write access to one or more balancing or management segment values

If you use reporting currencies or secondary ledgers with a journal or subledger conversion level, select a reporting currencies or secondary ledger for your journal. Creating manual journals is an exception for the secondary and reporting ledgers because their journals propagate directly from their primary ledger.

Lines

The lines require accounts and amounts. Total debits must equal total credits for all journal entries except for statistical journal entries.

Single or Multiple Journal Batches

Entering journal batches is optional. The application creates a unique batch ID automatically; using the journal entry name combined with the system date and time. All journal entries in a batch must share the same accounting period. Enter journals only in a current or future enterable accounting period. Batches can contain one or an unlimited number of journal entries. When you post one journal entry, the entire batch posts. Posting is always done at the batch level.

Using a Single Batch

You can record a set of journal entries in a single batch. For example, all of your statistical entries or monthly accruals can be entered in one batch for easy reference, querying, and posting.

Using Multiple Batches

Use multiple batches when it's important for each journal entry to be reversed separately or to document a specific transaction or adjustment.

Example of Statistical Journal Entry

This example uses headcount to illustrate how a company can record statistical information in a journal entry. The posted statistical balances can then be used in journal entries that allocate expenses.

Scenario

InFusion America Incorporated hires thirty new employees and assigns them to the sales, accounting, and purchasing departments. To allocate expenses properly, InFusion America Incorporated must track headcount for each department.

Transaction Details

The thirty new employees are assigned as follows:

Twelve to the sales department

Ten to the accounting department

Eight to the purchasing department

Analysis

The sales department has expanded its territory and needs twelve new employees to cover the new areas. The sales force works in the field and has travel expenses.

The accounting department has lost four employees to retirement so needs four new employees to fill those vacated positions. The accounting department also added six new positions to handle the expected increase in sales. Accounting employees work in a central office, and the department allocates expenses across other departments.

The purchasing department has added four new buyer positions and four new warehouse positions to handle the expected increase in orders. Purchasing employees work in the warehouse and participate in InFusion America Incorporated health insurance plan.

Resulting Statistical Journal Entry

The following table shows the journal entry that was created, using the STAT currency, to capture the headcount information for each department.

Department	Department Number	Debits	Credits	Description
Sales	200	12		Sales force addition due to territory expansion.
Accounting	300	10	4	Addition of six new positions and the loss of four due to retirement, which requires four new employees.
Purchasing	500	8		Addition of four buyers and four warehouse positions.
Total	Not Applicable	30	4	Not Applicable

Note: In statistical entries, debits aren't required to equal credits.

Enter Foreign Currency Journals

This example demonstrates how to create a journal entry in a foreign currency. Your company, InFusion America, has purchased a new truck from a company located in the United Kingdom. The price is in British pounds (GBP) and your ledger currency is United States dollars (USD). When the cost was booked in purchasing, the freight costs weren't included. You must enter a manual journal entry for the missing freight costs.

Follow these steps to enter a manual journal entry using a foreign currency. A currency is classified as foreign if it isn't your ledger currency or a reporting currency you're using with the journal or subledger level reporting currency functionality.

Entering a Foreign Currency Journal

Navigate to the Manage Journals page and select the Create Journal task.

Complete the fields, as shown in this table.

Field	Value
Batch Name	UK Sales Adjustment
Batch Description	Freight costs on purchase of a truck
Journal Name	UK Sales Adjustment
Journal Description	Freight costs on purchase of a truck
Category	Adjustment
Currency	GBP
Conversion Rate Type	User
Conversion Rate	1.59
Debit Account	Your purchase account
Debit Amount	500
Credit Account	Your payables account
Credit Amount	-500

Click Post.

The application saves, completes, and posts the entry.

Note: In this example, the conversion rate type of User was selected, which requires you to enter the conversion rate. Other conversion rate types are Spot, Corporate, or user-defined. These other conversion rate types can automatically enter the conversion rate based on the data in the daily rates tables and the conversion date. Select a conversion date within the accounting period that you defined for the journal entry. The conversion date field lets you select other dates to use a different daily rate. The default conversion date is equal to the journal accounting date.

How You Require Manual Journals Balance by Entered Currency

You can require that manual journals balance by entered currency when a journal is created. So when a journal preparer creates a journal on the Create Journal page or Create Journal spreadsheet, total debits must equal total credits for each entered currency, otherwise the journal can't be saved.

This also means that the journal posting process doesn't have to generate additional lines to balance the journal. The posting process continues to balance any unbalanced journals coming in through external feeds.

Here's how you set it up.

In the Setup and Maintenance work area, go to the Specify Ledger Options task:
- Offering: Financials
- Functional Area: General Ledger
- Task: Specify Ledger Options, with the primary ledger scope set
On the Specify Ledger Options page, enable the Require manually entered journals balance by currency option in the Journal Processing Balancing section. The option is automatically enabled for any associated secondary ledgers and reporting currencies.

How You Limit a Journal to a Single Currency

You can enforce single currency journals for a journal source. The limit applies to journals entered on the Create Journal page and to journals that are imported. The Import Journals process automatically separates the journals by currency.

Here's how you set it up.

In the Setup and Maintenance work area, go to the Specify Ledger Options task:
- Offering: Financials
- Functional Area: General Ledger
- Task: Specify Ledger Options, with the primary ledger scope set
On the Specify Ledger Options page, enable the Limit a journal to a single currency option in the Journal Processing Entry section. The option is automatically enabled for any associated secondary ledgers and reporting currencies.
Go to the Manage Journal Sources task:
- Offering: Financials
- Functional Area: General Ledger
- Task: Manage Journal Sources
On the Manage Journal Sources page, enable the Limit Journal to Single Currency option for the applicable journal sources.

Note: You can't enable the option for these journal sources: Allocations, AutoCopy, Balance Transfer, Closing Journal, and Revaluation.

How Journal Import Data Is Processed

Use the Journal Import file-based data import to upload journal entry data from external sources into Oracle Fusion General Ledger. You can download a spreadsheet template to use to prepare your journal entry data. The template contains an instruction sheet to help guide you through the process of entering your journal information.

To access the template, complete the following steps:

Navigate to the File-Based Data Import for Oracle Financials Cloud guide.
In the Table of Contents, click File-Based Data Imports.
Click Journal Import.
In the File Links section, click the link to the Excel template.

Follow these guidelines when preparing your data in the worksheet:

Enter the required information for each column. Refer to the tool tips on each column header for detailed instructions.
Don't change the order of the columns in the template.
You can hide or skip the columns you don't use, but don't delete them.

Settings That Affect the Journal Import Process

The Journal Import template contains an instructions tab and a tab that represents the table where the data is loaded.

The Instructions and CSV Generation tab contains information about:

Preparing the journal data.
Understanding the format of the template.
Entering journals.
Loading the data into the interface table and the product.

The GL_INTERFACE tab is where you enter information about the journals that you're adding, such as the journal source, category, currency, and amount.

How Journal Import Is Processed

To load the data into the interface table:

Click the Generate CSV File button on the instructions tab to create a CSV file in a .zip file format.
Save the .zip file locally.
Navigate to the Scheduled Processes work area.
Select the Load Interface File for Import process.
For the Import Process parameter, select Import Journals.
For the Data File parameter, select the file that you saved in step 1.

To load the data from the interface table into the product:

Navigate to the Journals work area and select the Import Journals task.
Enter values for the parameters.
If the process ends in error or warning, you can correct or delete the rows that have errors.
1. To correct the rows with errors:
  1. Review the log and output files for details about the rows that caused the failure.
  2. Navigate to the Journals work area and select the Correct Import Errors task to download the journal corrections worksheet.
  3. Search for the errors rows using the Source and Group ID fields.
  4. Correct the entries in the worksheet and click Upload. If you select to save to the interface, you must rerun the Import Journals process.
2. To delete the rows with errors:
  1. Navigate to the Journals work area and select the Delete Import Data task.
  2. Provide values for the required parameters. For the Process ID parameter, specify the ID for the Import Journals process.

To delete the data from the interface table without loading into the product, while the status of the interface rows is NEW:

Navigate to the Scheduled Processes work area and select the Purge Interface Tables process.
Accept the default value of File-based data import for the Purge Process Intent parameter.
Select Import Journals for the Import Process parameter.
Enter the process ID from the Load Interface File for Import process into the Load Request ID parameter.

Related Topics

File-Based Data Import for Oracle Financials Cloud

Financial Descriptive Flexfields

In Oracle Fusion Financial Applications, the descriptive flexfields are available from either the Basic or Advanced Search sections for all transaction objects that have Secure Enterprise Search (SES) enabled.

Examples of the descriptive flexfields available are:

Oracle Fusion Payables: Invoices
Oracle Fusion Receivables: Adjustments
Oracle Fusion Expenses: Expense
Oracle Fusion Assets: Assets Invoices
Intercompany: Intercompany Transaction Headers (Inbound Transaction)
Intercompany: Intercompany Transaction Batches (Outbound Transaction)
Oracle Fusion General Ledger: Journal Batches
Oracle Fusion General Ledger: Journals
Oracle Fusion Subledger Accounting: Subledger Journal Entry Header

Descriptive flexfields consists of segments.

The following table lists the descriptive flexfield segments.

Segment	Description
Global Segment	Are always displayed, if enabled.
Context Segment	Used to determine which context sensitive segments are displayed.
Context Sensitive Segment	Displayed values based on the defined value in the context segment.

In some products, the descriptive flexfields are displayed by default in the Search section, while others are available in the Add Fields menu.

Global Segments: Generally available in the Add Fields menu if they're not displayed by default. When a Global Segment is added to a Search Panel, it's displayed before the context segments.
Context Segments: Generally available in the Advanced Search section by default.
Context Sensitive Segments: Available in the Add Fields menu after you select a context segment value.
The segments are displayed in the Search Panel in the following order:
1. Global Segments
2. Context Segments
3. Context Sensitive Segments, after their Context Segment

Note:

The list of values on the Add Fields menu lists all descriptive flexfields alphabetically, followed by all other fields alphabetically.
If more than one global segment is defined, then all global segments are displayed in the Search panel in the sequence defined by you, the user, followed by context segments.
Similarly for context segments, all context segments are displayed in the Search panel in your defined sequence defined order.
When context sensitive segments are added to a Search panel, they're also displayed in your defined sequence order.

Related Topics

How You Search for Journal Descriptive Flexfields

Use descriptive flexfields to define and store additional information for journals. You have the capability to retrieve the information from descriptive flexfields by using the Advanced Search in the Manage Journals Search panel.

The two descriptive flexfields available for search on the journal pages are in the following regions:

Journal Batches
Journals

You can search using global and context segments, and both are available from the Advanced Search panel. After adding the context segment, a value is selected and a list of context-sensitive segments become available in the Add Fields.

Example of Additional Journal Information with Descriptive Flexfields Based on Ledger or Account Value

This example shows how to capture additional journal line information in the context of a specific ledger or natural account segment value, during journal entry.

Scenario

Your company has multiple ledgers. When entering journal lines for the Vision Corporation ledger, users must enter a source voucher number as additional information. For the Spruce Street Foods ledger, users must enter both a source voucher number and a source voucher date. The remaining ledgers don't have to track this information.

In addition, when entering journals, if the natural account segment in an account combination has a value of 7620, which represents legal expenses, users must provide a litigation file number. If the segment value is 52310, which represents insurance expenses, users must provide the name of the insurer and the policy number.

Configuring General Ledger Descriptive Flexfields

Before configuring the descriptive flexfield for source voucher information, you must find the ledger ID for each ledger. Use the Manage Primary Ledgers task in the Setup and Maintenance work area. If the Ledger ID column isn't displayed, click Columns, Ledger ID, from the View menu. In this example, the ledger ID for Vision Corporation is 1000, and the ledger ID for Spruce Street Foods is 1225.

Analysis

To capture the source voucher information, use the Manage General Ledger Descriptive Flexfields task in the Setup and Maintenance work area. Create a context segment for the Journal Lines descriptive flexfield with ledger ID as the context segment value. Set up the value to automatically default from the Ledger ID parameter.

The following image shows the Context Segment section on the Edit Descriptive Flexfield page for the Journal Lines flexfield, which has the flexfield code GL_JE_LINES. The context segment has a prompt of Ledger Details, a default type of Parameter, a default value of Ledger ID, a derivation value of Ledger ID, and a display type of List of Values.

This image shows a context segment that's configured
for the ledger ID.

Next, define a context-sensitive segment for the source voucher number, within the context of the Vision Corporation ledger. Set the context code to 1000, and set the segment to required. Then, define context-sensitive segments for the source voucher number and source voucher dates, within the context of the Spruce Street Foods ledger. Set the context code to 1225 and set both segments to required.

The following image shows part of the Edit Context page for the Spruce Street Foods ledger context with the two context-sensitive segments.

This image shows the context segment for the Spruce
Street Foods ledger, which has a ledger ID of 1225. The context segment
has two context-sensitive segments, one named Source Voucher Number
and the other named Source Voucher Date. Both context-sensitive segments
use the Character data type and are set to display in a text box.

Similarly, to capture information that's based on natural account segment values, create a context segment for the Journals Captured Information descriptive flexfield (flexfield code GL_CAPTURED_INFO) with natural account as the context segment value. Set up the value to automatically default from the Natural Account parameter.

Next, define a context-sensitive segment for the litigation file number, within the context of the legal expenses account. Set the context code to 7620 and set the segment to required. Then, define context-sensitive segments for the insurer and policy number, within the context of the insurance expenses account. Set the context code to 52310 and set both segments to required.

Deploy each descriptive flexfield after the setup is complete.

Resulting Prompts During Journal Line Entry

The prompts for providing the additional information appear on both the Create Journal page and the Create Journal spreadsheet, which you open using the Create Journal in Spreadsheet task. If prompted, you must provide the information to save the journal.

The following image shows part of the Journal Lines section on the Create Journal page. The ledger for the journal is Vision Corporation, and the natural account segment value on the journal line is 7620. The Source Voucher Number and Litigation File Number fields are required. The values for the context segment prompts of Ledger Details and Account Number are automatically defaulted.

This image shows journal line 1 with fields for
capturing additional information. The Ledger Details field displays
Vision Corporation, which is the ledger for the journal, and the Account
Number field displays 7620.

When entering journal lines for the Spruce Street Foods ledger and the insurance expenses account, users must provide a source voucher number, source voucher date, name of the insurer, and policy number. Journal lines with natural account segment values other than 52310 only require a source voucher number and date.

The following image shows part of the Journal Lines section on the Create Journal page. The ledger for the journal is Spruce Street Foods, and the natural account segment value on the journal line is 52310. The Source Voucher Number, Source Voucher Date, Insurer's Name, and Policy Number fields are required. The values for the context segment prompts of Ledger Details and Account Number are automatically defaulted.

This image shows journal line 1 with fields for
capturing additional information. The Ledger Details field displays
Spruce Street Foods, which is the ledger for the journal, and the
Account Number field displays 52310.

Related Topics

Overview of Descriptive Flexfields

Create Journals in Spreadsheets

How You Create Journals in Workbooks

You can use the Create Journals workbook for high volume journal entry. You can prepare the journals offline, distribute the workbooks for review, or save the journals for recurring entry.

Setup

Before you can use the Create Journals workbook, you must install an Excel add-in. Navigate to the Tools work area and select the Download Desktop Integration Installer link.

You can optionally set a profile option to require that journals entered in workbooks balance, regardless of the suspense setting on the Specify Ledger Options page. To set the profile option as needed, use the Manage General Ledger Profile Options task in the Setup and Maintenance work area. The name of the profile option is Journals: Balanced Spreadsheet Journals Required.

Download

To download the Create Journals workbook, navigate to the Journals work area and select the Create Journal in Spreadsheet task.

Note: If you use encumbrance accounting, select the Create Encumbrance Journal in Spreadsheet task.

Journal Entry

The Create Journals workbook has two worksheets. On the Single Journal worksheet, you can create a journal for one ledger, similar to using the Create Journal page in the application. On the Multiple Journals worksheet, you can create multiple journals and multiple journal batches for different ledgers.

Submission

When you're ready to submit the journals for processing, click Submit on the Create Journal ribbon. Some initial validations are performed, such as verifying that you provided an accounting date and a valid journal category. The validation results display in the Status Viewer pane on the worksheet.

Note: If you enable the Journals: Balanced Spreadsheet Journals Required profile option, then the journals must balance before you can upload. The journals must also balance if you don't enable this profile option and also don't enable suspense accounting.

Make the necessary corrections and resubmit the worksheet. On the Submission Options window, accept the default selection or select one of the other options:

Save to Interface: If you select this option, you must submit the import and posting process later to create and post the journals.
Submit Journal Import: If you select this option, you must submit the posting process later to post the journals.
Submit Journal Import and Posting (default selection)

You can also select from among these additional options:

Import Descriptive Flexfields: If you selected one of the import options, you can also specify whether to import descriptive flexfields and validate them.
Defer Account Validations to Journal Import: If you plan to load a high volume of data, this option can improve the performance of the workbook. When you select this option, the account combinations used in the workbook aren't validated or created during the workbook upload. Instead, the Import Journals process creates the account combinations and performs these validations.

Note: When this option is selected, journals being created aren't checked against third-party control accounts.
Send Email Notification for Journal Import Failures: If you select one of the import options, you can also receive email notifications for warnings or failures encountered during the journal import process.

Related Topics

Examples of Balancing Validations in Journal Workbook Upload

The Create Journals workbook has validations on the Single Journal and Multiple Journals worksheets. The validations ensure that unbalanced actual journals aren't uploaded when suspense accounting isn't enabled for the ledger or when the Journals: Balanced Spreadsheet Journals Required profile isn't enabled. Validation is affected by the way journals are grouped and classified.

Journal lines are grouped into one journal if the following data is the same:

Journal Batch Name and Description
Source
Journal Name and Description
Ledger
Category
Clearing Company
Legal Entity

The legal entity is used as a grouping criterion only when sequencing is enabled at the legal entity level for your ledger.

Journals are classified as single currency journals if all the journal lines have the same data for these fields:

Currency
Conversion Rate Type
Conversion Rate
Conversion Date

Any journal which doesn't qualify as a single currency journal is classified as a multicurrency journal. Different criteria is used to validate the balancing of single and multicurrency journals.

A single currency journal is unbalanced if:

Entered amounts are not equal or
The percentage difference in the accounted amounts is equal to or greater than the Balancing Threshold Percentage on the Specify Ledger Options page.

Note: If any of the journals on the worksheet aren't balanced, then none of the journals on the worksheet are uploaded.

Journal Validation Examples

Example 1: A single currency journal with unequal accounted debit and accounted credit amounts.

On the Specify Ledger Options page, set:
- Currency: USD
- Enable Suspense is not checked for General Ledger
- Balancing Threshold Percent = 1 percent
Here are the details for the Multiple Journals worksheet:
- Journal Batch: Year End Adjustments
- Journal: Bad debt adjustment
- Ledger: Vision Operations (USA)
- Accounting Date: 9/30/17
- Source: Spreadsheet
- Category: Adjustment
- Currency for each line: EUR
- Entered Debit: 240
- Entered Credit 240
- Accounted Debit: 270.4
- Accounted Credit: 270.82

This journal has a single currency. The entered debit amount is equal to the entered credit amount, but the accounted debit and credit amounts are different. The percentage difference of the accounted amounts is (0.42/270.82)*100 = 0.155 percent. The percentage difference is less than the 1 percent threshold provided on the Specify Ledger Options page. Hence the journal is balanced.

Example 2: A multicurrency journal that is not balanced by clearing company.

On the Specify Ledger Options page, set:
- Currency: USD
- Enable Suspense option is not checked for General Ledger
- Balancing Threshold Percent = 1 percent
- Enable intercompany accounting option is checked
Here are the details for the Multiple Journals worksheet:
- Journal Batch: Intercompany accruals
- Journal: Rent accruals
- Ledger: Vision Operations (USA)
- Accounting Date: 9/30/17
- Source: Spreadsheet
- Category: Accrual
- Currency on all journals line: USD
- Clearing company on journals lines: 99, 98
- Total Entered Debit for all journal lines: 2300
- Total Entered Credit for all journal lines: 2300
- Total Entered Credit for lines with clearing company 99: 2300
- Total Entered Debit for lines with clearing company 99: 0
- Total Entered Credit for lines with clearing company 98: 0
- Total Entered Debit for lines with clearing company 98: 2300

This journal has a single currency and two clearing companies. The clearing company was used as the grouping criterion. The lines with clearing company 99 are grouped into one journal and the lines with clearing company 98 are grouped into another. So although the journal name is the same, the validation evaluates each group of clearing company lines as a separate journal. Both of these journals are unbalanced since one has the credit amount and the other has the debit amount.

How Journals Are Imported

Oracle Fusion Financials reflect the traditional segregation between the Oracle General Ledger and associated subledgers. Detailed transactional information is captured in the subledgers and periodically imported and posted in summary or detail to the General Ledger. You import from the subledgers to the General Ledger in real time or you can import and post automatically based on a defined schedule. Once the data is posted in the General Ledger, the data is available for balance inquiry and reporting.

Use journal import to integrate transactions from other applications such as payroll, accounts receivable, accounts payable, and fixed assets with your General Ledger. You can import ledger currency and foreign currency encumbrance journals, if encumbrance accounting has been enabled for the ledger.

For each accounting period, you import accounting data from the subledger application, then review, update, and post the journal entries. You can also use journal import to import historical data from your previous accounting application. Import data from multiple interface tables by entering a particular source and group ID combination for the data in each interface table. Journal import processes data from one table at a time.

The following table lists the effect of security privileges on the journal import process.

Security Privilege	Journal Import
Control Accounts	Not blocked.
Segment Value Security	If the account combination exists, then no check happens. If the journal import process creates an account combination, then segment value security is enforced.
Cross-Validation Rules	If the account combination exists, then no check happens. If the journal import process creates an account combination, then cross-validation rules are enforced.

Settings That Affect Journal Import

Configure the following settings before running the Import Journals process.

Set up your General Ledger to accept journal import data by defining your ledger, currencies, accounts, journal sources, and categories.
Optionally, run the Optimizer process to ensure optimal system performance.
Define your import process parameters and schedule, if using automatic processing.
Set the period status to either future enterable or open. Journals can be created by the journal import process in a future enterable period, but not posted. Posting requires an open period.
Export data from your subledgers and populate the General Ledger Interface table.
Optionally, enable encumbrance accounting.

How Journal Import Is Processed

Transactions can be imported into General Ledger from Oracle subledgers and legacy applications.

The flow of accounting data includes the following steps:

The transaction data entered in both Oracle and legacy application subledgers is imported into the General Ledger Interface table. If the process completes successfully, journal entries are created. If the process fails, the error lines are loaded into the corrections spreadsheet or are deleted using the Delete Journal Import Data process. After correcting the errors or deleting the error lines, run the Import Journals process again.
After the journal entries are created in the General Ledger from the imported data, post the journals. The posting process validates the data and records it in both the General Ledger Balances table and the balances cube. Posting errors are listed in the Posting Execution report and can also be viewed in the Journals dashboard and on the Manage Journals page. After correcting the errors, run the posting process again.
After posting completes, the data is available for reporting and balance inquiry.

The following figure outlines the flow of accounting data between the subledgers and General Ledger.

This figure shows the accounting data flow between
subledgers or legacy applications, and General Ledger.

Note: The journal import process is used to import data and create journals for several General Ledger processes, for example, allocations, revaluations, and balance transfers.

Related Topics

Error Codes for Journal Import

Journal import error codes appear in the log file on the Schedule Process page after the import process is run. The codes help identify errors and assist you in correcting the errors.

Journal Import Error Codes

The following table describes the period error codes.

Code	Description
EP01	This date is not in any open or future enterable period.
EP03	This date is not within any period in an open encumbrance year.
EP04	This date is not a business day.
EP05	There are no business days in this period.

The following table describes the unbalanced journal error codes.

Code	Description
WU01	This journal entry is unbalanced. It is processed because suspense posting is allowed in this ledger.
EU02	This journal entry is unbalanced and suspense posting is not allowed in this ledger.
EU03	This encumbrance journal entry is unbalanced and the Reserve for Encumbrance account is not defined.

The following table describes the flexfield error codes.

Code	Description
EF01	This account is inactive for this accounting date.
EF02	Detail posting not allowed for this account.
EF03	Disabled account.
EF04	This is an invalid account. Check your cross-validation rules and segment values.
EF05	There is no account with this Code Combination ID.
EF06	The alternate account is invalid.
WF01	An alternate account was used instead of the original account.
WF02	A suspense account was used instead of the original account.

The following table describes the foreign currency error codes.

Code	Description
EC01	A conversion rate must be entered when using the User conversion rate type.
EC02	There is no conversion date supplied.
EC03	A conversion rate type or an accounted amount must be supplied when entering foreign currency journal lines.
EC06	There is no conversion rate for this currency, conversion rate type, and conversion date.
EC08	Invalid currency.
EC09	No currencies are enabled.
EC10	Encumbrance journals cannot be created in a foreign currency.
EC11	Invalid conversion rate type.
EC12	The entered amount must equal the accounted amount in a ledger or statistical currency journal line.
EC13	Amount is too large.
ECW1	Converted amounts could not be validated because the conversion rate type is not specified.

The following table describes the budget error codes.

Code	Description
EB01	A budget version is required for budget lines.
EB02	Journals cannot be created for a frozen budget.
EB03	The budget year is not open.
EB04	This budget does not exist for this ledger.
EB05	The encumbrance_type_id column must be null for budget journals.
EB06	A period name is required for budget journals.
EB07	This period name is not valid. Check calendar for valid periods.
EB08	Average journals cannot be created for budgets.
EB09	Originating company information cannot be specified for budgets.

The following table describes the encumbrance error codes.

Code	Description
EE01	An encumbrance type is required for encumbrance lines.
EE02	Invalid or disabled encumbrance type.
EE03	Encumbrance journals cannot be created in the STAT currency.
EE04	The BUDGET_VERSION_ID column must be null for encumbrance lines.
EE05	Average journals cannot be created for encumbrances.
EE06	Originating company information cannot be specified for encumbrances.

The following table describes the reversal error codes.

Code	Description
ER01	This reversal period name is invalid. Check your calendar for valid periods.
ER02	This reversal period name is invalid. Check your calendar for valid periods.
ER03	The reversal date must be provided.
ER04	This reversal date is not in a valid period.
ER05	This reversal date is not in your database date format.
ER06	Your reversal date must be the same as or after your effective date.
ER07	This reversal date is not a business day.
ER08	There are no business days in your reversal period.
ER09	Default reversal information could not be determined.

The following table describes the descriptive flexfield error codes.

Code	Description
ED01	The context and attribute values do not form a valid descriptive flexfield for Journals - Journal Entry Lines.
ED02	The context and attribute values do not form a valid descriptive flexfield for Journals - Captured Information.

The following table describes the miscellaneous error codes.

Code	Description
EM01	Invalid journal entry category.
EM02	There are no journal entry categories defined.
EM05	The ENCUMBRANCE_TYPE_ID column must be null for actual journals.
EM06	The budget_version_id column must be null for actual journals.
EM07	The statistical amount belongs in the entered_dr or entered_cr column when entering a STAT currency journal line.
EM09	There is no Transaction Code defined.
EM10	Invalid Transaction Code.
EM12	An error occurred when generating sequential numbering.
EM13	The assigned sequence is inactive.
EM14	There is a sequential numbering setup error resulting from a missing grant or synonym.
EM17	Sequential numbering is always used and there is no assignment for this ledger and journal entry category.
EM18	Manual document sequences cannot be used with Journal Import.
EM19	Value Added Tax data is only valid in conjunction with actual journals.
EM24	Average journals can only be imported into consolidation ledgers.
EM25	Invalid average journal column value. Valid values are {Y_CODE, {N_CODE, and null.
EM26	Invalid originating company.
EM27	Originating company information can only be specified when intercompany balancing is enabled.
EM29	You do not have access to this ledger and account combination.
EM30	This primary balancing segment value is not valid for this ledger.
EM31	This management segment value is not valid for this ledger.

Reverse Journals

Journal Reversals

You can reverse journals manually by selecting a reversal action in the user interface, or you can reverse journals automatically by running a process. Decide which approach is best for journals such as accruals, estimates, errors, temporary adjustments, or reclassifications that require reversal. Reversing journals saves you time and helps prevent data entry errors.

Here are the key areas to understand when reversing journals:

Reversal Settings on Journals
Manual Journal Reversal
Journal Reversal Criteria Sets
Automatic Journal Reversal
Reversal Synchronization Between a Primary Ledger and Its Secondary Ledgers

Reversal Settings on Journals

You can enter and view a journal's reversal settings in the Reversal tab on the Create and Edit Journal pages:

Reversal Period: Accounting period for the resulting reversal journal. Required for reversal.
Reversal Date: Applicable only to average daily balance ledgers. Accounting date to be applied to the reversed journal, since that's needed for calculating average balances. For ledgers that aren't average daily balance ledgers, default logic is applied to determine the accounting date for the generated reversal.
Reversal Method: Method for reversing amounts in the reversal journal. Select from Change Sign or Switch Debit or Credit. The default setting is Switch Debit or Credit. The Change Sign setting means the reversal puts the original journal amount in the same Debit or Credit column, but with the opposite (negative or positive) sign. The Switch Debit or Credit setting means the amount is moved to the other column. Required for reversal.
Reversal Status: View-only state of the journal reversal. For example, Not reversed or Reversed.

You can enter a reversal period and method at any time, even after the journal is posted. If applicable, the following values also display in the Reversal tab:

Reversal Journal: If you're reviewing a journal that was reversed, this setting displays the name and link to the reversal journal.
Originating Journal: If you're reviewing a reversal journal, this setting displays the name and link for the journal that was reversed.

Manual Journal Reversal

You can manually reverse posted journals that are eligible for reversal on both the Manage Journals and Edit Journal pages. Both pages provide an action to reverse a journal and an action to reverse a batch.

On the Edit Journal page, you can select Reverse from the Batch Actions menu to reverse a journal batch, or you can select Reverse from the Journal Actions menu to reverse a specific journal. On the Manage Journals page, you can select rows in the Search Results section and then select the Reverse Batch or Reverse Journal buttons. To select multiple rows at once, use the Shift or Control key. You can reverse multiple journals of the same batch, or of different batches, or reverse entire journal batches that are eligible for reversal, based on the rows you selected.

Each reversal journal is created in its own reversal batch and the batch name starts with the word Reverses. When you reverse a batch, a single reversal request is submitted. However, the reversal journal for each journal in the reversed batch is still generated in its own journal batch. Reversal journals for journal-level reporting currencies are grouped into the same reversal batch as the corresponding reversal journal of their associated primary or secondary ledger. Reversal journals for subledger-level reporting currencies are grouped into the same reversal batch as their corresponding primary ledger.

Here are some examples of when you might want to use batch reversal.

Scenario	How It Works
You want to reverse all of the journals in a batch that aren't yet reversed, using the same reversal settings. For example, using the same reversal period for ledgers that aren't enabled for average balances, or the same reversal period and date for ledgers that are enabled for average balances. Or, you want to use the same reversal method.	When you select the reverse batch action, the Reverse Journal Batch window opens. You provide the reversal period, date, or method. The information you enter overrides any reversal settings at the journal level of journals that aren't yet reversed. All journals eligible for reversal are reversed according to what you specified on the Reverse Journal Batch window.
You specified reversal settings for every journal that's not yet reversed in a batch, and you want to process reversals more efficiently using batch reversal.	Leave the fields blank on the Reverse Journal Batch window. Each of these journals is reversed according to the journal's reversal settings.
You specified reversal settings for some, but not all, of the journals that aren't yet reversed in a batch, and you want to process reversals more efficiently using batch reversal.	Use the Manage Journals page to reverse the batch. Leave the fields blank on the Reverse Journal Batch window. Each of these journals is reversed according to the journal's reversal settings.
You want to reverse multiple journals from different batches using the reversal settings specified on each journal in these batches.	Use the Manage Journals page to select the rows for the batches and then select the reverse batch action. Each journal that's eligible for reversal in these batches is reversed according to the journal's reversal settings.

Journal Reversal Criteria Sets

To provide default reversal settings to a newly-created journal based on the journal's category, or to also proceed with automatically reversing a posted journal, create a journal reversal criteria set and assign it to a ledger. A journal reversal criteria set contains all journal categories with their corresponding reversal settings and can be shared with any number of ledgers.

Here's how to navigate to the journal reversal criteria set page from the Setup and Maintenance work area:

Offering: Financials
Functional Area: General Ledger
Task: Manage Journal Reversal Criteria Sets

The Create Journal Reversal Criteria Set page lists all of the journal categories with default reversal settings. Find the journal categories that you want to specify reversal criteria for and set the values accordingly. This table describes each reversal setting.

Setting	Values	Description
Reversal Period	No Default, Same Period, Next Period, Next Nonadjusting Period, Next Day, Same Day	Accounting period for the resulting reversal journal. The following values apply only to average balance ledgers: Next Day, Same Day. Selecting those values for a ledger that isn't an average balance ledger is the same as selecting the value No Default.
Reversal Date	First Day, Next Day, Last Day	Day of the accounting period when the journal is to be reversed. A reversal date only applies to average balance ledgers. You must specify a reversal date if you select the following values for the reversal period: Next Nonadjusting Period, Next Period, Same Period.
Reversal Method	Change Sign, Switch Debit or Credit	Method for reversing amounts in the reversal journal.
Automatic Reversal Option	None, Reverse Automatically, Reverse and Post Automatically	Setting that determines whether a journal is selected for automatic reversal, and whether the reversal journal is posted after it's reversed. Unlike the previous settings in this table, which are propagated directly as attributes in the journal, this setting is used to determine the reversal action that's applied when the automatic reversal process is run.

After you create the journal reversal criteria set, assign it to one or more of your ledgers. Here's how to navigate to the ledger page in the Setup and Maintenance work area where you can assign the journal reversal criteria set:

Offering: Financials
Functional Area: General Ledger
Task: Specify Ledger Options, with the ledger scope set

When you create a journal for a ledger with an assigned criteria set, the journal's reversal period and method are populated according to the criteria setting for that journal's category. This applies to journals entered through the user interface and the Create Journal spreadsheet. You can accept the defaulted reversal values or change them at any time, even after the journal is posted.

Automatic Journal Reversal

The automatic reversal process only selects reversible journals whose categories are enabled for automatic reversal in the journal reversal criteria set that's assigned to the ledger. The automatic reversal option for those categories must be set to either Reverse Automatically or Reverse and Post Automatically.

Here's how you can run the automatic reversal process:

Select the Run AutoReverse task from the tasks pane in the Journals work area. The task opens the Scheduled Process page for the AutoReverse Journals process. You might want to run automatic reversals this way for one-time accruals entered in the current period, but tagged to reverse in a later period.
Submit or schedule the AutoReverse Journals process on the Scheduled Processes page.
Enable the ledger option Run AutoReverse After Open Period on the Specify Ledger Options page. When enabled, the automatic reversal process is submitted with the reversal period choice of All.

Note: If you usually reverse journals on the last day of every month, don't enable this option. Instead, schedule the automatic reversal process to run on the last day of the month. The accounting period parameter automatically increments for each subsequent run.

The automatic journal reversal process creates one journal batch for each journal that's reversed. The names for the reversal batch and reversal journal begin with the word Reverses. The process also produces the AutoReverse Execution report, which prints the name of the journal batch that was submitted for reversal, along with the journal batch accounting period. If the automatic reversal option is set to Reverse and Post Automatically, then the report also provides information about the reversal batch.

Note: The AutoPost Journals process that's automatically submitted by the reversal process posts only the reversal journals that it generated, not other journals that are pending posting.

If reversal synchronization is enabled (refer to the next section for details), the process generates a journal reversal in the corresponding secondary ledger and the AutoReverse Execution report includes information about the journal reversal batch that's generated in the secondary ledger.

After the process completes, you can review the reports for any problems and verify that all journals were processed properly.

Here are some points to consider if you decide to run the automatic reversal process:

If the automatic reversal option on the applicable journal reversal criteria set is set to:
- Reverse and Post Automatically and journal approval is enabled, journals posted by the process bypass approval.
- Reverse Automatically, you must manually post the reversal journals.
If you have an average balance ledger, the automatic reversal process doesn't check that the reversal date is a valid business day. However, the journal validation in the journal pages and the import process perform this check and, if necessary, roll the date to the next business day.

Reversal Synchronization Between a Primary Ledger and Its Secondary Ledgers

If you have secondary ledgers, it's recommended that you enable the primary ledger option Synchronize Reversals Between Primary and Secondary Ledgers. Reversal synchronization helps to ensure that the secondary ledger remains as an accurate alternate representation of its corresponding primary ledger. If you enable this option, a journal reversal (manual or automatic) in the primary ledger triggers the reversal of the corresponding journal in the associated secondary ledger. If you didn't enable this option, you would have to actively manage the reversal of journals in the secondary ledger, whether they were replicated from its primary ledger or created directly in the secondary ledger. To set this option for a primary ledger, use the same navigation as you did for assigning the journal reversal criteria set to the ledger.

Note: Reversal synchronization is relevant only for secondary ledgers with a data conversion level of Journal or Subledger because primary ledger journal replication is applicable only to secondary ledgers at those conversion levels. Reversals for reporting currencies at a Journal level of conversion for a primary or secondary ledger, and also at a Subledger level for a primary ledger, are automatically synchronized with their source ledger, regardless of the synchronization option setting.

Here's how reversal synchronization works with journal approval when you have this setup:

You enabled journal approval in both the primary and secondary ledger.
You enabled reversal synchronization between the two ledgers.

The reversal journal generated in the secondary ledger (for the primary ledger reversal) won't require a separate approval.

This table shows how journals are reversed in a secondary ledger when synchronization is enabled. Journal reversal depends on how the journals were created in the secondary ledger and on whether a reversal criteria set is assigned to the secondary ledger.

How was the journal that's going to be reversed created in the secondary ledger?	Did you assign a journal reversal criteria set to the secondary ledger?	How is the journal reversed in the secondary ledger?
The journal was replicated from the primary ledger.	Yes	The journal is reversed automatically when the journal in the primary ledger is reversed. The reversal settings in the primary ledger source journal override any reversal settings on the journal in the secondary ledger that's being reversed. Note: Because the journal was replicated from the primary ledger, the journal reversal criteria set has no impact on the reversal.
The journal was created directly in the secondary ledger.	Yes	If the journal category is set for automatic reversal in the secondary ledger's assigned criteria set, you can run the automatic reversal process in the secondary ledger. Otherwise, you must reverse the journal manually.
The journal was replicated from the primary ledger.	No	The journal is reversed automatically when the journal in the primary ledger is reversed.
The journal was created directly in the secondary ledger.	No	You must specify reversal information in the journal and manually reverse the journal in the secondary ledger.

Once set, the primary ledger option Synchronize Reversals Between Primary and Secondary Ledgers applies to any secondary ledger of the primary ledger. The option Post Journals Automatically from Source Ledger is set by the individual secondary ledgers of the primary ledger and controls automatic posting of secondary ledger journals (reversals and otherwise), when the corresponding primary ledger journal is posted. To set this option, use this navigation in the Setup and Maintenance work area:

Offering: Financials
Functional Area: General Ledger
Task: Complete Primary to Secondary Ledger Mapping, with the primary ledger and secondary ledger scope set

Post Journals

Overview of Journal Posting

Journal posting is a process that updates balances in general ledger accounts to reflect an entity's business transactions and provides data for financial reporting.

Two aspects to consider in journal posting are:

Functionally
Timing

Functionality

Posting is done from the journals pages by selecting journal entries and clicking the Post button. Automate your posting process by scheduling an automatic posting process to periodically select and post batches. You can start posting from the journal creation spreadsheet in Oracle Fusion Application Development Framework Desktop Integration. You can also start posting through the Import and Post option, which imports the data in the spreadsheet and then runs the posting process. Once you post a journal batch, you cannot modify its contents, including additional descriptive information. You cannot delete posted journals but you can copy or reverse them. To reverse a posted journal, modify the reversal fields in on a posted journal or use the automatic reversal functionality. You can only reverse a journal once.

Timing

Journal entries can be posted to a current or prior accounting period, or to an open prior fiscal year. When you post to a prior period, the general ledger automatically updates the beginning balances of all subsequent periods, even if the period is closed. If you post a journal entry into a prior year, the retained earnings balance is adjusted for the effect on the income and expense accounts. When you finalize the activity for an accounting period, close the period to prevent the entry or posting of additional journal entries.

Note: Enable the ledger option Notify When Prior Period Journal to display a warning when you create a journal in an open prior period.

Automatic or Manual Journal Posting

The two methods for posting journal batches are:

Manually from these pages: Create Journal, Manage Journals
Automatically using criteria sets, spreadsheet creation, allocation and revaluation processes, or propagation to secondary ledgers

Manual

From the journal pages, click the Post button during the creation process or at a later time. Use this method for manually created journals and other types of journals that are infrequent and unscheduled. Use manual posting after error correction when the initial posting, either manual or automatic, fails to post the journal entry.

All Oracle Fusion General Ledger job roles, except the financial analyst, have predefined function security privileges to enter and post journals. Use journal approval to provide a layer of security for posting, if needed. For example, construct approval rules to require a manager to approve the journal entry before posting is permitted.

Automatic

Select options to automatically post journal entries when using spreadsheet creation, defining allocation and revaluation processes, transferring balances, or propagating journal entries to secondary ledgers.

Create AutoPost criteria sets in advance to automatically post journal entries. These posting criteria sets use the period, source, and category to select the journal entries for posting. Automatic posting is especially important for journal imports because it prevents editing of the journal import data. Editing of such data causes permanent out-of-balance situations between the subledger and the general ledger. Schedule the AutoPost process after journal import processes for increased efficiency.

Statuses for Unposted Journal Batches

All batches that aren't in a Posted status are considered unposted batches. These unposted batches have various statuses, including the following:

Incomplete: Batch has been saved but not completed.
Selected for Posting: Batch was selected but the posting process hasn't begun.
Processing: Posting process is currently running.
Error: Statuses assigned to journal batches at the end of the posting process to indicate problems preventing posting. Error statuses are displayed on the Journals work area landing page and General Accounting dashboard, as well as on the Posting Execution report.

Completing a Journal

Incomplete journals are listed on the Incomplete tab of the Journals work area landing page and General Accounting dashboard. You can manually enable the Complete status by clicking the Complete button or the Post button while the journal is still in an incomplete status.

Using the Incomplete Status

Use the Incomplete status to prevent posting of your journal batch while waiting on information or if you haven't completed all the entries within the batch. For example, you have to verify the amounts or accounts entered on the journal, or you have additional journal entries or lines to add. The Incomplete status also prevents the journal batch from being selected for posting by the AutoPost process.

How Account Balances Are Calculated

Account balances, when correctly calculated, create accurate financial statements that an entity can use to report its transactions.

Settings That Affect Account Balances

The initial ledger setup of the primary ledger controls how account balances are calculated. If implemented, accounting representations for secondary ledgers and currency conversion levels for reporting currencies are settings that affect account balances.

How Account Balances Are Calculated

Account balances are calculated when a journal is posted. The following occurs:

The application updates the general ledger balances table and the balances cubes, which are based on the chart of accounts and hierarchies, known as trees.
Balances are preaggregated in the balances cubes at every level in the account hierarchy for each chart of accounts segment.
- Balances cubes store both detail and aggregated balances.
- For each chart of accounts segment, balances are preaggregated at every level in the account hierarchy.
Foreign currency journal entries update account balances for both the foreign currency that is entered and the amount in the ledger currency that is accounted for during journal entry.
If you enable journal or subledger level options for reporting currencies or secondary ledgers, the journal is replicated to the reporting currency or secondary ledger.

Note: You configure these options by deciding on a combination of source and category, and for secondary ledgers, whether or not to automatically post the replicated journal.

Reporting currencies offer accounting representations that differ by currency from the source ledger, either primary or secondary. Suspense, rounding imbalances, and intracompany balancing lines are generated independently for each reporting currency at the journal and subledger level by the posting process.
Secondary ledgers are additional accounting representations that differ from primary ledgers in either the chart of accounts, accounting calendar, currency, accounting method, or ledger options. For instance, a secondary ledger may be required for local government compliance and reporting. Suspense, rounding imbalances, and intracompany balancing lines are generated independently for each secondary ledger at journal and subledger level by the posting process.

How Single Currency Journals Are Balanced

A journal must balance before it can be posted. If a journal is out of balance when submitted for posting, the posting process can automatically create balancing lines, or add differences to existing lines, depending on your setup.

Settings That Affect Balancing for Single Currency Journals

On the Specify Ledger Options page:

You can set these options in the Journal Processing Balancing section:
- Enable Suspense for General Ledger or Subledger
- Default Suspense Account
- Rounding Account
- Balancing Threshold Percent
Note: The Entered Currency Balancing Account option is only applicable to journals with multiple currencies.
You can set the Enable intercompany accounting option in the Journal Processing Intercompany section and define balancing rules on the Manage Intercompany Balancing Rules page.

On the Manage Suspense Accounts page, you can define suspense accounts for specific journal sources and categories.

How Single Currency Journals Are Balanced

The posting process checks entered amounts, accounted amounts, and balancing segment values in determining whether a journal balances. When a journal doesn't balance, the posting process uses your setup to process the differences and automatically balances the journal. When differences can't be handled automatically, the posting process fails.

The following figure shows the flow that the posting process follows to balance journals that have a single currency.

Are entered and accounted amounts in balance, or are accounted amount differences within threshold? If yes, the process continues to step 2. If no, and suspense is enabled, suspense balancing lines are created and the balancing process is complete. If no, and suspense isn't enabled, posting fails.
For each balancing segment value, are entered and accounted amounts in balance, or are accounted amount differences within threshold? If yes, the process continues to step 3. If no, and intercompany is enabled, intercompany balancing lines are created and the process continues to step 3. If no, and intercompany isn't enabled, posting fails.
Are there any remaining accounted amount differences? If yes, the process continues to step 4. If no, the balancing process is complete.
Is the Rounding account defined? If yes, rounding balancing lines are created and the balancing process is complete. If no, the difference is added to the largest line and the balancing process is complete.

This figure shows the balancing flow for journals
with a single currency.

The following examples compare unposted journals with the decision points in the flow to illustrate how the journals are subsequently balanced. The first segment in the account combination is the balancing segment, the ledger currency is USD, and the applicable options are set as follows:

Enable Suspense: Yes for General Ledger.
Default Suspense Account: 101.10.29900.000.000.
Rounding Account: None.
Balancing Threshold Percent: None for examples 1 through 4. For example 5, this option is set to 1.
Enable Intercompany Accounting: Enabled and intercompany rules defined.

Example 1: Entered Amount Differences

The following table shows the lines, accounts, and debits and credits, for an unposted journal in the ledger currency with differences between entered amounts.

Line	Account	Entered (USD) Debit	Entered (USD) Credit
1	101.10.11300.000.000	10,000.00
2	101.10.11200.000.000		10,000.01
Total		10,000.00	10,000.01

To understand how the journal is balanced, follow the flow:

Entered and accounted amounts balanced or accounted amount differences within threshold? No. Entered debits don't equal entered credits.
Suspense enabled? Yes. Suspense is enabled for General Ledger and the suspense account is 101.10.29900.000.000. To balance the journal, the posting process creates suspense line 3.

The following table shows the lines, accounts, amounts, and descriptions, for the posted journal.

Line	Account	Entered (USD) Debit	Entered (USD) Credit	Description
1	101.10.11300.000.000	10,000.00
2	101.10.11200.000.000		10,000.01
3	101.10.29900.000.000	0.01		Suspense line.
Total		10,000.01	10,000.01

Example 2: Accounted Amount Differences

The following table shows the lines, accounts, and debits and credits, for an unposted journal in a nonledger currency with differences between accounted amounts.

Line	Account	Entered (GBP) Debit	Entered (GBP) Credit	Accounted (USD) Debit	Accounted (USD) Credit
1	101.10.11300.000.000	10,000.00		15,297.54
2	101.10.11200.000.000		10,000.00		15,297.55
Total		10,000.00	10,000.00	15,297.54	15,297.55

Follow the posting flow:

Entered and accounted amounts balanced or accounted amount differences within threshold? No. Accounted debits don't equal accounted credits and no threshold is defined.
Suspense enabled? Yes. Suspense is enabled for General Ledger and the suspense account is 101.10.29900.000.000. To balance the journal, the posting process creates suspense line 3.

The following table shows the lines, accounts, amounts, and descriptions, for the posted journal.

Line	Account	Entered (GBP) Debit	Entered (GBP) Credit	Accounted (USD) Debit	Accounted (USD) Credit	Description
1	101.10.11300.000.000	10,000.00		15,297.54
2	101.10.11200.000.000		10,000.00		15,297.55
3	101.10.29900.000.000			0.01		Suspense line.
Total		10,000.00	10,000.00	15,297.55	15,297.55

Example 3: Entered Amount Differences by Balancing Segment Value

The following table shows the lines, accounts, and debits and credits for an unposted journal in the ledger currency with entered amount differences for each balancing segment value.

Line	Account	Entered (USD) Debit	Entered (USD) Credit
1	101.10.11300.000.000	10,000.00
2	102.10.11200.000.000		10,000.01
Total		10,000.00	10,000.01

Follow the posting flow:

Entered and accounted amounts balanced or accounted amount differences within threshold? No. Entered debits don't equal entered credits.
Suspense enabled? Yes. Suspense is enabled for General Ledger and the suspense account is 101.10.29900.000.000. To balance the journal, the posting process creates suspense lines 3 and 4.

The following table shows the lines, accounts, amounts, and descriptions, for the posted journal.

Line	Account	Entered (USD) Debit	Entered (USD) Credit	Description
1	101.10.11300.000.000	10,000.00
2	102.10.11200.000.000		10,000.01
3	102.10.29900.000.000	10,000.01		Suspense line.
4	101.10.29900.000.000		10,000.00	Suspense line.
Total		20,000.01	20,000.01

Example 4: Balancing Segment Values Out of Balance

The following table shows the lines, accounts, and debits and credits, for an unposted journal in the ledger currency that balances in total, but not by balancing segment value.

Line	Account	Entered (USD) Debit	Entered (USD) Credit
1	101.10.11300.000.000	10,000.00
2	102.10.11200.000.000		10,000.00
Total		10,000.00	10,000.00

Follow the posting flow:

Entered and accounted amounts balanced or accounted amount differences within threshold? Yes. Entered debits equal entered credits.
Entered and accounted amounts balanced by balancing segment value or accounted amount differences within threshold? No. Balancing segment value 101 has only debits and balancing segment value 102 has only credits and the threshold applies only to accounted amounts.
Intercompany enabled? Yes. To balance the journal by balancing segment value, the posting process creates intercompany balancing lines 3 and 4.

The following table shows the lines, accounts, amounts, and descriptions, for the posted journal.

Line	Account	Entered (USD) Debit	Entered (USD) Credit	Description
1	101.10.11300.000.000	10,000.00
2	102.10.11200.000.000		10,000.00
3	102.10.18100.000.101	10,000.00		Intercompany balancing line.
4	101.10.29100.000.102		10,000.00	Intercompany balancing line.
Total		20,000.00	20,000.00

Example 5: Rounding Difference

The following table shows the lines, accounts, and debits and credits, for an unposted journal in a nonledger currency with a difference due to rounding.

Line	Account	Entered (GBP) Debit	Entered (GBP) Credit	Accounted (USD) Debit	Accounted (USD) Credit
1	101.10.11300.000.000	10,000.00		15,297.54
2	101.10.11200.000.000		4,500.00		6,883.89
3	101.10.12110.000.000		5,500.00		8,413.64
Total		10,000.00	10,000.00	15,297.54	15,297.53

Follow the posting flow:

Entered and accounted amounts balanced or accounted amount differences within threshold? Yes. The difference between the accounted debits and the accounted credits, which is .01, is within the specified threshold of 1 percent.

Note: The threshold is calculating by multiplying the Balancing Threshold Percent setting by the total accounted debits or credits, whichever is greater. In this example, the threshold is 152.98, which is 1 percent of 15,297.54.
Entered and accounted amounts balanced by balancing segment value or accounted amount differences within threshold? Yes. All lines have a balancing segment value of 101.
Accounted amount differences remaining? Yes. The accounted debits are 15,297.54 and the accounted credits are 15,297.53.
Rounding account defined? No. To balance the journal, the posting process adds the rounding difference to the largest credit line, which is line 3.

The following table shows the lines, accounts, and amounts for the posted journal.

Line	Account	Entered (GBP) Debit	Entered (GBP) Credit	Accounted (USD) Debit	Accounted (USD) Credit
1	101.10.11300.000.000	10,000.00		15,297.54
2	101.10.11200.000.000		4,500.00		6,883.89
3	101.10.12110.000.000		5,500.00		8,413.65
Total		10,000.00	10,000.00	15,297.54	15,297.54

How MultiCurrency Journals Are Balanced

Settings That Affect Balancing for Multicurrency Journals

On the Specify Ledger Options page:

You can set these options In the Journal Processing Balancing section:
- Enable Suspense for General Ledger or Subledger
- Default Suspense Account
- Rounding Account
- Entered Currency Balancing Account
- Balancing Threshold Percent
You can set the Enable intercompany accounting option in the Journal Processing Intercompany section and define balancing rules on the Manage Intercompany Balancing Rules page.

On the Manage Suspense Accounts page, you can define suspense accounts for specific journal sources and categories.

How Multicurrency Journals Are Balanced

The posting process checks entered amounts, accounted amounts, balancing segment values, and currencies, in determining whether a journal balances. When a journal doesn't balance, the posting process uses your setup to process the differences and automatically balances the journal. When the differences can't be handled automatically, the posting process fails.

The following figure shows the flow that the posting process follows to balance journals that have multiple currencies.

Are accounted amounts in balance, or are accounted amount differences within threshold? If yes, the process continues to step 2. If no, and suspense is enabled, suspense balancing lines are created and the balancing process is complete. If no, and suspense isn't enabled, posting fails.
For each balancing segment value, are accounted amounts in balance, or are accounted amount differences within threshold? If yes, the process continues to step 3. If no, and intercompany is enabled, intercompany balancing lines are created and the process continues to step 3. If no, and intercompany isn't enabled, posting fails.
Does each balancing segment value balance by entered currency? If yes, the process continues to step 4. If no, and the Entered Currency Balancing account is defined, entered currency balancing lines are created and the process continues to step 4. If no, and the Entered Currency Balancing account isn't defined, posting fails.
Are there any remaining accounted amount differences? If yes, the process continues to step 5. If no, the balancing process is complete.
Is the Rounding account defined? If yes, rounding balancing lines are created and the balancing process is complete. If no, the difference is added to the largest line and the balancing process is complete.

This figure shows the balancing flow for journals
with multiple currencies.

The following examples compare unposted journals with the decision points in the flow to illustrate how the journals are balanced. The first segment in the account combination is the balancing segment, the ledger currency is USD, and the applicable options are set as follows:

Enable Suspense: Yes for General Ledger.
Default Suspense Account: 101.10.29900.000.000.
Rounding Account: 101.10.78550.000.000.
Entered Currency Balancing Account: 101.10.22270.000.000.
Balancing Threshold Percent: 1.
Enable Intercompany Accounting: Enabled and intercompany rules defined.

Example 1: Accounted Amount Differences

The following table shows the lines, accounts, currencies, and debits and credits, for an unposted multicurrency journal with accounted amount differences.

Line	Account	Currency	Entered Debit	Entered Credit	Accounted (USD) Debit	Accounted (USD) Credit
1	101.10.11300.000.000	GBP	10,000.00		15,297.54
2	101.10.11200.000.000	ANG		9,500.00		9,500.00
Total			10,000.00	9,500.00	15,297.54	9,500.00

To understand how the journal is balanced, follow the flow:

Accounted amounts balanced or accounted amount differences within threshold? No. The difference between the total accounted debits and total accounted credits is 5,797.54, which isn't within the specified threshold of 1 percent.

Note: The threshold is calculated by multiplying the Balancing Threshold Percent setting by the total accounted debits or credits, whichever is greater. In this example, the threshold is 152.98, which is 1 percent of 15,297.54.
Suspense enabled? Yes. Suspense is enabled for General Ledger and the suspense account is 101.10.29900.000.000. To balance the journal for each currency, the posting process creates suspense lines 3 and 4.

The following table shows the lines, accounts, currencies, amounts, and descriptions, for the posted journal.

Line	Account	Currency	Entered Debit	Entered Credit	Accounted (USD) Debit	Accounted (USD) Credit	Description
1	101.10.11300.000.000	GBP	10,000.00		15,297.54
2	101.10.11200.000.000	ANG		9,500.00		9,500.00
3	101.10.29900.000.000	ANG	9,500.00		9,500.00		Suspense line.
4	101.10.29900.000.000	GBP		10,000.00		15,297.54	Suspense line.
Total			19,500.00	19,500.00	24,797.54	24,797.54

Example 2: Entered Amounts Out of Balance by Entered Currency

The following table shows the lines, accounts, currencies, and debits and credits, for an unposted multicurrency journal that doesn't balance by entered currency.

Line	Account	Currency	Entered Debit	Entered Credit	Accounted (USD) Debit	Accounted (USD) Credit
1	101.10.11300.000.000	GBP	10,000.00		15,297.54
2	101.10.11200.000.000	ANG		9,500.00		15,297.54
Total			10,000.00	9,500.00	15,297.54	15,297.54

Follow the posting flow:

Accounted amounts balanced or accounted amount differences within threshold? Yes. Total accounted debits equal total accounted credits.
Accounted amounts balanced by balancing segment value or accounted amount differences within threshold? Yes. The balancing segment value for both lines is 101 and total accounted debits equal total accounted credits.
Entered amounts balanced by currency and balancing segment value? No. The journal doesn't balance by entered currency. The GBP currency has only debits and the ANG currency has only credits.
Entered Currency Balancing account defined? Yes. The Entered Currency Balancing account is 101.10.22270.000.000. To balance the journal, the posting process creates entered currency balancing lines 3 and 4 for each currency.

The following table shows the lines, accounts, currencies, amounts, and descriptions, for the posted journal.

Line	Account	Currency	Entered Debit	Entered Credit	Accounted (USD) Debit	Accounted (USD) Credit	Description
1	101.10.11300.000.000	GBP	10,000.00		15,297.54
2	101.10.11200.000.000	ANG		9,500.00		15,297.54
3	101.10.22270.000.000	ANG	9,500.00		15,297.54		Entered currency balancing line.
4	101.10.22270.000.000	GBP		10,000.00		15,297.54	Entered currency balancing line.
Total			19,500.00	19,500.00	30,595.08	30,595.08

Example 3: Entered Currencies and Balancing Segment Values Out of Balance

The following table shows the lines, accounts, currencies, and debits and credits, for an unposted multicurrency journal that doesn't balance by entered currency or balancing segment value.

Line	Account	Currency	Entered Debit	Entered Credit	Accounted (USD) Debit	Accounted (USD) Credit
1	101.10.11300.000.000	GBP	10,000.00		15,297.54
2	102.10.11200.000.000	ANG		9,500.00		15,297.54
Total			10,000.00	9,500.00	15,297.54	15,297.54

Follow the posting flow:

Accounted amounts balanced or accounted amount differences within threshold? Yes. Total accounted debits equal total accounted credits.
Accounted amounts balanced by balancing segment value or accounted amount differences within threshold? No. Balancing segment value 101 has only debits totaling 15,297.54. Balancing segment value 102 has only credits totaling 15,297.54. Each balancing segment value needs 15,297.54 to balance, which isn't within the threshold.

Note: The threshold is 152.98, which is 1 percent of 15,297.54.
Intercompany enabled? Yes. To balance the accounted amounts by balancing segment value, the posting process creates intercompany balancing lines 3 and 4 in the USD currency.
Entered amounts balanced by currency and balancing segment value? No to both. The GBP currency has only debits and the ANG currency has only credits. Debits don't equal credits for either balancing segment value.
Entered Currency Balancing account defined? Yes. The Entered Currency Balancing account is 101.10.22270.000.000. To balance by currency, the posting process creates entered currency balancing lines 5 and 6. To balance by balancing segment value, the posting process creates entered currency balancing lines 7 and 8 in the USD currency.

The following table shows the lines, accounts, currencies, amounts, and descriptions, for the posted journal.

Line	Account	Currency	Entered Debit	Entered Credit	Accounted (USD) Debit	Accounted (USD) Credit	Description
1	101.10.11300.000.000	GBP	10,000.00		15,297.54
2	102.10.11200.000.000	ANG		9,500.00		15,297.54
3	101.10.29100.000.102	USD		15,297.54		15,297.54	Intercompany balancing line.
4	102.10.18100.000.101	USD	15,297.54		15,297.54		Intercompany balancing line.
5	102.10.22270.000.000	ANG	9,500.00		15,297.54		Entered currency balancing line.
6	101.10.22270.000.000	GBP		10,000.00		15,297.54	Entered currency balancing line.
7	101.10.22270.000.000	USD	15,297.54		15,297.54		Entered currency balancing line.
8	102.10.22270.000.000	USD		15,297.54		15,297.54	Entered currency balancing line.
Total			50,095.08	50,095.08	61,190.16	61,190.16

Example 4: Rounding Difference

The following table shows the lines, accounts, currencies, and debits and credits, for an unposted multicurrency journal with a rounding difference.

Line	Account	Currency	Entered Debit	Entered Credit	Accounted (USD) Debit	Accounted (USD) Credit
1	101.10.11300.000.000	GBP	10,000.00		15,297.54
2	101.10.11200.000.000	ANG		9,500.00		15,297.54
3	101.10.11200.000.000	GBP		10,000.00		15,297.54
4	101.10.11300.000.000	ANG	9,500.00		15,297.35
Total			19,500.00	19,500.00	30,594.89	30,595.08

Follow the posting flow:

Accounted amounts balanced or accounted amount differences within threshold? Yes. The difference between accounted debits and accounted credits is 0.19, which is within the threshold.

Note: The threshold is 305.95, which is 1 percent of 30,595.08.
Accounted amounts balanced by balancing segment value or accounted amount differences within threshold? Yes. The balancing segment value for all lines is 101 and the difference between accounted debits and accounted credits is 0.19, which is within the threshold.
Entered amounts balanced by currency and balancing segment value? Yes. For each currency, entered debits equal entered credits, and the balancing segment value is the same for all lines.
Accounted amount differences remaining? Yes. For the ANG currency, the difference between accounted debits and accounted credits is 0.19.
Rounding account defined? Yes. The rounding account is 101.10.78550.000.000. To balance the journal, the posting process creates rounding line 5 for the ANG currency.

The following table shows the lines, accounts, currencies, amounts, and descriptions, for the posted journal.

Line	Account	Currency	Entered Debit	Entered Credit	Accounted (USD) Debit	Accounted (USD) Credit	Description
1	101.10.11300.000.000	GBP	10,000.00		15,297.54
2	101.10.11200.000.000	ANG		9,500.00		15,297.54
3	101.10.11200.000.000	GBP		10,000.00		15,297.54
4	101.10.11300.000.000	ANG	9,500.00		15,297.35
5	101.10.78550.000.000	ANG			0.19		Rounding line.
Total			19,500.00	19,500.00	30,595.08	30,595.08

Create an AutoPost Criteria Set

In this example, you're creating an AutoPost criteria set to post the general ledger journal entries created by journal import for your subledger transactions.

Here's the relevant setup for your Vision Corporation ledger.

You implemented Oracle Fusion General Ledger and the subledgers Oracle Fusion Payables and Oracle Fusion Receivables.
You use a non-Oracle subledger called Fast Assets for fixed asset tracking and depreciation.
You plan to automate posting of general ledger journal batches created by journal import. The automation is to protect the subledger-sourced journal entries from edits or deletion that could cause an out-of-balance situation between the subledgers and general ledger.

Consider these points when creating a criteria set:

Use the All option for category and accounting period to reduce maintenance and ensure that all journal imports are included in the posting process.
Create a criteria set that includes all your subledger sources. Create multiple criteria sets by source only if you must schedule different posting times to balance close activities or reduce processing time.

Create the Set

Go to the following:
- Offering: Financials
- Functional Area: General Ledger
- Task: Manage AutoPost Criteria Sets
Click Create.
Enter this name: All Journal Imported Entries.
Enter this description: Posting journals imported from the subledgers.
Select Enabled.
Select the Use Batch Creator as Approval Submitter check box if you require keeping the creator of the journal batch as the user who submitted the batch for approval when the AutoPost Journals process runs. If you don't select this check box, the user running the AutoPost journals process is the submitter for approval.

Enter these values and click Add Row to add each new line.

Priority	Ledger or Ledger Set	Source	Category	Accounting Period	Balance Type
1	Vision Corporation	Payables	All	All	All
2	Vision Corporation	Receivables	All	All	All
3	Vision Corporation	Fast Assets	All	All	All

Select Yes for the Process All Criteria check box, and enter 30 as the number of days before and after the submission date. The process runs less often when you specify a wide range.
Click Save and Close.

Tip: Schedule the process to run immediately after the Import Journals process to prevent changes to the journals. Run the process during nonpeak times to save resources.

Related Topics

Submit Scheduled Processes and Process Sets

Examples of Manually Running the AutoPost Process

Create an AutoPost criteria set and schedule the AutoPost Journals process to run on a regular basis following your scheduled journal imports from your subledgers. When errors occur that prevent posting of the journal imports, you must correct the errors and manually run the AutoPost process. The following scenarios illustrate the kinds of errors that could occur and how you can resolve these errors.

Scenario

The following table lists the errors that prevented journal batches from posting when the scheduled AutoPost Journals process ran.

Error	Cause	Solution
Unopened accounting period	The journal import was imported into a future period. An error arises when the AutoPost Journals process runs on a schedule because journals can't be posted in a future period.	Open the period.
Invalid or no journals	Journal import fails to import transactions from the general ledger interface table. The AutoPost Journals process runs on schedule but finds no batches to post. The posting process doesn't run and the AutoPost Execution report shows that no batches matched the criteria.	Correct the error that caused the journal import to fail.
Invalid or no journals	No journals were selected based on the posting criteria. Journal batches are available for posting. The posting process doesn't run and the AutoPost Execution report shows that no batches matched the criteria.	Revise the criteria set.

After you correct the errors:

Manually run the AutoPost Journals process by selecting the Run AutoPost option from the Tasks panel on the journal pages.
Click Generate on the AutoPost criteria set pages.
Verify that the process ran successfully by reviewing the AutoPost Execution report.

Journal Batch Summary Report

Use the Journal Batch Summary report to review your posted journal batches for a particular ledger, balancing segment value, currency, or date range.

The report provides data on:

Actual balances for your journal batches, sources, and posting dates
Total entered debits and credits
Journal batches within each journal entry category

Run the report from the Manage Journal Task Panel and optionally schedule the report to run periodically.

Before running this report, you must:

Approve all journals batches
Post all journals batches
Optionally, close the accounting period to ensure no further journal batches are entered

Ledger Set: To obtain a consolidated report across all ledgers, you must enter a ledger set representing all ledgers.
Balancing Segment Value: Leave the Balancing Segment Value parameter blank.
Currency: Enter a currency.
Start and End Date: Enter the accounting period date range.

Ledger Set: To obtain a report on a specific ledger or entity, you must enter the value for that ledger.
Balancing Segment Value: Leave the Balancing Segment Value parameter blank.
Currency: Enter a currency.
Start and End Date: Enter the accounting period date range.

Ledger Set: To obtain a report on a specific ledger or entity, you must enter the value for that ledger.
Balancing Segment Value: Enter the value representing the entity in the Balancing Segment Value parameter.
Currency: Enter a currency.
Start and End Date: Enter the accounting period date range.

Report Results

The report provides data on Actual balances for your journal batches by sources, batches, posting dates, and total entered debits and credits. The report sorts the data by journal batch within each journal entry category. In addition, totals are provided for each journal category and a grand total for each ledger and balancing segment value combination selected.

Note: This report does not report on budget or encumbrance balances.

Approve Journals

Considerations for Defining Journal Approval Rules

Use approval management to define policies that apply to the journal approval workflow.

Rule Definition Consideration

One predefined approval rule exists for journal approval. If a journal's ledger and source are enabled for approval, then that journal is sent for one level of approval to the supervisor of the person who submitted the journal for approval. You can configure journal approval rules in the Business Process Management Worklist application. Open the application by selecting the Notifications icon on the home page and clicking More Details or, by using the following in the Setup and Maintenance work area:

Offering: Financials
Functional Area: Application Extensions
Task: Manage Task Configurations for Financials

For a simple approval scenario, start by defining one or all of the following journal approval rules based on:

The highest journal line amount per ledger per batch.
The highest journal amount per ledger per batch.
Your stage in the period close process. For example, are you in the beginning, middle, or end of the month, or in preclose, close, post close, or quarter close process?

The following table provides an example of rule conditions and approval actions that route a journal approval based on maximum journal line amounts.

Condition	Approval Action
Less than 50,000 USD	No approval required
Between 50,000 and 100,000 USD	One level of approval required
Greater than 100,000 USD	Two levels of approval required

You can build your rules for combinations of ledger, entered amount, approval level, or other scenarios. In addition, you can define rules based on attributes from different parts of your journal, including the ledger, batch, header, or line level. For example, you can use category, source, account, or descriptive flexfield information as selection criteria for journal approval.

Note: To prevent a submitter from approving their own journal batch, select the Skip creator for Approval List check box on the Configuration page in the Worklist application. The approval task is then assigned to other approvers or automatically routed to the manager of the submitter.

Approvals List Builder Considerations

List builders are the way approvals management builds the list of approvers required for a transaction based on the rule condition. Each approval rule is associated with a list builder for generating the list of approvers.

The following table describes the list builders you can use to build a journal approval list.

List Builder	Description
Supervisory	Based on the employee supervisory hierarchy, which is defined in HCM. Employees must be set up with appropriate jobs and supervisors. For example, a clerk reports to a manager, who reports to the director.
Job Level	Based on the job level, which is defined in HCM. Employees must be set up with the appropriate job levels and supervisors. For example, a job level 1 employee, a clerk, reports to a job level 2 employee, a manager, who reports to a job level 4 employee, a director. The approval list is generated based on the starting position specified in the rule and continues until an approver with a sufficient job level is found. The supervisory hierarchy must be defined along with the corresponding job levels.
Position	Based on the position hierarchy, which is defined in HCM. The position hierarchy must be defined and employees must be assigned the corresponding positions. Use this hierarchy if you need a hierarchy that's different from the supervisory hierarchy, or multiple hierarchies selected based on different attributes.
Approval Group	Consists of a static predefined set of users configured to act on a task. For example, you can create an approval group called Finance Group, consisting of users from the finance department who must participate in the task approval.
Resource	Builds the approvers list by using a specific user, enterprise group or application role.

Other Considerations

Other functionality to consider before defining approval rules.

Both the ledger and journal source must be enabled for the approval process.

Caution: You should not enable journal approval for journals that come from subledgers (with subledger journal sources). Otherwise, if a journal from a subledger isn't approved, the journal can get stuck in the approval process. For any subledger journal sources, approvals for subledger transactions should be done in the subledgers themselves.
Approval is for the entire journal batch, regardless of the attributes used in the approval rules.
If a journal requires approval, submitting a journal for posting automatically routes the journal for approval before posting.
A journal can be escalated to an approver by the administrator.
The task initiator can select Withdraw Approval on the Journals page at any time in the approval process to withdraw journals from the process. Clicking this button enables editing of the journal. After your changes are made, submit the entry for approval again. When a journal is withdrawn, the completion status is set to Incomplete.
Approval notifications display a table of key journal attributes for each journal and a list of past, current, and future approvers.
The Journals work area displays journals requiring your approval and journals pending approval from others.
If you're the current approver, the Journals page shows the journals to be approved or rejected.
Allocation journals aren't routed through the approval process.
You can review the details of the journals and journal lines included in a journal batch on the online and email journal batch approval notifications.

Related Topics

Create Journal Approval Rules Using a Spreadsheet

Create Workflow Rules Using a Spreadsheet

The Simplified Workflow Rules Configuration feature is a spreadsheet based alternative to creating rules in Oracle Business Process Management (BPM). You can use spreadsheet templates available on the Manage Workflow Rules in Spreadsheet page to manage rules for Financials application workflows.

Note: Currently, only Payables Invoice Approval and General Ledger Journal Approval workflows use this feature.

To create workflow rules in a spreadsheet, perform the following steps:

Steps to create workflow rules using a spreadsheet.

Sign in and navigate to the Manage Workflow Rules in Spreadsheet task.
Download the rule template from the Rule Templates section of the Manage Workflow Rules in Spreadsheet page.
Define the workflow rules in the spreadsheet.
Generate the rule file.
Upload the rule file to create rules.
Verify the spreadsheet upload.

Caution: You must use MS Excel version 2016 to create workflow rules. Also, every successful rule upload using a spreadsheet template overrides the existing rules for the workflow.

Tip: Once you create rules using the rule templates, we recommend you use the spreadsheet method only for any future maintenance of rules.

Manage Workflow Rules Using a Spreadsheet

Before creating and managing workflow rules, perform these steps:

Sign in to the application as a Financial Application Administrator.
Verify if the Approval Routing Administration feature is enabled at Offerings > Financials > Opt In Features. Click the Edit icon for Financials. If the feature isn't enabled, select its check box.
In the Setup and Maintenance work area, go to Financials > Application Extensions > Manage Workflow Rules in Spreadsheet task.

Download the Rules Template

Download the rule template by performing these steps:

In the Rule Templates section of the Manage Workflow Rules in Spreadsheet page, select the required workflow.
Click Download. The Download Templates dialog box appears.
From the dialog box, select the required template. Save the template to your local computer.

Caution: You must use MS Excel version 2016 to create workflow rules.

Note: Each rule template contains an example of an approval business case to demonstrate how to manage workflow rules using the rule template.

Define the Rules in the Spreadsheet

After downloading the rule template, you must define the workflow rules using the sheets provided in the rule template. Here's a list of sheets you can see in the rule template spreadsheet:

Instructions: This sheet contains details of the help topics present on Oracle Help Center for this feature and the Generate Rule File button. You can also update your rule template version from the Instructions sheet.
Workflow Rules: Provides a template for configuring transaction approval rules.

Note: The name of this sheet varies for each product. For example, for Payables, the sheet is labeled as Invoice Approval Rules.
Data Set: This sheet provides a template to map the varying attributes to the data.

Note: Currently, data sets are only available for Payables workflows. For more information about data sets, refer to the Data Sets section.

A business rule is an approval requirement within your approval policy. Before defining rules in the rule template, you must analyze approval policy. Consider these points before defining a business rule:

Which transactions require approval?
Who approves transactions in your organization?
Do the approvers vary based on the transaction attributes? If so, use a data set.
What are approval conditions?
How do you want to route the approval notifications?
Which approvals require FYI notifications?
Which transactions are exempted from the approval rule?

For example, for Payables, if your organization's approval policy mandates that:

All invoices that aren't matched to a purchase order must be approved at two levels of the supervisory hierarchy. This hierarchy starts from the manager of the user who creates the invoice.
All invoices that have an invoice amount of more than 5000 USD must be approved by a group of personnel from the Finance department.

For this example, you need two business rules.

Use the Workflow Rules sheet to define approval rules. Enter these details:

Rule Description

Enter the description for each approval business rule that you define.

Approvers

In this section, designate approvers and specify approval routing. The template supports a variety of approval routing options. This table provides you details on approval routing and how it works.

Approval Routing	How Approval Routing Works
Supervisory Hierarchy	Members of the supervisory hierarchy beginning from the first applicable approver receive approval notifications.
Group in Parallel	Members of an approval group receive approval notifications. All members receive notifications at the same time. All members must take an action on the approval notification.
Group in Serial	Members of an approval group receive approval notifications. Only when a member takes an action on the approval notification does the next member of the series receive the approval notification.
Group First Responder	Members of an approval group receive approval notifications. All members receive notifications at the same time. Only one member is required to take an action on the approval notification.
Job Level Hierarchy	Members of the job hierarchy beginning from the first applicable approver receive approval notifications.
User	The specified application user receives the approval notification.
Role	The users with the specified application role receive the approval notification.
Auto Approve	Transactions that are automatically approved. No notifications are sent.
Auto Reject	Transactions that are automatically rejected. No notifications are sent.
FYI	Information only notifications. No action is required from the approver.
Skip Approval	Transactions for which the rule isn't applicable. No notifications are sent.

Note: You can only use an approval group that exists in the BPM.

For detailed instructions on the other columns in the Approvers section, refer to the tool tip on each column header.

Approval Conditions

In the Approval Conditions section you can select the attributes based on which the transaction should be evaluated for the workflow rules. You can also add attribute categories.

To add an attribute category:

Open the list of values associated with the last column in the Approval Conditions section.
Select the required attribute category.

To add an attribute:

Open the list of values associated with the attribute category.
Select the required attribute.

For example, in the Invoice Approval template for Payables, you can select Business Unit and Invoice Amount attributes for the attribute category Invoice Header. Similarly, you can select attributes for categories, such as Invoice Line, Invoice Distributions, and more.

While defining approval conditions, you can use a variety of operators. This table lists the supported operators.

Condition	Value Type	Format	Example
Attribute is a specific value	Text, number, or date	value Note: No specific format applies here.	If the Invoice Type is Standard, then enter the value as: Standard
Attribute value is one of multiple specific values	Text or number	`in (value 1, value 2, ...)`	If the BU name is Vision Operations, Vision Services, or Vision Foods then enter the value as: In (Vision Operations, Vision Services, Vision Foods
Attribute value should be within a range of values	Number or date	between value 1 and value 2 OR value 1 to value 2	If the Invoice Date is between 01 August 2018 to 01 August 2019, then enter the value as: Between 01/aug/2018 and 31/aug/2019 OR 01/aug/2018 to 31/aug/2018
Attribute value starts with a specific value	Text	Starts with value	If the BU name starts with Vision then enter the value as: Starts with Vision
Attribute value ends with a specific value	Text	Ends with value	If the BU name ends with Operations then enter the value as: Ends with Operations
Attribute value contains a specific value	Text	Contains value	If the Pay Group contains Standard then enter the value as: Contains Standard
Attribute value matches a specific value	Text	Matches value	If the Description matches manual invoice then enter the value as: `Matches manual\\s(.) invoice` In this example, the Matches operator begins with Manual and ends with Invoice. Between the two words, there can be one space and any character. Other options that can be used with the Matches operator are: `(.)` - Denotes zero or more characters. `(.+)` - Denotes one or more characters. `\\s` - Denotes space. `\\d` - Denotes numbers from 0-9. `?` - Makes a character optional. For example: `\\d?` `[ ]` - Specifies range such as A-Z, 0-9
Attribute value is more than or equal to a specific number	Number	More than equal to number OR >= number	If the Invoice amount is more than or equal to 500, then enter the value as: More than equal to 500 OR >= 500
Attribute value is less than or equal to a specific number	Number	Less than equal to number OR <= number	If the Invoice amount is less than or equal to 500, then enter the value as: Less than equal to 500 OR <= 500
Attribute value is more than a specific number	Number	More than number OR >number	If the Invoice amount is more than 500, then enter the value as: More than 500 OR >500
Attribute value is less than a specific number	Number	Less than number OR <number	If the Invoice amount is less than 500, then enter the value as: Less than 500 OR <500
Attribute value is on or before a specific date	Date	On or before date	If the Invoice date is on or before 01/10/2018, then enter the value as: On or before 01/oct/2018
Attribute value is on or after a specific date	Date	On or after date	If the Invoice date is on or after 01/10/2018, then enter the value as: On or after 01/oct/2018
Attribute value is before a specific date	Date	Before date	If the Invoice date is before 01/10/2018, then enter the value as: Before 01/oct/2018
Attribute value is after a specific date	Date	After date	If the Invoice date is after 01/10/2018, then enter the value as: After 01/oct/2018
Attribute value is a specific value and the condition must be evaluated as case insensitive	Text	Equals ignore case value	If the Invoice Source is equal to Manual, then enter the value as: Equals ignore case manual

Note: The operators aren't case-sensitive. However, you must enter the date in the DD/MMM/YYYY or DD-MMM-YYYY format only.

If you have a negative approval condition, add Not as a prefix to any of the supported operators. For example, your approval condition states that BU name isn't Vision Operations, Vision Services, or Vision Foods then enter the value as: Not In (Vision Operations, Vision Services, Vision Foods).

If you have two distinct rule conditions that require the same approval routing, then you must enter the rule conditions in two separate rows. Ensure that the information in the Approvers section is identical for both the rows.

Rule Blocks

A rule block is a group of rows in the workflow rules spreadsheet. You can define a business rule and all aspects of the business rule in these rows. Use a separate block for each business rule.

While all rule aspects defined within a rule block are processed simultaneously, rule blocks are processed in sequence. Therefore, before defining the rules, you must consider the sequence in which the rules should be processed.

You can create additional rows in a block and additional blocks in a sheet as needed.

To insert more blocks in a rule block:

Select a row.
Right-click and select Add Block.

To add a rule block after the existing rule blocks, click Add Block in the sheet.

To insert more rows in a rule block:

Select a row and right-click.
From the menu, select Insert.

To delete a rule block:

Select all the rows in a rule block.
Right-click and select Delete Block.

Data Sets

In your approval policy, if the approver of a transaction varies based on the transaction attributes, then you should use a data set. A data set lets you define a mapping between your data and the variation in approvers based on such data.

For example, a transaction with an amount greater than 5000 USD must be approved by an approval group. However, the approval group varies depending on the cost center. In this case, you can use a data set to define a mapping between the cost center and the approval group.

Note: Currently, data sets are only available for templates for Payables Invoice Approval Workflow.

To define a data set, perform these steps:

Open the Data Set sheet of the rule template.
In the Set Name column, enter a unique name.
Enter the value in the Approval Group/Supervisory Level/Job Level Range/User/Role column. This value depends on the approval routing of the rule for which you're using the data set.

For the given example, specify the approval group name in the Approval Group/Supervisory Level/Job Level Range/User/Role column.

Note: You can only use an approval group that already exists in the BPM.
If your starting approver for rules using Supervisory or Job Level Hierarchy approval routing varies based on transaction attributes, then click Add Start Approver to add the Start Approver column in the dataset. You can select any of the values from the list of values or directly enter a user name as the start approver.

Note: If you're specifying start approver in the dataset, then you must select a value of Use Dataset in the Start Approver column of the Approvers section in the Invoice Approval Rules or Invoice Request Approval Rules sheet as applicable. This ensures that the Start Approvers are picked up from the dataset for such rules.
In the Varying Attribute section, select the attributes based on which the approver varies for the transaction.

For the given example, select Distribution Cost Center Segment from the list of values and specify the cost center values for each approval group.
Enter values for each varying attribute. You can also use the supported operators with the values.
Click Add New Column to create additional columns for varying attributes.
Click Add Data Set to create additional data sets.

After you create a data set, you must enter a data set reference in your rule in the Workflow Rules sheet. Prefix the data set name with $ to create a reference. For example, to reference a data set named Supervisory, enter the value as $Supervisory Set in the Workflow Rules sheet.

You can enter the data set references in the Approvers section of the Workflow Rules sheet. Based on the approval routing used for the rule, enter data set references in these columns:

Job Level Range
Approval Level
Group/User/Role Name

Generate Rule File

After entering the data in the Workflow Rules sheet, click the Generate Rule File button located in the Instructions sheet to generate the rule file. A compressed file is generated. Save the file in your local computer.

Upload the Rule File

To upload the rule file, perform the following steps:

Navigate to the Manage Workflow Rules in Spreadsheet page.
In the Rule Templates section, select the required workflow.
Click Upload. The Upload File dialog box appears.
In the File field, click Choose File.
From your local directory, select the compressed rule file that was generated from the workflow rules template.
Click Submit. A confirmation message stating the process ID appears.

Caution: Every successful rule upload using a spreadsheet template overrides the existing rules for the workflow.
Click OK.
Check the status of the upload in the Upload History section.

Update the Rule Template Version

While uploading your rule template, if you're asked to update the file version, perform the following steps:

Download the latest version of the rule template from the Manage Workflow Rules in Spreadsheet page. You can select any of the available templates for the workflow.
In the Instructions sheet of the rule template, click Update Spreadsheet.
Select the older version of the rule template and click OK.

This copies rules from the older version of your rule template to the latest version.
Review the copied rules and proceed as usual to create rules using the latest version of the rule template.

Verify the Spreadsheet Upload

The Upload History section displays details of the spreadsheet uploads such as the date, user, rule template used, and the status.

If the rule upload process fails, the status is displayed as Error. Click Error to download the Error CSV file. Review the error details, resolve the errors in the spreadsheet, and generate the rule file again.

Related Topics

Migrate Workflow Rules to Simplified Workflow Rules Configuration Templates

Import existing rules from Oracle Business Process Management (BPM) directly into spreadsheet-based templates.

You can then use the spreadsheet to view and update these rules, before uploading this spreadsheet back on the Manage Rules in Spreadsheet page. Previously, BPM rules had to be manually entered into the spreadsheets to use the Simplified Workflow Rules Configuration feature.

At present, you can use this feature to migrate rules for these workflows:

Payables Invoice Approval
General Ledger Journal Approval

Here's how you migrate BPM rules to a Simplified Workflow Rules Configuration spreadsheet:

Download a BPM rules file.
Import the rules from the BPM rules file into the Simplified Workflow Rules Configuration template for the workflow.

Download BPM Rules File

Perform these steps to download a file that contains the BPM rules:

Go to the Manage Workflow Rules in Spreadsheet page.
In the Migrate Rules from BPM section, click Download BPM Rules.
On the Download BPM Rules dialog box, select the workflow for which you want to download the rules.
Click OK.

Note: The BPM rule file is generated only when your rules are supported for migration. You get a message when your rules aren’t supported for migration. In such cases, you must use Oracle BPM to manage your rules. Click BPM Worklist to go to the Task Configuration tab of the BPM Worklist.

A copy of your current rule configuration for a workflow is saved in UCM when you successfully download it for the first time. The configuration copy is used to restore the rules back to this state after migration.

Import Rules to Simplified Workflow Rules Configuration Spreadsheet

Here’s how you import the downloaded rules into a Simplified Workflow Rules Configuration spreadsheet:

Go to the Manage Workflow Rules in Spreadsheet page.
In the Rule Templates section, select any of the available templates for a workflow and click the Download icon in the same row.
Open the downloaded file and go to the Instructions sheet.
Click the Import Rules button and then select the BPM rule file downloaded previously. This imports your BPM rules into the spreadsheet.

Note: Ensure that you select a template for the workflow for which you want to migrate the rules. For example, you must use an Invoice approval workflow template to migrate Invoice rules.

Once the rule migration has completed, you can review the rules and proceed to use this template to view and modify the rules. Once you’re done, go to the Instructions sheet and generate the rule file. Next, upload the rule file on the Manage Workflow Rules in Spreadsheet page. The migration process is completed only after a successful upload.

Restore Rules

Use the Restore Rules feature to restore the rules to their previous state (the way they were when the BPM rules file was first downloaded).

Here’s what you do to restore the rules:

Go to the Manage Workflow Rules in Spreadsheet page.
In the Migrate Rules from BPM section, click Restore Rules.

Note: The Restore Rules button is enabled only when there is at least one workflow for which a BPM rule file has been successfully downloaded at least once previously.
On the Restore Rules dialog box, select the workflow for which you want to restore the rules.
Click OK.

After you confirm this action, the configuration file stored in UCM is used to restore the workflow rules to the state before migration.

Note: The Restore Rules always restores the rules to the state they were in at the first time the rule file was ever downloaded. Even if you subsequently change the BPM rules and download the rules file again, this doesn’t change the rules file stored in the UCM. It remains the same as the first time the rule file was ever downloaded.

Modify Workflow Rules Using a Spreadsheet

After creating the rules using a spreadsheet template, you can modify them using a spreadsheet.

Note: Each time you make modifications, a new set of rules are created. The new rules overwrite the existing rules.

To modify workflow rules using a spreadsheet, perform the following steps:

Navigate to the Manage Rules in Spreadsheet page.
In the Rule templates section, select the required workflow.
For the workflow, select the link in the Last Successful Upload column. Save the copy of the last successfully uploaded rule template to your local computer.
Make the necessary changes in the spreadsheet and click Generate Rule File. A compressed file is generated. Save the generated rule file in your local directory.
On the Manage Rules in Spreadsheet page, select the required workflow in the Rule Templates section.
Click Upload. The Upload File dialog box appears.
In the File field, click Choose File.
From your local directory, select the compressed rule file to be uploaded for the rule creation that was generated from the workflow rules template.
Click Submit. A confirmation message stating the process ID appears.
Click OK.
Check the status of the upload in the Upload History section.

Note: If the upload fails, the status is displayed as Error. Click Error to download the Error CSV file. Review the error details, resolve the errors, and generate the rule file again.

Workflow Rule Templates for Journal Approval

The Simplified Workflow Rules Configuration feature enables you to create rules for the General Ledger Approval workflow using a spreadsheet. You can select from among the available sample templates in the Download column on the Manage Workflow Rules in Spreadsheet page:

Journal Approval Basic Template
Journal Approval Sample Template 1
Journal Approval Sample Template 2

Each template contains two worksheets: Instructions and Journal Approval Rules. The Journal Approval Rules worksheet contains sample rules. You can modify them or define your own rules.

You use the templates to create approval rules in accordance with your approval policy. Each sample template contains use cases that you can refer to. You can define your specific rules using any of the templates.

Journal Approval Basic Template: Supervisory Hierarchy-Based Approval

The rule in this template demonstrates the following approval policy requirement:

All journal batches require approval from the direct supervisor of the user submitting the batch for approval.

You don't have to make any changes to this rule to use it.

Note: The General Ledger Journal workflow implementation comes with a predefined rule. That rule is represented in the Journal Approval Basic Template.

Tip: You can upload this sample rule to reset the journal approval rule back to its predefined state.

Journal Approval Sample Template 1: Group-Based Approval

The rules in this template demonstrate the following approval policy requirement:

All journal batches from a specific ledger and from the specific journal sources require approval from one user of the nominated approval groups. The approval group is different when the journal batch has been created by some nominated users and has some specific description.
Journal batches from sources other than these sources are automatically rejected.

The business rule from the approval policy is represented in one block in this template with four listed rules.

To use these rules, ensure:

The approval groups that you enter in the spreadsheet are defined in the approval management application.
The specified users are valid.
The specified ledger ID is valid.

Note: When a journal batch satisfies more than one rule within a block, the notification flow and approval process completion can vary depending on the approval routings specified for those rules within that block. For this template, if a journal batch satisfies more than one rule, all of the users of the nominated groups are notified, and only one user must take an action to complete the approval process.

Journal Approval Sample Template 2: Supervisory Hierarchy and Group-Based Approval

The rules in this template demonstrate the following approval policy requirement. The business rules are represented in multiple blocks depending on the business requirement and the approval routing.

First block: All journal batches for journal sources Manual, AutoCopy, and Spreadsheet, and with a total batch amount greater than 250000, require supervisory approval. Any batch from those same sources with a total batch amount up to 250000 is automatically approved. Journal batches from sources other than these sources don't require this type of approval.
Second block: All journal batches with a total batch amount up to 250000 for journal sources Allocations, Revaluation, and Balance Transfer, require approval from any one member of the designated approval group. All journal batches with a total batch amount up to 250000 for journal sources other than these sources don't require this type of approval. All journal batches with a total batch amount greater than 250000 don't require this type of approval.
Third block: All journal batches with a total batch amount greater than 250000 for the journal sources Allocations, Revaluation, and Balance Transfer, require approval from all members of the designated approval group. All journal batches with a total batch amount greater than 250000 for journal sources other than these sources don't require this type of approval. All journal batches with a total batch amount up to 250000 don't require this type of approval.

To create rules for these business rules, you must first analyze and separate the requirements into distinct rules. All the rules that are included in a block must be collectively exhaustive. It's important that all approval scenarios are defined. If not, errors might occur.

The following table displays the details of the rules that are created to enforce the business requirement presented in the first block in this sample template.

Rule Name	Approval Routing	Approval Condition Attribute	Approval Condition Operator
Source_amount up to 250000	Auto Approve	Journal Batch Total Accounted Credit	<=250000
		Journal Source Name	in (Manual, AutoCopy, Spreadsheet)
Source_amount up to 250000_other source	Skip Approval	Journal Batch Total Accounted Credit	<=250000
		Journal Source Name	not in (Manual, AutoCopy, Spreadsheet)
Source_amount greater than 250000	Supervisory	Journal Batch Total Accounted Credit	>250000
		Journal Source Name	in (Manual, AutoCopy, Spreadsheet)
Source_amount greater than 250000_other source	Skip Approval	Journal Batch Total Accounted Credit	>250000
		Journal Source Name	not in (Manual, AutoCopy, Spreadsheet)

The same logical process is followed to define rules for the remaining approval policy requirements.

To use this rule, ensure the approval groups that you enter in the spreadsheet are defined in the approval management application.

Approval Conditions in Journal Approval Rule Templates

For the journal approval workflow, approval conditions define the criteria that a journal batch is evaluated against. The approval conditions are defined using the attributes available in the drop-down list of each attribute category. There are three default attribute categories: Journal Batch, Journal Header, Journal Line.

You can use the predefined approval conditions in the sample rule templates, or you can modify the conditions to meet your company approval policy requirements.

In addition to the attribute categories displayed in the rule templates, you can add more attribute categories by selecting the drop-down list after the last displayed attribute category.

Here's the list of attribute categories that you can use to define your approval conditions:

Journal Batch Approval Requester
Journal Batch Creator
Journal Batch Ledger
Journal Batch Source
Journal Category
Journal Calendar
Journal Header
Journal Line
Maximum Amount Journal
Maximum Amount Journal Line
Period
Submitted Period

Each attribute category has its own set of attributes that you can select from.

Rule Evaluation Currency Attribute

To create workflow rules that should be evaluated in a specific currency, enter the currency using the attribute Rule Evaluation Currency. The attribute is available for these attribute categories:

Journal Header
Journal Line
Maximum Amount Journal
Maximum Amount Journal Line

Specify the currency value following the ISO 4217 standard. The resulting rules that are created apply Corporate as the rate type and the Accounting Date as the rate date for evaluating transactions that satisfy rule conditions.

Create Journal Approval Rules Using Oracle Business Process Management

Watch video

You can use the Business Process Management Worklist application to configure journal approval rules. For example, you can create journal approval rules that automatically approve a journal batch, or that route the batch for approval based on the ledger and journal amounts.

This procedure creates the following approval rules:

When the largest journal amount in a batch is more than 500, and less than 10,000, the batch requires one level of supervisory approval.
When the largest journal amount is 10,000 or more, two levels of supervisory approval are required.
If the largest journal amount in a batch is 500 or less, the batch doesn't require approval or it's automatically approved.

Create a Rule That Requires One Level of Supervisory Approval

In the Global menu, click the Notifications icon and select More Details. If you're using the news feed default home page layout, then select Show All and click Worklist.
Select Financials. The Business Process Management Worklist application page opens.
Click your user name and select Administration. You can manage the journal approval rules only if you have administrator access.
Click the Task Configuration tab.
From the Tasks to be configured pane, select the FinGLJournalApproval task.
Click Edit task to create the rules.
Click the Assignees tab. The Assignees page shows the participant tree. A participant is a user or set of users in the approval assignment and routing definition. The journal approval task displays three predefined participants. Typically you use only one or two participants, but have the flexibility to add more participants to meet more complex approval requirements. Each participant is associated with one rule set, and a rule set can have one or more approval rules.
On the Supervisory Journal Approver participant, click Go to rule.
Click the Expand icon on the Manager Approval Rule. That's the default predefined approval rule. If a journal's ledger and source are enabled for approval, the rule is configured to send that journal for one level of approval to the supervisor of the person who submitted the journal for approval.
Click the Show Advanced Settings icon.
Click in the Active check box to deselect it. When this check box is cleared, the approval routing process doesn't use the rule.
Click the Add Rule icon.
In the Name field, enter the name of the rule: Between 500 and 10000.
Click Expand. Each rule defines the conditions for when the journal batch should be approved and by whom.

Note: The IF component evaluates the journal based on batch, journal, or journal line-level attributes. The THEN component determines who the approval should be routed to.
In the IF section, click the Left Value icon. The Condition Browser window opens.
Click the Expand icon on the Maximum Amount Journal folder.
Click the Name attribute, which represents the ledger name.
Click OK. The Condition Browser window closes and the attribute name is populated in the Left Value field.
In the Right Value field, enter the name of the ledger in quotation marks, for example, enter "Vision Corporation".

Note: The first condition uses the operator named is. This operator compares the two values.
Click the Add simple test icon from the list to add another condition.
Click the Left Value icon. The Condition Browser window opens.
Expand the Maximum Journal Amount folder and select the Maximum Accounted Amount Credit attribute. This attribute stores the maximum accounted credit amount across all journals in the batch.
Click OK. The Condition Browser window closes.
In the second condition, click in the Operator field and select the operator named between.
Click the Right Value icon. The Right Operand window opens.
In the Operand 1 field, enter the lower limit as 500.
In the Operand 2 field, enter the upper limit as 10000.
Click OK. The Right Operand window closes.
To configure the action to send the journal batch for one level of supervisory approval, click the Add Action icon in the THEN section.
Select Add Approver and select Supervisory.

Note: The Supervisory list builder generates the list of approvers by moving up the supervisory hierarchy that's set up in the Human Resources application. Specify the number of approvers, the first approver, and the highest possible approver.
To route the journal batch for one level of supervisory approval, in the Number of levels field, enter 1.
In the Starting Participant field, click Search. The Add Hierarchy Participant window opens and the Get Manager option is selected by default.
For this rule, the starting participant or first approver, is going to be the manager of the person who submits the journal batch for approval. In the Reference User field, enter Task.Workflow Submitter.
Click OK. The Add Hierarchy Participant window closes.
In the Top Participant field, click Search. The Add Hierarchy Participant window opens.

Note: The top participant is the last user in the approval hierarchy. The list builder continues to add users to the approvers list from the supervisory hierarchy of the first approver, until the number of levels is met, or the top participant is reached.
Click the Get User button.
In the Reference User field, enter the sign in name of the top participant within quotation marks.
Click OK. The Add Hierarchy Participant window closes.
From the Tasks to be configured pane, click Save. The Enter Comments window opens.
Click OK. The Enter Comments window closes and a message appears stating that the rule has been saved.
Click OK.

Create a Rule That Requires Two Levels of Supervisory Approval

Create a rule for the same ledger requiring two levels of supervisory approval if the largest journal amount is 10,000 or more. Copy the first rule and make changes for this second rule.

Click the Assignees tab.
Select the first rule.
Click the list on the Cut icon and select Copy.
Click the list on the Cut icon and select Paste. The second rule appears after the first rule.
In the Name field for the second rule, enter Greater than 10000.
Click Expand.
The first condition in the IF section that checks for the ledger, stays the same. Change the operator of the second condition to same or more than.
In the Right Value field, enter 10000.
In the THEN section, in the Number of levels field, enter 2.
Click Collapse. The second approval rule is complete.

Create a Rule That Automatically Approves Journals

Create the rule that automatically approves journals that are 500 or less for a specific ledger. The rule must also ensure that journal batches for all other ledgers are automatically approved as well.

Caution: It's very important that the rules in a rule set cover all conditions and are collectively exhaustive. If not, errors might occur.

Select the first rule.
Click the list on the Cut icon and select Copy.
Click the list on the Cut icon and select Paste. The third rule appears after the first rule.
Click in the Rule Name field and rename the third rule to Less than 500.
Click the Expand icon to open the new rule.
Create a condition for journals 500 or less in the specified ledger by first grouping the two existing conditions together. In the IF section, click both conditions to select them.
Click the Surround selected tests with parenthesis icon. Both conditions are now enclosed within a set of parentheses.
Click in the Operator field of the second condition and select same or less than from the list. The amount automatically changes to 500.
Now add another condition to cover all of the other batches that don't have journals for the specified ledger. Click the Add simple test icon. A third condition row is added after the two grouped conditions.
Since this new condition is mutually exclusive to the grouped conditions, click the connector to change it from and to or.
Click the Left Value icon. The Condition Browser window opens.
Expand the Maximum Journal Amount folder and select Name.
Click OK. The Condition Browser window closes.
Click in the Operator field and select the operator named isn't.
In the Right Value field, enter the name of the ledger in quotation marks.
Now set up the automatic approval. The Supervisory list builder has two parameters that override the supervisory approval and return a preconfigured approval action. In the THEN section, click in the Auto Action Enabled field, and select True.
In the Auto Action field, enter "APPROVE". Include the quotation marks.
Collapse the rule.

You have now defined three rules that meet the business requirements and are collectively exhaustive. All journal batches satisfy the conditions in at least one of the three rules and are routed for approval accordingly. If a journal batch doesn't satisfy the conditions in at least one rule within a rule set, the rule evaluation process would fail with errors.
Deploy the rules so that they can be used. On the Tasks to be configured toolbar, click the Commit Task icon. The Enter Comments window opens.
Click OK. The Enter Comments window closes and a message appears stating that the data rule has been saved and committed.
Click OK.

After journal approval is enabled, journal batches being posted are submitted for approval based on these rules.

Predefined Journal Approval Participants and Attributes

You can configure journal approval rules in the Business Process Management Worklist application. Open the Worklist application by selecting the Notifications icon on the home page and clicking More Details or, by using the following in the Setup and Maintenance work area:

Offering: Financials
Functional Area: Application Extensions
Task: Manage Task Configurations for Financials

The name of the journal approval workflow task is FinGlJournalApproval.

Assignees

Assignees, also called participants, are users or a set of users that an approval request is routed to. There are four types of assignees.

Single: Maps to a user, group, or role. Select this type if the approval request requires only a single user to approve. When the request is sent to a group or to an application role, all of the users within that group or that carry that application role receive the notification, but only one user's approval is required.
Parallel: Indicates that a set of people work in parallel and that everyone's approval is required. For example, a journal batch affects multiple lines of business and requires approval from the controllers for each line of business. The controllers can approve the journal batch in parallel.
Serial: Indicates that a set of users must work in sequence. The most common scenario is supervisory chain approval, which is done by specifying that the list is based on a supervisory chain.
FYI: Maps to a single user, group, or role, just as the Single assignee type. However, this type of assignee just receives a notification, and the business process doesn't wait for the assignee's response. FYI assignees can't directly impact the outcome of a task, but in some cases can provide comments or add attachments.

The journal approval workflow task contains three assignees (participants) with a type of Single, Serial, and Parallel, each. These three predefined assignees are arranged in the parallel mode. Assignees can be arranged in parallel or sequential mode. For assignees in parallel mode, a task is assigned and notifications are sent to all of the assignees at once in parallel. For assignees in sequential mode, a task is assigned and notifications are sent in a sequential manner, meaning one after another, to each assignee.

You can select to use any one, or combination of, the three assignees. You can delete them, or add new ones as needed. The Serial type assignee has a predefined journal approval rule based on the requester's supervisory hierarchy. If a ledger and journal source are enabled for approval, the predefined journal approval rule sends a journal belonging to that ledger and source to the requester's manager for approval.

Attributes

The tables in this section list the objects and attributes that appear in the Condition Browser window in the Worklist application.

The following table describes the attributes for the Journal Batch object.

Name	Description
Accounting Period Type	Name of the accounting calendar.
Batch Type Indicator	Indicator for the type of amounts that the batch contains. Valid values are A or E, representing the following respective types: Actual and Encumbrance.
Approval Status	Approval status of the journal batch. Valid values are A, I, J, V, R, or Z, representing the following respective statuses: Approved, In Process, Rejected, Validation Error, Required, and Not Required. For Oracle internal use only.
Approver Employee ID	Internal identifier of the employee who submitted the batch for approval. For Oracle internal use only.
Average Balance Journal Indicator	Indicator for whether the journal is an average balance journal. Valid values are Y or N, representing Yes and No.
Batch Amount	Amount of the journal batch.
Budgetary Control Status	Not currently used.
Calendar	Reference to the Calendar object. For Oracle internal use only.
Chart of Accounts ID	Internal identifier of the chart of accounts.
Control Total	Control total of the journal batch.
Created By	Sign in name of the user who created the journal batch.
Creation Date and Time	Date and time when the journal batch was created.
Creation Date	Date when the journal batch was created. For Oracle internal use only.
Default Accounting Date	Internal default accounting date. For Oracle internal use only.
Accounting Period Name	Accounting period of the journal batch.
Description	Description of the journal batch.
Earliest Postable Date	For Oracle internal use only.
Group ID	Internal identifier of the interface group. For Oracle internal use only.
Batch ID	Internal identifier of the journal batch. For Oracle internal use only.
Source	Internal identifier of the journal source. For Oracle internal use only.
Journal Batch Ledger	Reference to the Journal Batch Ledger object. For Oracle internal use only.
Journal Batch Source	Reference to the Journal Batch Source object. For Oracle internal use only.
Journal Header	Reference to the Journal Header object. For Oracle internal use only.
Last Updated Date	Date when the journal batch was last updated.
Last Updated Login	For Oracle internal use only.
Last Updated By	Sign in name of the user who last updated the batch.
Lookup Code	For Oracle internal use only.
Lookup Type	For Oracle internal use only.
Maximum Amount Journal	Reference to the Maximum Amount Journal object. For Oracle internal use only.
Maximum Journal Line Amount	Reference to the Maximum Journal Line Amount object. For Oracle internal use only.
Batch Type	Full text value for the Batch Type Indicator attribute. Valid values are Actual or Encumbrance.
Name	Name of the journal batch.
Object Version Number	For Oracle internal use only.
Packet ID	For Oracle internal use only.
Parent Batch ID	For Oracle internal use only.
Period	Reference to the Period object. For Oracle internal use only.
Accounting Period Set Name	Accounting calendar name for the accounting period.
Posted Date	For Oracle internal use only.
Posting Run ID	Internal identifier. For Oracle internal use only.
Request ID	Internal identifier. For Oracle internal use only.
Accounted Running Total Credit	Total accounted credit amount of the journal batch.
Accounting Running Total Debit	Total accounted debit amount of the journal batch.
Entered Running Total Credit	Total entered credit amount of the journal batch.
Entered Running Total Debit	Total entered debit amount of the journal batch.
Status	Status of the journal batch. Valid values are u, U, S, I, or P, representing the following respective statuses: Incomplete, Unposted, Selected for Posting, Processing, and Posted.
Status Verified by Posting Indicator	Indicator for whether the status of the journal batch has been verified. Valid values are Y and N, representing Yes and No. For Oracle internal use only.
Submitted Period	Reference to the Submitted Period object. For Oracle internal use only.
Not Reserved Packet ID	For Oracle internal use only.
Journal Batch Creator	Reference to the Journal Batch Creator object. For Oracle internal use only.
Journal Batch Approval Requester	Reference to the Journal Batch Approval Requester object. For Oracle internal use only.
Funds Status	Budgetary control status for the batch. A list of valid values can be found in the lookup type XCC_BC_FUNDS_STATUSES. For example, RESERVED_PARTIAL or RESERVED_PASSED, representing Partially reserved and Reserved.
Chart of Accounts Code	The chart of account structure code used to record transactions and maintain account balances.
Descriptive Flexfield Structure Definition 1	Structure definition of the Journal Batches descriptive flexfield.
Descriptive Flexfield Attributes 1 through 10	Segments of the Journal Batches descriptive flexfield.

The following table describes the attributes for the Journal Batch Ledger object.

Name	Description
Batch ID	Internal identifier of the journal batch. For Oracle internal use only.
Currency	Currency of the ledger. For example USD or EUR.
Ledger Category Code	Category of the ledger. Valid values are SECONDARY, PRIMARY, NONE, and ALC, representing the following respective categories: Secondary Ledger, Primary Ledger, None, and Reporting Currency.
Ledger Enabled for Journal Approvals Indicator	Indicator for whether approval is enabled for the ledger. Valid values are Y or N, representing Yes and No.
Ledger ID	Internal identifier of the ledger.
Ledger Name	Name of the ledger.
Meaning	For Oracle internal use only.
Period Set Name	Internal name for the accounting calendar, which is the original calendar name that a user entered. For Oracle internal use only.
Primary Ledger Currency	Ledger currency defined for the primary ledger. For example, USD or EUR.
Descriptive Flexfield Structure Definition	Structure definition of the Ledgers descriptive flexfield.
Descriptive Flexfield Attributes 1 through 15	Segments 1 through 15 of the Ledgers descriptive flexfield.

The following table describes the attributes for the Journal Batch Source object.

Name	Description
Journal Source ID	Internal identifier of the journal source. For Oracle internal use only.
Journal Reference Indicator	Indicates whether journal import saves the references to the subledger transactions. Saved references let you drill from a general ledger journal to the subledger transaction. Valid values are Y or N, representing Yes and No.
Override Edits Indicator	Indicator for whether a user can update the journal that has the journal source. Valid values are Y, N, or P, representing Yes, No, and Partial, respectively.
Type	Identifies whether the source for the batch is a subledger application. Valid values are SLA or Non-SLA, representing subledger accounting and nonsubledger accounting, respectively.
Journal Source Name	User-defined name for the journal source.
Source Key	Unique identifier for a journal source.
Descriptive Flexfield Attributes 1 through 5	Segments 1 through 5 of the Journal Sources descriptive flexfield.

The following table describes the attributes for the Journal Calendar object.

Name	Description
Calendar ID	Internal identifier of the accounting calendar. For Oracle internal use only.
Period Set ID	Internal identifier. For Oracle internal use only.
Period Set Name	Name of the accounting calendar when first created. If the calendar name is later changed in the user interface, this original name remains stored internally as a unique identifier. For Oracle internal use only.
Period Type	Internally generated value based on period frequency of the accounting calendar. For Oracle internal use only.
Period Type ID	Internal identifier of the period type. For Oracle internal use only.
User Period Set Name	Current name of the accounting calendar.
Descriptive Flexfield Structure Definition	Structure definition of the Calendars descriptive flexfield.
Descriptive Flexfield Attributes 1 through 5	Segments 1 through 5 of the Calendars descriptive flexfield.

The following table describes the attributes for the Journal Category object.

Name	Description
Category ID	Internal identifier of the journal category. For Oracle internal use only.
Journal Category Name	Translated name of the journal category. Might not uniquely identify a category in an approval rule. Varies depending on a user's language setting.
Category Key	User-defined category key that uniquely identifies the category.
Descriptive Flexfield Structure Definition	Structure definition of the Journal Categories descriptive flexfield.
Descriptive Flexfield Attributes 1 through 5	Segments 1 through 5 of the Journal Categories descriptive flexfield.

The following table describes the attributes for the Journal Header object.

Name	Description
Reversed Journal Indicator	Indicator for whether the journal was reversed. Valid values are Y or N, representing Yes and No.
Accounted Currency	Currency of the ledger. For example, USD or EUR.
Accounting Date	Accounting date of the journal.
Batch ID	Internal identifier of the journal batch. For Oracle internal use only.
Category	Internal identifier of the journal category. For Oracle internal use only.
Journal from Subledger Indicator	Indicator for whether the journal was created through subledger accounting. Valid values are Y or N, representing Yes and No.
Header ID	Internal identifier of the journal. For Oracle internal use only.
Journal Header Category	Reference to the Journal Header Category object. For Oracle internal use only.
Journal Line	Reference to the Journal Line object. For Oracle internal use only.
Ledger ID	Identifier for the ledger.
Ledger Name	Name of the ledger.
Reference Date	Reference date entered for the journal.
Running Total Accounted Credit	Total accounted credit amount of the journal.
Running Total Accounted Debit	Total accounted debit amount of the journal.
Attachment Exists Indicator	Indicator for whether the journal has attachments. Valid values are Y or N, representing Yes and No.
Entered Currency	Entered currency of the journal. For example, USD or EUR.
Journal Description	Description of the journal.
Journal Name	Name of the journal.
Reversing Journal Indicator	Indicator for whether the journal resulted from a reversal. Values are Y or N, representing Yes and No.
Clearing Company	Intercompany clearing entity used to balance the journal.
Control Total	Control total entered for the journal.
Conversion Date	Date for the conversion rate, which is used to convert an amount into another currency.
Encumbrance Type	Type of encumbrance for journal batches with the Encumbrance batch type.
Journal Reference	Additional information entered by a user.
Legal Entity	Name of the legal entity associated with the journal.
Total Entered Credit	Total journal batch credit amount in the entered currency.
Total Entered Debit	Total journal batch debit amount in the entered currency.
Conversion Rate Type	Source of a currency conversion rate, for example User, Spot, and Corporate.
Descriptive Flexfield Structure Definition 1	Structure definition of the Journals descriptive flexfield.
Descriptive Flexfield Attributes 1 through 10	Segments 1 through 10 of the Journals descriptive flexfield.

The following table describes the attributes for the Journal Line object.

Name	Description
Accounted Credit	Accounted credit amount of the journal line.
Accounted Debit	Accounted debit amount of the journal line.
Entered Currency	Entered currency of the journal line. For example, USD or EUR.
Accounted Currency	Ledger currency of the journal line. For example, USD or EUR
Entered Credit	Entered credit amount of the journal line.
Entered Debit	Entered debit amount of the journal line.
Header ID	Internal identifier of the journal. For Oracle internal use only.
Line Number	Number of the journal line.
Ledger ID	Internal identifier of the ledger. For Oracle internal use only.
Ledger ID 1	For Oracle internal use only.
Account	Reference to the Account object. For Oracle internal use only.
Chart of Accounts ID	Internal identifier of the chart of accounts.
Account Combination ID	Internal identifier of the account combination.
Concatenated Segment	For Oracle internal use only.
Account Combination	Concatenated segments separated by the key flexfield delimiter. For example, 101-10-110-11010-0000.
Account Type	Valid values are A, L, E, R, or O, representing the following respective account types: Asset, Liability, Expense, Revenue, and Owner Equity.
Conversion Date	Date for the conversion rate, which is used to convert an amount into another currency.
Conversion Rate Type	Source of a currency conversion rate, for example User, Spot, and Corporate.
Detail Posting Allowed	Indicator for whether the account allows posting. Valid values are Y and N.
Account Enabled	Indicator for whether the account is available for use.
Account End Date	The date when the account becomes inactive.
Financial Category	Group assigned to a Natural Account segment value. Used for reporting with Oracle Transactional Business Intelligence. A list of accepted values is defined in the FINANCIAL_CATEGORY lookup type.
Reconciliation Enabled Account	Indicator assigned to a Natural Account segment value for whether the account is enabled for reconciliation. Valid values are Y and N.
Control Account	Setting assigned to a Natural Account segment value for maintaining detailed balances by third party. Valid values are CUSTOMER, N, R, SUPPLIER, and Y, representing the following respective controls: Customer Control Account, No, Restricted GL Manual Journals, Supplier Control Account, and Third-Party Control Account.
Account Start Date	The date when the account becomes active.
Account Segments 1 through 30	Value of a segment in the account combination.
Descriptive Flexfield Structure Definition 1	Structure definition of the Journal Lines descriptive flexfield.
Descriptive Flexfield Attributes 1 through 10	Segments 1 through 10 of the Journal Lines descriptive flexfield.
Descriptive Flexfield Structure Definition 3	Structure definition of the Journals Captured Information descriptive flexfield.
Descriptive Flexfield Attributes 11 through 20	Segments 11 - 20 of the Journals Captured Information descriptive flexfield.

The following table describes the attributes for the Maximum Amount Journal object.

Name	Description
Batch ID	Internal identifier of the batch. For Oracle internal use only.
Journal Ledger Category Code	Category of the ledger. Valid values are SECONDARY, PRIMARY, NONE, and ALC, representing the following respective categories: Secondary Ledger, Primary Ledger, None, and Reporting Currency.
Ledger Enabled for Journal Approval Indicator	Indicator for whether approval is enabled for the ledger. Valid values are Y or N, representing Yes and No.
Ledger ID	Internal identifier for the ledger. For Oracle internal use only.
Name	Name of the ledger.
Maximum Accounted Amount Credit	Maximum accounted credit journal amount of the journal batch.
Maximum Accounted Amount Debit	Maximum accounted debit journal amount of the journal batch.
Maximum Net Accounted Amount	Maximum accounted net journal amount of the journal batch.
Accounted Currency	Currency of the ledger. For example, USD or EUR.

The following table describes the attributes for the Maximum Amount Journal Line object.

Name	Description
Batch ID	Internal identifier of the journal batch. For Oracle internal use only.
Journal Ledger Category Code	Category of the ledger. Valid values are SECONDARY, PRIMARY, NONE, and ALC, representing the following respective categories: Secondary Ledger, Primary Ledger, None, and Reporting Currency.
Ledger Enabled for Journal Approval Indicator	Indicator for whether approval is enabled for the ledger. Valid values are Y or N, representing Yes and No.
Ledger ID	Identifier of the ledger. For Oracle internal use only.
Ledger Name	Name of the ledger.
Maximum Accounted Line Amount Credit	Maximum accounted credit amount of a journal line in the journal batch for the ledger. For example, if a journal batch has five credit lines, this attribute holds the largest value of those five credit lines.
Maximum Accounted Line Amount Debit	Maximum accounted debit amount of a journal line in the journal batch for the ledger. For example, if a journal batch has five debit lines, this attribute holds the largest value of those five debit lines.
Maximum Net Accounted Line Amount	Maximum accounted net amount of a journal line in the journal batch for the ledger.
Accounted Currency	Currency of the ledger. For example, USD or EUR.

The following table describes the attributes for the Period object, which has details for the period that the journal belongs to.

Name	Description
Description	Description of the accounting period.
End Date	End date of the accounting period.
Name	Name of the accounting period.
Number	Number of the accounting period in the fiscal year.
Set Name	Name of the accounting calendar when first created. If the calendar name is later changed in the user interface, this original name remains stored internally as a unique identifier.
Type	Internally generated value based on the period frequency of the accounting calendar. For Oracle internal use only.
Year	Year for the accounting period.
Quarter Number	Quarter number of the accounting period.
Start Date	Start date of the accounting period.
Adjustment Period Indicator	Indicator for whether the period is an adjustment period. Valid values are Y or N, representing Yes and No.
Descriptive Flexfield Structure Definition	Structure definition of the Accounting Calendar Periods descriptive flexfield.
Descriptive Flexfield Attributes 1 through 8	Segments 1 through 8 of the Accounting Calendar Periods descriptive flexfield.
Descriptive Flexfield Dates 1 through 5	Date segments 1 through 5 of the Accounting Calendar Periods descriptive flexfield.
Descriptive Flexfield Numbers 1 through 5	Number segments 1 through 5 of the Accounting Calendar Periods descriptive flexfield.

The following table describes the attributes for the Submitted Period object, which has details for the period in which a journal was submitted for approval.

Name	Description
Adjustment Period Indicator	Indicator for whether the period is an adjustment period. Valid values are Y or N, representing Yes and No.
End Date	End date of the accounting period.
Most Recent Period End Date	End date of the accounting period that's two months before the current accounting period. For example, if a journal is submitted for approval in February 2018, this attribute would contain December 31, 2017.
Name	Name of the accounting period for the journal.
Number	Number of the accounting period in the fiscal year.
Set Name	Name of the accounting calendar when first created. If the calendar name is later changed in the user interface, this original name remains stored internally as a unique identifier.
Type	Internally generated value based on the period frequency of the accounting calendar. For Oracle internal use only.
Year	Accounting period year.
Previous Period End Date	End date of the previous accounting period. For example, if a journal is submitted for approval in February 2018, this attribute would contain January 31, 2018.
Start Date	Start date of the accounting period.
Descriptive Flexfield Structure Definition	Structure definition of the Accounting Calendar Periods descriptive flexfield.
Descriptive Flexfield Attributes 1 through 8	Segments 1 through 8 of the Accounting Calendar Periods descriptive flexfield.
Descriptive Flexfield Dates 1 through 5	Date segments 1 through 5 of the Accounting Calendar Periods descriptive flexfield.
Descriptive Flexfield Numbers 1 through 5	Number segments 1 through 5 of the Accounting Calendar Periods descriptive flexfield.

Related Topics

Update Existing Setup Data

Examples of Maximum Amount Journal and Maximum Amount Journal Line Objects in Journal Approval Rules

Offering: Financials
Functional Area: Application Extensions
Task: Manage Task Configurations for Financials

The name of the journal approval workflow task is FinGlJournalApproval.

To configure journal approval rules that route journals for approval based on amounts, you can use the Maximum Amount Journal and Maximum Amount Journal Line objects in your approval rule definitions.

Maximum Amount Journal

To route journal batches for approval based on the largest journal amount within a batch, you can use the Maximum Amount Journal object in your approval rule definition. For a journal batch, this object contains the maximum accounted debit and credit amounts at the journal level, per ledger.

The following table shows an example of a journal batch that has four journals for two ledgers with different ledger currencies.

Journal	Ledger	Ledger Currency	Accounted Amount
1	USA	USD	500
2	USA	USD	700
3	France	EUR	500
4	France	EUR	900

Note: Since each journal balances, the value in the Accounted Amount column represents the sum of all of the debits, as well as the sum of all of the credits for each journal.

For the USA ledger, journal 2 has the largest accounted amount of 700. For the France ledger, journal 4 has the largest accounted amount of 900. This journal batch is represented in the Maximum Amount Journal object by two rows of information, one row for each ledger.

The following table shows the relevant attributes in the Maximum Amount Journal object and the values that these attributes contain.

Name (Ledger)	Maximum Accounted Amount Debit	Maximum Accounted Amount Credit
USA	700	700
France	900	900

The values for the debit and credit amount attributes for the USA ledger row are 700, and the values for the debit and credit amount attributes for the France ledger row are 900.

Maximum Amount Journal Line

To route journal batches for approval based on the largest journal line amounts, you can use the Maximum Amount Journal Line object in your approval rule definition. For a journal batch, this object contains the maximum accounted debit and credit amounts at the journal line level, per ledger.

The following table shows an example of a journal batch that has two journals for two ledgers with different ledger currencies. Each journal has four lines.

Journal	Ledger	Ledger Currency	Journal Line Number	Accounted Debit	Accounted Credit
1	USA	USD	1	400
1	USA	USD	2	100
1	USA	USD	3		400
1	USA	USD	4		100
2	France	EUR	1	200
2	France	EUR	2	300
2	France	EUR	3		200
2	France	EUR	4		300

For the USA ledger, the journal line with the largest accounted debit is number 1 with 400. The journal line with the largest accounted credit is number 3, also with 400. For the France ledger, the journal line with the largest accounted debit is number 2 with 300. The journal line with the largest accounted credit is number 4, also with 300. This journal batch is represented in the Maximum Amount Journal Line object by two rows of information, one row for each ledger.

The following table shows the relevant attributes in the Maximum Amount Journal Line object and the values that the attributes contain.

Ledger Name	Maximum Accounted Line Amount Debit	Maximum Accounted Line Amount Credit
USA	400	400
France	300	300

The values for the debit and credit amount attributes for the USA ledger row are 400, and the values for the debit and credit amount attributes for the France ledger row are 300.

Related Topics

Update Existing Setup Data

Workflow Transaction Console

Overview of Workflow Transaction Console for Financials

Use the workflow Transaction Console to monitor and troubleshoot workflow tasks for the Invoice, Expenses, and Journal Approval workflows.

From the console you can:

View the latest status of all workflow tasks.
Review the issue description and resolution for failed tasks.
Take appropriate action on a failed task.
Search tasks based on user-defined criteria.
Download search results to a spreadsheet.

Related Topics

Give Users Access to Manage Financials Workflow Transactions

Users can manage transactions for the Invoice, Expenses, and Journal Approvals workflows from the Transaction Console.

Give Financial Users Administrator access

You have a couple of options for giving users access to the Transaction Console work area, depending on whether you're assigning them predefined job roles, or your own configured job roles.

Assign the predefined Financials Application Administrator (ORA_FUN_FINANCIAL_APPLICATION_ADMINISTRATOR_JOB) job role.
Your own configured job role must include the Financial Transaction Approval Reviewing (ORA_FIN_REVIEW_APPROVAL_TRANSACTIONS) duty role.

Limit What Users Can See

By default, users who have access to the Transaction Console work area can see all transactions, from all product families.

To make sure that financial users view only the financial workflows, enable transaction security:

In the Setup and Maintenance work area, go to the Manage Enterprise HCM Information task.
- Offering: Financials
- Functional Area: Enterprise Profile
- Task: Manage Enterprise HCM Information
On the Edit Enterprise page, click Edit and then select Update.
Complete the fields in the Update Enterprise dialog box and click OK.
In the Transaction Console Information section, select Enable Transaction Security.
Click Submit.

Note: You just need to do this for one offering. The setting now applies to all product families. If you're also using Oracle HCM Cloud, make sure transaction security profiles are set up so that HCM administrators can see and act on HCM transactions.

Related Topics

Manage Workflow Transactions

After workflow tasks are created, it's helpful to keep track of them and jump in when you need to, especially when something goes wrong. If you have the appropriate roles, you can monitor and troubleshoot workflow tasks for others and for yourself. Use the Transaction Manager: Transactions page in the Transaction Console work area to manage transactions. A transaction is a business process that involves a workflow task.

Here are some of the things you can do:

Track transaction statuses and download spreadsheets with information about transactions.
Download and review diagnostic logs for transactions with errors.
Depending on what's going on with the transaction and what roles you have, you might be able to, for example, reassign or recover the transaction.

Find Transactions

Follow these steps:

Click Navigator > Tools > Transaction Console.
If you see tabs, make sure you're on the Transaction Summary tab.
On the Transaction Manager: Transactions page, check the Last Refresh time stamp after the page title to see when the transaction statuses were last updated. Click the Refresh icon if needed. You can refresh any time as long as someone else didn't already start a refresh.
- You can also set the Refresh Transaction Administrator Console Transaction Status scheduled process to run on a schedule, to automatically refresh the statuses on a regular basis. Start by setting it to run once every hour, and then see how it goes and adjust from there.
- If you open the details for a specific transaction (step 5), its status also refreshes and you see the latest on the details page.
View the transactions with a status that matches the default Status filter, for example Failed. You can remove this filter to get results for all statuses. Or, use the search and filters to apply your own criteria, for example, to find transactions that are priority 1 or submitted by a specific person.
- You can use the search to find results based on keywords in the Name or Process Name column, or specifically use the Name or Process Name filters. Name is the person or object the workflow task applies to, and the process reflects the type of workflow task.
- You can personalize filters to add or hide filters, and create saved searches for future use.
Select and act on the transactions right there from the results table, or click the transaction in the Name column to see details, such as diagnostic information for failed transactions, and go from there.

Act On Transactions Without Opening Details

Here's what you do:

Select one or more transactions from the results table.
Optionally use the Priority menu to set an issue priority, so that you can later filter on the priority to find these transactions.
Open the Actions menu and select an action. If you selected more than one transaction, you see only the actions that can apply to all of them.

Use Transaction Details

What you can see and do in the transaction details depends on the transaction status and what roles you have. For example, for transactions that are in progress or completed, you might see the approval history, which shows who already approved and who the current assignee is, if any.

For failed transactions, you can get information about the issues and, if you're an administrator, usually take some action:

Select an issue from the Issues list, if the transaction has more than one issue.
Review the information in the Instructions and Details sections, including any description and resolution for the issue, as well as the related workflow task and approval rule.
Click the Download link to get the diagnostic log.
Use the Issue Priority list to set an issue priority, if you want to later filter on the priority to find this transaction.
From the Assigned To list, select the person who should fix the issue, for tracking and filtering purposes.
Add comments, for example to track what you're doing to address the issue, or note down any service request IDs. You and others can see these comments only in the Transaction Console, not with the workflow task in the worklist.
If you can, take action to address the issue. Here are some examples of how you might go about it:
- Open the Actions menu and select an action to manage the transaction.
- Follow up with the person you assigned the issue to or your help desk. Give them the diagnostic log and other information from the transaction details.
- Reconfigure the approval rule that the transaction is based on, and have the workflow task resubmitted.
Select another issue from the Issues list, if any, and go through the same process.
Click Save and Close.

Download a Spreadsheet of Transactions

This is all you need to do:

In the results table, select the transactions you want to include in the spreadsheet. To get all transactions, either select all of them or none at all.
On the Actions menu, click Download.

Related Topics

Statuses for Filtering Transactions

Use the Transaction Manager: Transactions page in the Transaction Console work area to track the status of transactions. For example, you can filter the transactions by status to see just the transactions that are in progress or stuck. These statuses aren't the actual workflow task statuses that you see in the worklist or in notifications.

Status	Description
Auto Recovery	The transaction ran into some issues, but the application is trying to fix them without any action on your end.
Completed	All approvals are done and the transaction successfully went through all processes.
Draft	The transaction is saved but not submitted yet. This status doesn't apply to all product families.
Failed	The transaction has one or more errors, for example, due to a network or database outage, or an issue in the approval rules setup.
In Progress	At least one approval is still pending for the transaction before it's all done.
Stuck	The transaction was submitted, but ran into issues so the workflow task doesn't exist yet.
Submitted	The transaction was just created and hasn't moved on yet to another status. This status doesn't apply to all product families.

Related Topics

Actions and Statuses for Workflow Tasks

Actions for Managing Transactions

Use the Transaction Manager: Transactions page in the Transaction Console work area to manage and troubleshoot transactions. For example, you can withdraw a transaction even if you're not the one who submitted it. What you can do depends on the transaction status and the roles you have. Some actions, such as approve and reassign, are the same as the ones you can take on the workflow tasks from the worklist or from notifications.

Action	Description
Add Comment	Add your notes for the transaction, for example to track what you're doing to address the issue, or to jot down any service request IDs. You and others can see these comments only in the Transaction Console.
Alert Initiator on Error	Notify the submitter if the transaction ends up in error.
Approve	Approve the transaction if the workflow task is currently assigned to you to approve or reject.
Download	Get a spreadsheet with information about the selected transactions.
Reassign	Reassign the workflow task to an approver, the submitter, or someone else.
Recover	Restart the process after the transaction stopped due to errors. After you address the issue, use this action to get the application to pick up where the process last left off and retry whatever had ended up in error.
Reject	Reject the transaction if the workflow task is currently assigned to you to approve or reject.
Terminate Process	Completely end the transaction so that no one can see or act on the workflow task again.
Withdraw	Remove the workflow task from the workflow. You can ask the submitter to submit again, for example, after an issue is resolved.

Related Topics

Actions and Statuses for Workflow Tasks

FAQs for Journals

How can I copy a journal entry?

Begin by opening an existing journal entry from the Manage Journals page. Select the Copy action in the Batch Actions drop down on the Journal Batch region to copy the entire journal batch. You can then delete any journals you don't need and modify the new journal batch, including the batch name, period, and accounting date, as needed. When you save, an unposted journal batch is created, that you then complete, approve, and post following your standard procedures. The copied journal has a source of AutoCopy instead of Manual.

What happens if I change the currency on a journal entry?

The journal entered and accounted amounts are recalculated to reflect the new currency amounts. The default conversion date is the journal accounting date. You can override the conversion date but the conversion date must be within the accounting period that you defined for the journal entry.

If the currency isn't the ledger currency, enter the currency conversion information at

The journal level for a single currency journal.
The journal line level for a cross currency journal.

Enter a conversion rate, if you enter User as the conversion rate type. When using a conversion rate type of Spot or Corporate, the daily conversion rate entered in the daily rates table automatically populates the conversion rate.

Note: Currency can only be changed on an unposted journal entry.

How can I add the Inverse Conversion Rate field to the Journal pages?

Use the Personalization functionality to add the Inverse Conversion Rate field to the Journal and Journal Lines regions of the Create and Edit Journal pages. The Inverse Conversion Rate field appears automatically on pages displaying a completed Conversion Rate field.

How can I prevent edits to journal entries created from journal import?

Select the value of Yes in the Freeze Journals field for the wanted source in the Manage Journal Sources page. This ensures that the subledger and general ledger balances reflect the same data. The value of Partial - Allow Import Correction Only prevents edits in the journal pages, but allows edits in the journal import correction spreadsheet.

What's the maximum number of journal lines that can be exported to an integrated Excel workbook?

When you are reviewing a journal, 500 journal lines can be exported. To review the details of a journal larger than 500 lines, run the General Ledger Journals Report for the journal batch.

What happens if an error occurs with the Journal Import service?

The Journal Import public web service provides specific validation errors and the account combination that has the error when invalid data is loaded.

What's the difference between incomplete and unposted batch statuses?

All batches that are not in a Posted status are considered unposted batches. These unposted batches have various statuses, including Incomplete, Selected for Posting, Processing, or Error.

A journal batch that is in an incomplete status has been saved, but is not completed. Incomplete journals are listed on the Incomplete tab of the Journals work area landing page and General Accounting dashboard.

What happens if I use suspense posting or other options to post an unbalanced journal entry?

If you enabled suspense posting when you define the ledger or after creating the ledger, Oracle Fusion General Ledger automatically creates additional journal lines. The process uses the suspense account you specify to balance your journal entries. You can optionally specify a threshold at which journal entries for monetary amounts are balanced.

General Ledger analyzes the journal entry and creates the additional balancing journal lines for the following situations in the order listed.

Suspense posting of unbalanced journals when suspense posting is enabled. If suspense posting happens, then the remaining balancing options don't occur.
Rounding differences at the journal level when journals are unbalanced because of rounding differences on currency conversion.
Intercompany or intracompany balancing for journals that aren't balanced by ledger or balancing segment value combination.
Entered currency balancing for journals that are unbalanced by the entered currencies. This option is only used on multicurrency journals.
Rounding differences by balancing segment when journals are unbalanced because of rounding differences on currency conversion and more than one balancing segment is effected.

Note: Statistical entries post without balancing debits and credits.

Why didn't my journal batch post?

Common reasons why a journal batch doesn't post are the following:

Account is disabled or not valid as of the accounting date.
Period isn't open for the ledger or for its secondary ledger or reporting currency.
Journal is imported into future-enterable period and the AutoPost program tries to post in an unopened period.
Journal is unbalanced and suspense balancing is turned off or not set up properly.
Journal is unbalanced by balancing segment value, and intercompany balancing is turned off or not set up properly.

The unposted journals with their error status are displayed on the Requiring Attention tab of the Journals work area and the General Accounting Dashboard. The error status also shows on the Posting Execution report. The Posting Execution report is created automatically when the Posting process completes. Use these sources to help in the error correction process.

Note: The Requiring Attention tab also shows journals with rejected approvals.

How can I correct errors that occur during the posting process?

Identify the error by using the Posting Execution report or by clicking the Show Errors button when querying the journal on the journal pages. The Posting Execution report lists the batches that are successfully posted and the batches that encounter posting errors. The Show Errors button appears when errors are detected during journal batch posting process. Clicking the Show Errors button displays a dialog box with an error message. Use the following methods to correct the error:

If it's an unopened accounting period for the ledger, the reporting currency, or the secondary ledger, the accounting period must be open.

If it's a disabled or invalid account combination, that combination must be enabled or made valid, or changed to a valid one.

If it's an unbalanced journal, the corresponding balancing method, suspense, rounding, entered currency, or intercompany, must be set up correctly and enabled with valid, related accounts.

Note: You are continually informed of posting validation errors on the Journal pages until the batch is corrected and posted.

How can I run the AutoPost process?

After you define an automatic posting criteria set, run the AutoPost process by clicking the Generate button on the Manage AutoPost Criteria Sets page or the Launch AutoPost link from the Journals task pane. The AutoPost process posts the journal batches that meet the criteria defined. Optionally, schedule the AutoPost process for specific automatic posting criteria sets through the Schedule tab in the Schedule Process: Advanced region to run at specific times and submission intervals.

How can I confirm that my journal entries were automatically posted?

Review the AutoPost Execution report. This report is created when the AutoPost process completes and contains the batch name, accounting period, and balance type for each batch posted, as well as error codes for those batches that failed to post. The posting status of journal batches is also listed on the Journals work area and the General Accounting Dashboard.

Why didn't the AutoPost process post journal batches as expected?

Verify that the posting criteria set specifies the precise criteria required to post the wanted journals. If the criteria is correct, then verify the following:

Journal imports completed successfully.
Journal batches are error free and ready to post.
Specified accounting period is open.

How can I identify errors that occurred during the AutoPost process?

Review the AutoPost process results on the AutoPost Execution report. This report is automatically created when the process completes successfully. The report contains the batch name, accounting period, and balance type for each posted journal batch, and lists error statuses for batches that fail to post. The unposted journals with their error status are also displayed on the Requiring Attention tab of the Journals work area and the General Accounting Dashboard.

Note: The Requiring Attention tab also shows journals with rejected approvals.

When does a journal become reversible?

You can reverse journals manually by selecting a reversal action in the user interface, or you can reverse journals automatically by running a process.

This table describes the criteria that must be met before you can reverse a journal, and indicates whether that criteria applies to manual or automatic journal reversal.

Criteria	Eligible for Manual Reversal?	Eligible for Automatic Reversal?
The journal has a balance type of Actual.	Yes	Yes
The journal has a balance type of Encumbrance.	Yes	No
The journal is posted and not yet reversed.	Yes	Yes
The reversal period is open or future enterable.	Yes	Yes
The journal isn't a reversal journal. Note: Reversal journals can't be reversed.	Yes	Yes
The journal category is enabled for automatic reversal.	N/A	Yes
The journal source for the posted journal isn't frozen.	Yes	Yes, however, this only applies to posted journals that originate from Oracle Fusion Subledger Accounting whose journal source isn't frozen. Posted journals that originate from a source other than Oracle Fusion Subledger Accounting are eligible for automatic reversal, regardless of the Freeze Journals setting.
The journal isn't a posted journal for a reporting currency that was replicated from its source ledger. Note: Reporting currency journals that were replicated from a source ledger are reversed when the source journal is reversed.	Yes	Yes
Where a secondary ledger is involved, the corresponding journals for the primary and secondary journals are both posted.	Yes	Yes
If using the Clearing Accounts Reconciliation feature, the posted journal doesn't include reconciliation lines for clearing accounts.	Yes	Yes

Tip: Use the Reversible Detail column in the Search Results section on the Manage Journal page for details on whether a journal is reversible.

Can I edit a journal that's approved and not yet posted?

Yes. Here's how you do it.

From the Journals work area:

Select the Manage Journals task.
Search for the journal and open it.
On the Edit Journal page, click Edit. A message will appear telling you that if you continue, the journal will return to an unapproved state. The approval status on the journal will change to Required.
Click Save.
Make your edits as needed.
Resubmit the journal for approval.