At the request of subscribers, Compliance Week offers a Remediation Center, in which readers can submit questions—anonymously—to securities and accounting experts. Compliance Week’s editors will review all questions and then submit them—confidentially, of course—to specialists who can address the issues. The questions and responses will then be reprinted in a future edition of Compliance Week. Below is one of the Q&As; ask your own questions by clicking here.
What is the best way to address a control weakness associated with the lack of a segregation of duties review for the Oracle’s PeopleSoft general ledger and accounts payable modules?
Segregation of duties (SoD), a critical element of the control environment, continues to present challenges for organizations across all industries. When executed properly, SoD imposes controls so that the duties and responsibilities assigned to a particular employee do not create a situation where erroneous or fraudulent activities can take place. Still, implementing these controls isn’t enough. To truly mitigate an organization’s exposure to risk, there must be frequent reviews of the SoD controls.
The general ledger and accounts payable functions of an organization are highly susceptible to errors and malfeasance, so SoD across these areas is crucial. Fortunately, modern financial transaction processing systems, like the Oracle’s PeopleSoft modules that you mention, provide several ways to implement, manage, and maintain proper SoD controls using the access and authorization functions of these systems. There are also a variety of third-party add-on software programs that can further enhance the transaction system’s ability to monitor and maintain compliance with SoD controls.
Before employing technology to remediate control weaknesses, it is important to first put the right processes in place around access entitlement and accurately define user roles and responsibilities. This requires an understanding of the root causes of SoD issues.
To identify potential issues, it’s important to:
Identify individuals or roles with incompatible functions. This most basic element of SoD control requires a deep understanding of each business process and the tasks that are incompatible from a controls standpoint. (For example, an employee who can issue purchase orders and also authorize payment of invoices).
Review access entitlement and administration functions for user roles. This concerns the ability to modify and customize employee roles without proper oversight, to prevent these roles from becoming incompatible (such as the ability to modify the AP processor role in Oracle’s PeopleSoft to add the ability to issue purchase orders). Additionally, SoD considerations must be incorporated into the user provisioning process to ensure that proper access is maintained on an ongoing basis with an audit trail for changes that are periodically reviewed.
Perform administrative cleansing. This includes reviewing the assignment of employee roles and transaction capabilities to identify people who do not require these capabilities in the course of their normal daily job responsibilities (typically, people who may have transferred out of a specific role).
To facilitate a simpler review of SoD issues, you should construct user roles in a way that supports ongoing maintenance. Organizations often unnecessarily complicate the process by defining many more roles than needed; much more efficient is to create a set of standard roles for management activities, transaction-processing activities, and analysis activities.
For example, the “management role” might have the ability to enter journal entries in the General Ledger (a common activity for the Accounts Payable Manager), but only view ability within the AP module itself, preventing an individual with this role from actually entering an invoice. The “transaction processor” role might have the ability to enter invoices into the AP system but only view journal entries in the GL system. The “analyst role” would have viewing ability across the board, but would not be able to process actual transactions. Defining roles in this way makes it easier to implement frequent reviews and to generate reports that illustrate users, associated roles, and potential violations.
This approach must be accompanied by strict access control and an audit trail (for example, a formal user set-up process) for adding users and assigning roles; this function is best performed by someone outside the finance and accounting functions. The challenge with a review process as described here is that it relies on an understanding of the business processes and the application setup, very much a manual control. Here’s where additional technology can help.
In the case of Oracle’s PeopleSoft, software add-ons with varying degrees of SoD capabilities include Oracle’s GRC Access Controls and third-party packages such as Approva BizRights. These tools all have the ability to add automation to the ongoing SoD review process, including the ability to audit existing relationships and user provisioning to avoid future conflicts. Each of these technologies provides the ability to establish parameters around desired SoD relationships and then monitor these parameters on an ongoing basis.
While technology helps to significantly improve the SoD process, to be effective, it should be coupled with an understanding of the root cause issues of SoD and the fundamental parameters of how to establish and maintain SoD controls.