A Back Door Way to Changing Supplier Addresses in Oracle E-Business Suite
Background:
Most organizations have a control defined over the entry of
and changes to Supplier Master data including the Supplier’s address. Allowing a user as part of the payment process
to change the address for a check would essentially allow them to circumvent
the expected controls that normally happen through the supplier master
maintenance process.
Risk Presented and Analysis:
The Allow Address Change option in the Payables Options form
enable a user to make a change to the Supplier’s address to re-direct where a
check it sent. This would allow a
fraudster to make a change and give them physical possession of a check that is
not meant for them. There are various
ways that fraudster could get that check cashed.
Therefore, this option should never be allowed to be set for
any Operating Unit. All changes to a
Supplier’s mailing address should follow your organization’s normal change
process rather than allowing a clerk to make this one-off adjustment when
entering a check.
If this is currently allowed, it needs to be disabled
(unchecked). The process should be to
require an additional address be set up or a change to the default address
through the Supplier Master process.
Following is a screen shot of the Payables Options
configuration form:
Note that this configuration is org (OU / org_id) specific. If you have more than one Operating Unit,
this configuration will need to be evaluated / changed for each Operating Unit
independently.
Following is a description of this process from the Oracle
Payables Users Guide:
Recording a manual payment
1. In the
Payments window select the Manual Type.
2. Enter a
Trading Partner. The Supplier Number is automatically displayed. If there are
multiple Supplier Sites, select the appropriate site from the list.
3. Enter the
Payment document Date. The date must be in an open period. If the Allow
Pre-Date Payables option is enabled, then you can only predate a computer-generated
payment.
4. Enter the
Bank Account from which you want to make the payment.
5. Select a
Payment Method.
6. Select the
type of Payment Document if Printed is selected as the Payment Process Profile.
7. Select a
Payment Process Profile.
8. If you have
enabled the Allow Remit-to Account Override Payables option, then you can
select a different, active Remit-to account. The list of values includes bank accounts
assigned to the supplier that have the same payment currency.
Important:
The system ensures that Quick
payments cannot be created for payment to inactive bank accounts.
9. Enter a
Maturity Date if the Bills Payable payment method is selected.
10. Select a
Rate Type.
11. If
necessary, enter or adjust other information:
•
If you created the payment
for an address different from the supplier site and your Allow Address Change
Payables Option page, Payments tab is enabled, adjust the address. For example,
you may need to send an expense check to a
consultant working at a site away from home.
Following
is an excerpt from the process related to recording a manual payment (which is
often used to generate a ‘one off’ check.
Recommendations:
Following are our recommendations related to this risk and
configuration:
1.
“Allow Address Change” should NOT be checked
(enabled) for any Operating Unit
2.
Any changes to Payables Options configurations
should be approved by someone responsible for fraud prevention. In other words, the Payables Process Owner
should NOT be able to approve a change to this configuration.
3.
If you have a tool to monitor access control risks,
you should have rules as follows:
a.
Single function rule related to Payables Options
– verify that the only users with access to this function are those that can
make changes in Prod once approved as part of your organization’s change
management process – typically this means IT users / business analysts.
b.
SoD rules – Enter AP Payments vs Payables
Options – no one user should have access to the ability to generate AP Payments
(particularly the function that allows single payments to be created) as well
as the ability to maintain Payables Options.
The SoD rule would be “Enter AP Payments vs Payables Options” – our rule
ID PP048.
Note: For recommendation 3 above, we offer a service to
evaluate access control risks that includes Segregation of Duties conflicts,
single function risks (Restricted Access), and access to sensitive data. Our
rule set is the most comprehensive in the industry. Find out more about our rule set at: erpra.net/Content.html. Our content includes Rule ID PP109 as a
single function rule to identify who has access to maintain Payables
Options. Our content also includes Rule
ID PP048 “Enter AP Payments vs Payables Options” since no one user should have
access to the ability to generate AP Payments (particularly the function that
allows single payments to be created) as well as the ability to maintain
Payables Options.
Contact us at erpra.net/contactus.html for more information about CaoSys GRC
solutions if you are interested in learning more. We offer our Role / Responsibility analysis
solutions as a service (CS*Proviso) or via installed software
(CS*Proviso). See more about CaoSys GRC
solutions at caosys.com.
Download a pdf of this article here.
Download a pdf of this article here.
Recommended Services from ERP Risk Advisors
We offer an evaluation of Application Controls design effectiveness along with an analysis of the configurations. This service can be performed typically in one to three weeks.
Since some of these risks need to be evaluated by reviewing
access controls, a SaaS service to review role design may also be
appropriate. We perform that service
through our partner, CaoSys.
Contact us at erpra.net/contactus.html for more information about these services or
CaoSys GRC solutions if you are interested in learning more. We offer our Role / Responsibility analysis
consutling as a service (CS*Proviso) or via installed software
(CS*Comply). See more about CaoSys GRC
solutions at caosys.com.
This query below can be run to identify how this
configuration is set:
Select *
From AP_SYSTEM_PARAMETERS_ALL
The column related to the “Allow Address Change” configuration is UPDATE_PAY_SITE_FLAG. A value of ‘Y’ means the capabilities are
allowed – i.e. they CAN change the Supplier Address when a manual payment is
processed, effectively bypassing any controls over the Supplier master.
About ERP Risk Advisors
ERP Risk Advisors is a leading provider of Risk Advisory
services for organizations using Oracle Applications. We provide consulting and training services
related to compliance, security, risk management, and controls. We also assist organizations in implementing
GRC-related software from industry-leading companies such as Oracle, CaoSys,
Smart ERP Solutions, and MentiSoftware.
About Jeffrey T. Hare, CPA CISA CIA
Jeffrey Hare, CPA CIA CISA is the founder and CEO of ERP
Risk Advisors. His extensive background
includes public accounting (including Big 4 experience), industry, and Oracle
Applications consulting experience.
Jeffrey has been working in the Oracle Applications space since 1998
with implementation, upgrade, and support experience. Jeffrey is a Certified Public Accountant
(CPA), a Certified Information Systems Auditor (CISA), and a Certified Internal
Auditor (CIA). Jeffrey has worked in
various countries including Austria, Australia, Brazil, Canada, Germany,
Ireland, Mexico, Panama, Saudi Arabia, United Arab Emirates, and United
Kingdom. Jeffrey is a graduate of
Arizona State University and lives in northern Colorado with his wife and three
daughters. You can reach him at
jhare@erpra.net or (970) 324-1450.
Jeffrey's first solo book project "Oracle E-Business
Suite Controls: Application Security Best Practices" was released in
2009. His second book project “Auditing
Oracle E-Business Suite: Common Issues” was released in 2015. Jeffrey has written various white papers and
other articles, some of which have been published by organizations such as
ISACA, the ACFE, and the OAUG. Request
these white papers here. Jeffrey is a
contributing author for the book “Best Practices in Financial Risk Management”
published in 2009.
LinkedIn: linkedin.com/in/jeffreythare
Twitter: twitter.com/jeffreythare
Blog: jeffreythare.blogspot.com
No comments:
Post a Comment