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.