The intent of this document is provide the reader with a fundamental understanding of Oracle’s Journal Entry Approval Workflow enriched with lessons learned from actual implementations. Matt Makowsky is an Oracle Financial Applications Consultant with 17 years experience and a Senior Solutions Architect with Perficient. Feel free to ask him any questions in the comments section below the blog.
Oracle’s Journal Entry Approval Workflow enables what in many companies may be a key SOX control:
- prevent unauthorized journals from posting into your ledger
- prevent unsubstantiated changes to financial statements
The control does this by ensuring journal entries are reviewed by supervisors to verify the journal is complete, accurate, and has supporting documentation.
Journal Approval works as follows in EBS:
- A journal is created in EBS (or uploaded via WebADI)
- The user clicks the “Approve” button on the journal form (note, if submitted via WebADI, the user must query the journal up in the core forms to submit for approval)
- The approver, typically the user’s supervisor as defined in Oracle HR, receives a notification with the ability to review the journal, and then approve, reject, or ask for more information.
- The workflow will move to the next supervisor if the value of the largest journal line is greater than the supervisors approval threshold.
Those are the basics, but under the hood there are a lot of mechanisms in motion to make it all work.
Enabling Journal Approval: The basics
Journal Approvals can be enabled easily with the following basic setups:
- For a given ledger (primary or secondary), navigate to the setups and “Enable Journal Approval”
- Review your Journal Sources, and enable Journal Approval for a given source – turn it off where journal approval is not required (ie: subledger journals from Receivables, Assets, Payables, and so on)
- Add Approvers and “signing limits” into the system by ledger.
- Set profile options to enable/disable “preparer can approve own journal” – if enabled, the preparer can approve their own journal, providing they have the signing limit for the journal.
Best practice is to disable this capability, to prevent people from splitting journals for the purpose of self approval.
Points to remember:
- Journal approval is conducted at the journal batch level. The highest journal line value across all journals within the batch will determine the supervisor.
- Journal approval looks at amounts, not accounts. To look at accounts, customization will be required.
- Journals will always go up the supervisor hierarchy, although there are options to “go direct” or to move up through the hierarchy. If going direct, the journal will skip anyone who would not have signing authority, as determined in the signing limits definition.
- Be sure managers have remote access to email and email is enabled for month end approvals.
- Appoint a workflow administrator to reassign workflows in the event an approver is absent and has not set their vacation rules.
- AME is not available for Journal Entry Approval as of 12.1.3. Customization must be done through workflow.
Pros and Cons of Implementing Journal Workflow
Pros
- Enables and simplifies a key sox control.
- Electronic signatures, governed by the system, are more easily audited.
- Prevents forgery of approved documents and loss of offline data.
Cons
- Month End process can be slowed if approvers are on vacation or out sick.
- Limited functionality in standard approval rules.
Implementation Recommendations and Considerations
- The size of your accounting department, the number of managers, the number of approvals needed
- Avoid situations where multiple approvals are needed, especially at month end, enabling “unlimited” authority for most managers.
- Consider other controls to prevent over burdensome approvals
- Mass Allocations and Recurring Journals- disable approvals for mass allocations, provided that the forumlas are “locked down” to select users (supervisors and managers)
- Sub Ledgers – disable approvals. The source of the activity has already been approved, or was otherwise generated with other system controls in place.
- Freeze all subledger journals to prevent changes and out of balance control accounts.
- Disable approval for automatic reversing journals (controlled by profile option)
- Create workflow reports
- Monitor the status of unapproved journals
- Audit Preparer vs. Approver to check on “system gaming” if preparers are allowed to approve own journals. See who is approving their own journals on a regular basis.
- Enable Auto Post and Schedule it Frequently (often at Month End)
- Auto Post simplifies the record to report process, by posting journals automatically (as the name suggests) if the journal has an approved status or does not require approval.
- Auto Post reduces redundancy in process. Consider that once approved, a journal is expected to be posted. Let the system manage the process from Approval to Post.
- Customization
- Avoid unnecessary customization, balancing business requirements against the technical complexities.
- Be flexible and look for functional solutions, using reports or other controls before customizing the workflow.
In summary, Journal Approval Workflow can provide huge benefits to your enterprise: Control over and Insight into your process. Prevent simple accounting errors, and streamline your month end process. Combined with Auto Post, implementing approvals can fundamentally change the way your finance team does business.
Hi, Matt. Thank you for your thoughtful article. Unfortunately, I have not been able to find very much information on how to audit change management on the R12.1.1 Journal Workflow configuration itself. Ideally, we would like to run a report which shows when the Journal Batch approval workflow or the associated approver group was changed. Do you have any ideas on how this can be accomplished?
Thanks for reading the blog and your question. If Oracle GRC doesn’t do the job, I’m pretty sure there’s no standard report or mechansim to track those specific changes.
If I had to respond to my client with a solution, I’d possibly recommend a trigger on the relevant tables to record the changes in the approvers and run a daily report off that table.
Same type of thing you might do for suppliers bank accounts and other sensitive data.
Matt
We have a business need where journals from 50 individuals should not follow HR – Hierarchy instead flow to admin staff at corporate office. Do you have any suggestions on Implementing above solution . Can you point us to links which have steps on GLBATCH customization’s.
Thanks
Tim
Hello Matt,
Thanks for posting this. Had two question however,
1. what if I have to post a JE and i want to select a different approver other than my Manager.
2. Can the tool act as a communication tool. for example there are some entries my team prepares here and some entries my team receives raw reports from phoenix. My team then prepares these entries based on the input. Is there a way in the tool for phoenix to send the raw reports so that my team can track it in the oracle workflow??
Thanks
Hi Matt thanks for your article what do you do when the original journal didn’t require approval but later management changes the policy for the journals to be approved and then arise a need to reverse the previous journal which didn’t have an approver and reversed journal must be approved.