The One Function That Could Undermine Your Journal Entry Controls

Background:

In R12, Oracle dramatically changed their subledger architecture by introducing SLA – Sub-Ledger Accounting Architecture. This change helps to standardize the way accounting is stored and transferred to the General Ledger and also allow multiple accounting methods for subledger activity. In the SLA architecture and design of function security, Oracle introduced some significant flaws.

The critical function in question has a User Function Name of: SLA: Create Subledger Journal Entry. The Function Name is: XLA_MJE_CREATE.

Let me demonstrate how to enter a manual journal entry at the subledger level. First, notice that I am accessing this function through an Inquiry menu. Yes… Oracle designed the seeded security to be able to create a manual Journal Entry line via an Inquiry menu…

Note: The top ten list (on the right half of the screen shots) shows the “User Function Name”. The user function name mentioned in the paragraph above is not the same as shown in the illustration. The fact that you can create the journal entry is the result of the function existing anywhere, possibly with no prompt in the responsibility menu. It causes this form to display the Create Journal Entry button as shown below.

Choose Journal Entries and you will receive this screen:

Press the Create Journal Entry button and you will receive this screen:

You can create a Journal Entry here as follows:

Press Continue and you will receive this screen:

Press the Finish button and you will receive this message:

How could this undermine your entire Journal Entry controls…?

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 approved 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.

In the scenario above, a manual JE could be entered via the SLA module which essentially amends JEs being transferred from the subledger. If a user enters a line or modifies a line in the SLA module, that activity SHOULD be subject to the manual JE review once it hits the GL. However, an accountant reviewing the subledger JEs once it hits the GL would have no idea that the JE was modified through the SLA module.

Therefore, putting my auditor hat on… if I see one or more users that have the ability to enter a JE through the SLA module, I have to ask the question – have they done so. If there is a possibility of this, then my expectation as an auditor is that the JE, when transferred to the GL, would be reviewed by someone. The question is HOW could they possibly review the JE when the manual lines were ‘buried’ in the JE somewhere – i.e. the manual modification isn’t identifiable. The logical conclusion by an auditor would be to require substantive testing of the subledger JEs which would dramatically increase the amount of testing that would need to be done related to such JEs.

Would using the Journal Approval workflow make a difference?

The simple answer is no. However, let’s take a look at the Journal Sources form to identify the different configuration options that could be used.

Journal Sources Configuration

Normally, only the Sources that are subject to the JE approval workflow that are ‘manual’ such as the MANUAL Source and the SPREADSHEET Source (not shown above). The subledger sources such as Receivables, Payables, and Assets are typically NOT subject to the journal approval workflow. Even if they were set to “Require Journal Approval” the question an auditor should ask is how they’d get comfortable approving such JEs since there are hundreds, thousands, or more transactions that make up each of the JEs.

Auditors looking to identify which Responsibilities and Users have this ability can run the query in Appendix A.

Just as an FYI, see Appendix B for screen shots of various seeded Responsibilities which have this Function built into the seeded Menu. Therefore, if the Menu or one of the Sub-menus that contains this Function is used in the development of a custom Responsibility the Function would be accessible unless a Function Exclusion was entered at the Responsibility definition screen.

Appendix A: Query to identify which Users and Responsibilities have access to enter a manual JE through the SLA module

Query 12: High Risk Single Functions SQL Query

Purpose: This query identifies the users and responsibilities that can access high risk single functions. The limitation of this query is that it does not take into account menu or function exclusions that may be applied at the Responsibility level. This information has to be reviewed along with the information in Query 1 which provides the definition of Responsibilities and Menu and Function exclusions applied.

select distinct fu.user_name user_name,fu.description user_description, fr.responsibility_name

resp_name,fff.function_name,fff.user_function_name, fff.description, ff.form_name, ff.user_form_name

from applsys.fnd_user fu,

apps.fnd_user_resp_groups furg,

apps.fnd_responsibility_vl fr,

applsys.fnd_compiled_menu_functions fcmf,

apps.fnd_form_functions_vl fff,

apps.fnd_form_vl ff

where fff.form_id=ff.form_id

and furg.responsibility_id = fr.responsibility_id

and furg.responsibility_application_id = fr.application_id

and fr.menu_id = fcmf.menu_id

and fcmf.grant_flag = ‘Y’

and fcmf.function_id = fff.function_id

and furg.user_id = fu.user_id

and sysdate between fu.start_date and nvl(fu.end_date, sysdate+1)

and sysdate between fr.start_date and nvl(fr.end_date, sysdate+1)

and fff.function_name in (

select fun.function_name

from apps.fnd_form_functions_vl fun, apps.fnd_form_vl form

where fff.function_name in (

‘XLA_MJE_CREATE’

)

and fun.form_id=form.form_id

)

order by 1,2

Appendix B – Examples of seeded menus / responsibilities with this flaw

Note inconsistency within Oracle in how these are handled

Project Costing Super User

with Function Exclusion

Payables Manager

w/o function exclusion, but with the function

Receivables Manager:

w/o function exclusion, but with the function

Cash Management: