© 2008 ERPS

Internal Control Best Practices for Implementing Oracle’s Journal

Approval Process

Overview The journal approval process in Oracle is often relied upon as a key application control

over the financial reporting process as it relates to controls defined to meet Sarbanes-

Oxley (SOX) requirements. Oracle’s journal approval process allows for a workflow

based approval process with pre-defined authorization limits. However, if certain setups

related to the journal source are not properly maintained and secured, the journal

approval process may be disqualified as an application control. Therefore, the testing of

the journal approval process would require significantly greater testing or, worse case,

may cause a significant deficiency or material weakness in a company’s SOX section 404

audit.

Control Objective The objectives of this control are three-fold. The first objective is to discuss the key

implementation setups and the related internal controls implications. The second

objective is to secure the definition of what journals should be routed through the journal

approval process and other key setups. The third objective is to make sure that all

manual journals (through the Journals form, via the client-server version of ADI, or via

web ADI) go through the approval process, as is a typical requirement for companies

implementing journal approval.

Scope The scope of this document is to discuss the key setups related to the journal approval

process from an internal controls perspective. It is not the intention of this document to

discuss all the steps and decisions related to the journal approval process, just those that

have internal controls implications. These concepts should be applicable to all versions

of the application that use Oracle’s Journal Approval process.

Key Implementation Steps There are a few key setups when implementing the journal approval process.

Authorization limits The authorization limit defines the amount of the journal that can be approved. The

Journal Approval process determines the appropriate approver by comparing each

potential approver’s authorization limit to the largest net journal line amount in the entire

batch.

© 2008 ERPS

Approval hierarchy The approval hierarchy is based on the HR setups (employee/supervisor relationships

must be established) and is outside the scope of this document. However, typically the

HR setups follow the reporting hierarchy within the company.

Profile options Three key profile options are as follows:

• Journals: Allow Preparer Approval – this determines whether or not the preparer

of the journal enter can also approve the journal if the journal is within their

authorization limit. Typically, companies don’t allow preparers to approve their

own journals since it may allow an employee to enter and approve a material

journal entry. In most cases, companies desire that even journals entered by

senior management (with a high authorization limit) are reviewed by another

member of senior management so that there is a sanity check on the journal entry

• Journals: Find Approver Method – this determines how the approval is routed and

can be configured various ways to meet company’s requirements, depending on

how the company wants to define the control. Values that can be set for this

profile option are as follows: Go Up Management Chain, Go Direct, and One

Stop Then Go Direct. The default is Go Up Management Chain. All options use

the supervisor hierarchy defined in the HR module. Any of the options would be

acceptable from an internal control perspective as long as management documents

and enforces the decision.

• GLDI: Journal Source – this is the key setup relating to the client-server version

of ADI and will be discussed in more detail below

Journal Sources When setting up Journal Approval, you determine which sources are subject to the

approval process via the Journal Sources form. You can determine that some sources go

through the Journal Approval process and some are not required. When Oracle GL is

installed, none of the sources are set up to go through the Journal Approval process.

Here is the Journal Sources form where the sources are enabled:

© 2008 ERPS

The Sources for which you want to require journals to go through the Journal Approval

process need to be enabled by checking the Require Journal Approval column.

Typically, you don’t require Sources such as Receivables and Payables to go through the

Journal Approval process because the activities in those subledgers have controls within

them. Any meaningful review of these subledger journal entries would lead you back to

the details in those modules. However, most companies have defined as one of their key

controls as a secondary/managerial review of any manual journal entries. Therefore, all

manual journal entries would need to go through the journal approval process. The

security to force all manual journal entries to go through the journal approval process

differs by the method by which the journal is entered. There are three primary methods

that will be discussed in this document: through the forms, through the client-server

version of ADI, and through WebADI (Desktop Integrator responsibility).

In the process of setting up the Journal Approval process it is imperative that an end user

NOT be allowed to select a Journal Source that could be overridden. You secure this as

follows:

Via the Journals form

Manual journals entered through the Journals form are defaulted to the Source of Manual.

Therefore, it is critical that this source be set to use the Journal Approval process. If

desired, the Category can also be defaulted by using the profile option “Journal: Default

Category.” However, I see no internal controls implications to this setting.

Client/server version

Using the client/server version, it is accomplished by setting the profile option “GLDI:

Journal Source.” The source you enter in this profile option is the source required for all

ADI journal entries and the source that is defaulted in the Excel template.

© 2008 ERPS

Web ADI version

In the WebADI (aka Desktop Integrator) version, it is necessary to 'secure' the Journal

Source as follows:

1. Define a custom layout or update the standard layout - in this template the Journal

Source field should have a Placement of "Context". By placing the journal source

field in the context section, it prohibits the end user from overriding the control by

changing the journal source to a source that doesn’t require the journal approval

process. The Default Type should be "Constant" and the Default Value should be a

Source that requires Journal Approval, presumably “Manual” since that is likely to be

enabled for journal approval.

2. This layout should be the only functional layout capable of being used. Any layout

that allows users to change the Journal Source should not be made available.

3. The definition of new layouts should be removed from any GL user so they can't

introduce a new layout or make changes to the layout that would allow them or

another user to be able to change the default journal source or otherwise enter a

journal entry with a Journal Source that doesn't require it to go through the Journal

Approval process. Therefore, the function “Desktop Integrator - Define Layout”

which is part of the standard Desktop Integration Menu should not be accessible for

any user involved in the journal approval process. Further, since this is an integral

part of the setup for this key control, any changes to the layout should go through

your company’s change management process and the impact on this key control

needs to be considered.

Typical Journal Source setups:

