The One Profile Option That Could Undermine Your Journal Entry Controls

Background:

Most organizations use ADI (client server version in 11i and prior and web version in R12 and later) to develop and upload Journal Entries (JEs). The JEs are subject to ‘manual’ journal entry controls. Typically, there are three types of controls that govern the review and approval of controls.

1. Segregate Enter Journals vs Post Journals – one person enters the journal and a supervisory person reviews then posts the journal.
2. Journal Approval Workflow – the organization has implemented the journal approval workflow process to automate the review and approval of all manual JEs.
3. All controls outside system – there are various ways this is done with the goal being all manual JEs are reviewed by someone prior to the release of financial statements.

For more background on how JEs are controlled, we need to understand the Journal Sources configuration. In Oracle there are various seeded (i.e. provided upon installation of the applications) Sources of JEs. Organizations implementing the application can also define more custom sources as part of their implementation. A custom source may be defined where a JE is being sent from another system.

Let’s take a look at the Journal Sources form where these are configured:

There are various attributes that can be set for each Source. The only critical attribute we are going to look at in this section is the “Freeze Journals” configuration. When the “Freeze Journals” configuration is set to “Yes” the JE is frozen once it is imported into the General Ledger. Therefore, because it is frozen, it cannot be changed.

Typically, organizations have journal entry controls that require a manual journal entry to be approved, but the journal entries transferred from the various subledgers aren’t reviewed. Journal entries that are transferred from subledgers are typically not reviewed in the same way as manual journal entries because there are hundreds, thousands, or more transactions that make up the subledger activity.

There is no way a user could properly review and approve a JE coming from the sales ledger (Receivables module) or the payables ledger (Payables module). Therefore, these JEs are typically ‘accepted as is’ when they are transferred from the various subledgers. The assumption is that there are proper controls within each of the subledgers that are used to review and approve the underlying transactions.

How could the improper setting of one Profile Option undermine your entire Journal Entry controls…?

The risk is journal entries that are uploaded via ADI could be uploaded with a source that is not typically reviewed. For example, a manual JE could be created in an Excel template using a source of Payables. Since the Payables source is not something that is part of the review of manual controls, if a JE were created and uploaded with a Source of Payables, it would bypass the manual JE controls.

If any auditor identified one or more ‘manual’ JEs that had a source that was not subject the review (such as these examples: Assets, Cash Management, Cost Management, Payables, Receivables, Inventory, Marketing, Payroll), then they may call into question what other JEs did not go through the manual JE process, including those that were actually uploaded from a subledger.

To compensate for this risk, Oracle designed the upload process to validate that the Source was a particular source – i.e. one that is defined via the profile option GLDI: Journal Source. If the GLDI: Journal Source profile option is set to “Spreadsheet” (for example and which is also our recommendation), then a JE uploaded into the GL must have a source of “Spreadsheet” or it will fail them import process.

The flip side of the coin in this… if the profile option “GLDI: Journal Source” is NOT set any source could be used when uploading a JE, including one such as Payables that would likely be ignored based on the assumption is was transferred from the Payables module.

Putting my auditor hat on…

The first thing I’d do is run a query to identify if the profile option “GLDI: Journal Source” is set, at what levels, and when it was set.

If it is not set, then I cannot have confidence that a JE wasn’t created using a Source that wasn’t subject to review and approval for manual JEs, such as Payables, Assets, etc. If it is set, then was it set for the full audit period or was it set or changed during the audit period.

By default, Oracle does not have the detailed history built to provide you with a full detail of changes to profile options (Inserts, Updates, or Deletes). All that is provided is information about whether it was added or changed via ‘row who’ fields (CREATION_DATE, CREATED_BY, LAST_UDPATE_DATE, LAST_UPDATED_BY). Absent this complete, detailed audit trail, you cannot get comfort as to whether the Profile Option GLDI: Journal Source was created or updated during the audit period. If the value was created after the start of the audit period or was changed after it was created, then you cannot be certain it was set appropriately for the entire audit period.

If it was set and not updated during the entire period, then review the value to make sure it is set to a value that WOULD be subject to manual JE review and approval, such as Spreadsheet or Manual.

If the query results showed it set to a value that is NOT subject to the manual JE review and approval (such as Payables or Assets), then all JEs using that source cannot be relied on. Therefore, as an auditor I would need to perform additional procedures to gain assurance related to those JEs.

Appendix A – Query to Pull the Profile Option Configurations

Query for all profile options set –use to review if and how GLDI: Journal Source is set

SELECT  ot.user_profile_option_name

TO_CHAR(v.level_id) level_id

• DECODE(v.level_id ,10001,’Site’
• 10002,’Application’
• 10003,’Responsibility’
• 10004,’User ID’
• level_id)

level_meaning

• DECODE(v.level_id ,10001,’Site’
• 10002,apl.application_name
• 10003,frt.responsibility_name
• 10004,u.user_name
• level_id)

level_name

• profile_option_value
• profile_option_name
• creation_date value_creation_date
• created_by value_created_by
• last_update_date value_last_updated_date
• last_updated_by value_last_updated_by

FROM         applsys.fnd_profile_options_tl ot

• fnd_profile_options o
• fnd_profile_option_values v
• fnd_responsibility_tl frt
• fnd_application_vl apl
• fnd_user u

WHERE v.level_value = frt.responsibility_id (+)
AND v.profile_option_id = o.profile_option_id
AND o.profile_option_name = ot.profile_option_name
AND ot.language = ‘US’
AND NVL(frt.language,’US’) = ‘US’
AND v.level_value = apl.application_id (+)
AND u.user_id (+) = v.level_value
ORDER BY ot.user_profile_option_name
, v.level_id

, DECODE(v.level_id ,10001,’Site’

• 10002,’Application’
• 10003,frt.responsibility_name
• 10004,u.user_name
• level_id);