Here is the list of the most common seeded journal sources and a discussion of each as it

relates to the internal controls implications:

Source Journal

Approval

Required?

Justification

Assets N Controls over accounting should be in the

subledger. Key setups in FA that relate to the

accounting for transactions should be

controlled and changes approved.

Budgets ? Whether or not you should require budget

journals to be approved depends on whether

you have defined controls over budgets as a

key or non-key control. If it is, this should be

enabled.

Consolidation N I believe the only time an entry with a

consolidation journal source is created is when

subledger GL’s are uploaded to a consolidation

layer. Therefore, all such journal entries are

system generated and need not go through the

journal approval process.

© 2008 ERPS

Source Journal

Approval

Required?

Justification

Elimination Y Depending on the controls put in place

regarding the definition of elimination sets,

these journals should probably be reviewed

before being posted

Encumbrance Y Any encumbrances entered via JE should be

reviewed

Intercompany ? Any journal entries with this source come from

the Global Intercompany System. Controls

surrounding such journals need to be evaluated

in regards to overall controls of JE’s.

Inventory N Controls over accounting should be in the

subledger.

Manual Y Relates to journals entered in the Journals form

MassAllocation ? Depending on where the control point is –

could be either in the definition of the Mass

Allocations or once the journal is generated –

see further comments below

Payables N Controls over accounting should be in the

subledger.

Payroll N Controls over accounting should be in the

subledger.

Projects N Controls over accounting should be in the

subledger.

Purchasing N Controls over accounting should be in the

subledger.

Receivables N Controls over accounting should be in the

subledger.

Recurring ? Depending on where the control point is –

could be either in the definition of the

Recurring Journals or once the journal is

generated – see further comments below

Revaluation Y Depending on where the control point is –

could be either in the definition of the

Revaluation process or once the journal is

generated – because the unrealized gain/loss

accounts need to be defined when running the

revaluation process, it would be ‘safer’ to have

the journal reviewed.

Spreadsheet Y Relates to journals entered via the client-server

version of ADI as is typically set in the profile

option “GLDI: Journal Source”

© 2008 ERPS

Special note regarding Mass Allocation and Recurring:

If you were considering place the control point at the definition of Mass Allocation or

Recurring journals (Journals -> Define -> Allocation or Journals -> Define -> Recurring)

then it would be necessary to audit these tables and have a process to review and approve

changes to these. Further, from a change management process, it would also be

necessary to validate (for completeness and authorization) that all changes were

approved. The easier path would be to have these journals reviewed once they are

generated.

© 2008 ERPS

AutoPost In the AutoPost form an end user could define certain sources to be automatically posted.

Here is the form by which the criteria are defined.

If you are using the journal approval process, journals can only be posted once they are

approved. The posting process has no control impact since the control point is the

approval process (or exclusion of the approval process in the case of some journal

sources like subledgers). Therefore, using this form would have no impact on the

definition of the control. However, if your company hasn’t implemented the journal

approval process and is relying on those that post the journals to perform the review,

access to this form should only be granted to those with posting authority. The function

name is GLXSTAPO.

© 2008 ERPS

AutoReverse This form allows you to define which categories (not sources) should be automatically

reversed and could also be automatically posted. Here is the form by which the criteria

are defined:

Since this form allows a user to define which categories should be automatically reversed

and which can be automatically posted, the definition of such could override the review

approval process and the access to it should, therefore, be controlled. The function name

is GLXSTARV.

Change Management Impact Since the journal approval process is often a key control and is usually defined as an

application / system control, it will be necessary to prove to your auditors on an on-going

basis that any changes to this process are authorized. To do so, it is necessary that all

related setups have a complete audit trail. This will require that tables underlying the key

setups noted about to be audited. These include, but are not limited to:

GL_JE_SOURCES_TL (journal sources), GL_AUTOMATIC_POSTING_OPTIONS

(AutoPost), GL_AUTHORIZATION_LIMITS (Authorization Limits),

GL_AUTOREVERSE_OPTIONS (AutoReverse), and

FND_PROFILE_OPTION_VALUES (profile option values). These tables should be

reviewed for their accuracy as well as their performance impact in your environment.

See recommended list of tables to audit by signing up for the Oracle Internal Controls

Repository at: http://groups.yahoo.com/group/oracleappsinternalcontrols/. The files are

TTA_GL and TTA_AOL.

Conclusion Oracle provides the functionality of the workflow based Journal Approval process, a

powerful tool to help companies automate a key control for their SOX 404 compliance.

However, if not properly configured and maintained, many companies could find

© 2008 ERPS

themselves in a difficult position with their auditors. By following the above advice,

hopefully, the pitfalls mentioned can be avoided.

Open Issues One reviewer indicated that the Stat currency journal entries can be approve their own

journal entries even when the profile option “Journals: Allow Preparer Approval” is set to

“No”. This has not been confirmed. However, if true, could have some internal control

implications where stat entries are being used in MassAllocations. A report for

management to review the stat entries each month will documented approvals would be a

detective control you may want to consider.

About the Author Jeffrey T. Hare, CPA CISA CIA is one of the world’s leading experts on the development

of internal controls in an Oracle Applications environment. Jeff founded ERP Seminars

and the Oracle Users Best Practices Board and is leading the efforts for the development

of a public domain internal controls repository. See a full bio for Jeff at

http://www.erpseminars.com/providers.html.

Version Control

Version Updated by Date Comments

1.0 Jeff Hare 23-Aug-06 Initial release to for public review

1.1 Jeff Hare 25-Sep-06 Update for reviewer comments

1.2 Jeff Hare 12-Dec-07 Corrected journal sources table by dropping

_TL which is the translation table.