Journal of Digital Forensics, Security and Law, Vol. 4(1) .docx

Journal of Digital Forensics, Security and Law, Vol. 4(1)
39
Continuous Fraud Detection in Enterprise Systems
through Audit Trail Analysis
Peter J. Best
School of Accounting, Economics & Finance
University of Southern Queensland
Toowoomba, Queensland, 4350, Australia
Tel: (+61) 7 4631 1231 / Fax: (+61) 7 4631 5594
Email: [email protected]
Pall Rikhardsson
Financial Intelligence Division
Business Advisory, SAS Institute A/S
Købmagergade 7-9, DK-1150 Copenhagen K, Denmark
Tel: (+45) 7028 2506
Mark Toleman
School of Information Systems
University of Southern Queensland
Toowoomba, Queensland 4350 Australia

Tel: (+61) 7 4631 5593 / Fax: (+61) 7 4631 5594
ABSTRACT
Enterprise systems, real time recording and real time reporting
pose new and
significant challenges to the accounting and auditing
professions. This includes
developing methods and tools for continuous assurance and
fraud detection. In
this paper we propose a methodology for continuous fraud
detection that exploits
security audit logs, changes in master records and accounting
audit trails in
enterprise systems. The steps in this process are: (1) threat
monitoring-
surveillance of security audit logs for ‘red flags’, (2) automated
extraction and
analysis of data from audit trails, and (3) using forensic
investigation techniques
to determine whether a fraud has actually occurred. We
demonstrate how mySAP,
an enterprise system, can be used for audit trail analysis in
detecting financial
frauds; afterwards we use a case study of a suspected fraud to
illustrate how to
implement the methodology.
Keywords: Continuous assurance, continuous audit, fraud
detection, enterprise
system, accounting information systems, mySAP, audit trails.

40
1. INTRODUCTION
Fraud continues to be of major concern to business companies,
not-for-profit
organizations and governmental agencies. Recent surveys by
leading accounting
firms document that fraud is costing these organizations billions
of dollars per
year (BDO 2008; KPMG 2008; Standards Australia 2008).
Furthermore, fraud
means reduced macroeconomic output. Estimates indicate that
fraud costs the
Australian economy up to 3 billion dollars each year (Standards
Australia 2008).
The incidence and financial impact of fraud seems to be steadily
increasing and
many organizations are ill-prepared to prevent and detect fraud
(KPMG 2008).
Australian Standard AS 8001-2008 (Standards Australia 2008)
proposes that
organizations implement a fraud detection program to quickly
identify instances
of fraud should preventive measures and internal controls fail.
It recommends the
development of systems for targeted post-transactional review
and strategic use of
computer systems including effective data mining and real-time
transaction
assessment to identify suspect fraudulent transactions. In a
similar vein, PCAOB
Auditing Standard No. 5 stresses the responsibility of external
auditors to conduct

a fraud risk assessment in planning and performing the audit of
internal control
over financial reporting, and to consider deficiencies in controls
to prevent and
detect fraud when assessing the risk of material misstatement in
the financial
statements (PCAOB 2007).
Few information technology innovations have had as much
impact on business
organizations in recent years as enterprise systems (sometimes
known as
enterprise resource planning systems or ERP) (Rikhardsson &
Kraemmergaard
2006). Enterprise systems are off-the-shelf applications that
offer a
comprehensive set of functionalities supporting and integrating
most business
processes, including accounting, sales, purchasing and
production in a single
system architecture. An enterprise system has several
distinctive characteristics
(Norris et al. 1998):
• Multi-functional in scope – it tracks financial results (dollars),
procurement (material), sales (people and goods) and
manufacturing
(people and resources);
• Integrated in nature, that is, when a piece of data is entered
regarding one
of the functions, data relevant to other functions is changed;
• Modular in structure, that is, it can be used in a way that is as
expansive
or narrow as an organization chooses.

Modern enterprise systems are web enabled, which can mean
browser based user
interfaces, standardised data exchange and web-based reporting.
It has been
estimated that organizations worldwide spend approximately
$18.3 billion US
every year on enterprise systems (Shanks et al. 2003). These
systems have
significant implications for accounting and auditing in general
and fraud control
in particular (ITGI 2006; Bae & Ashcroft 2004, Chapman &
Chua 2003;
41
Chapman 2005). However, enterprise systems are not typically
utilised for fraud
detection, certainly not in a systematic manner. These systems
increase the
complexity of the accounting and auditing environment but also
offer new
opportunities for improvements in effectiveness and efficiency
of these processes
(Spathis 2006).
Enterprise systems offer functionalities for continuous
monitoring of controls and
detecting fraudulent transactions. One such functionality is
audit trails. This paper
illustrates how audit trails in enterprise systems can be used for
continuous fraud

detection. It discusses continuous assurance and fraud detection
and links these
processes to enterprise systems. It explains the concept of audit
trails and how
they can be used for fraud detection within the context of a
specific enterprise
system solution – i.e. mySAP, which is described below, is a
product of the
German company SAP. It then proposes a methodology for
continuous fraud
detection that utilises various audit trails available in enterprise
systems, namely
security audit logs, changes in master records and accounting
audit trails. This
methodology is comprised of two stages: (1) threat monitoring,
involving high-
level surveillance of security audit logs for ‘red flags’, and (2)
automated
extraction and analysis of data from audit trails to document
user actions. At that
point, forensic investigation is used to determine whether a
financial fraud has
been committed.
2. DEDUCTIVE FRAUD AUDITING
The essential steps in detecting fraudulent transactions are
(Albrecht et al. 2009;
Institute of Internal Auditors 2003):
1. Understanding the business or operations.
2. Performing a risk analysis to identify the types of frauds that
can
occur.
3. Deducing the symptoms that likely frauds would generate.
4. Using computer software to search for these symptoms.

5. Investigating suspect transactions.
Each organization must incorporate within its risk management
processes
consideration of fraud risks. Common fraud schemes, preventive
measures and
symptoms (‘red flags’) are well-documented (see Albrecht et al.
2009; Baker
1999; Bologna & Lindquist 1995; Institute of Internal Auditors
2003; Koletar
2003; Zack 2003). For example, vendor frauds may involve
creation of a fake
vendor, purchase order, goods movement and invoice, or just a
subset of these
transactions. The enterprise system may pay the invoice
automatically once these
steps have been completed with Electronic Funds Transfer
(EFT). EFT allows the
transfer of money to the perpetrator’s bank account without
having to establish a
bank account in the name of the vendor.
The perpetrator may change the banking details for a vendor
with whom the
42
organization transacts frequently. These details specify the bank
number and the
account number to be paid through bank transfer. The
perpetrator switches these

details to their own bank account or that of an accomplice. An
invoice (often a
duplicate) is entered for payment, and is subsequently paid
automatically by the
system (possibly without the involvement of the perpetrator).
The banking details
are then switched back to their original form. This is referred to
as ‘flipping bank
details’. The respective vendor does not receive the duplicate
payment and is
therefore not aware of the fraud. Auditors may sample the
invoice and payment,
but will find them apparently genuine. Tests for duplicate
invoices and payments
may detect this fraud. However, many organizations have large
numbers of
duplicate payments, e.g. lease payments on photocopiers, and
investigation of
each transaction may not be feasible. This scheme is more
difficult to detect if the
invoice details are similar, but not identical.
Segregating vendor maintenance, invoice entry and payment can
significantly
reduce the risk of such frauds in the absence of collusion among
personnel
(Srinidhi 1994; Little and Best 2003). Weaknesses in
segregation controls are
common and often provide opportunities for such fraud schemes
(KPMG 2008).
The Sarbanes-Oxley Act (SOX) of 2002 has brought fraud and
fraud detection to
the fore with its emphasis on improving internal controls to
reduce the risk of
financial fraud. One of the important issues addressed in SOX is
timely fraud
detection and the link between fraud detection, internal controls

and information
systems (ITGI 2006). The premise is that early detection of
fraud limits losses,
prevents further fraud and improves controls. The real time
nature of transaction
data in enterprise systems and integrated accounting systems
presents a specific
challenge in that regard.
The next section looks at the area of continuous assurance in the
context of
enterprise systems.
3. CONTINUOUS ASSURANCE
Assurance services have been broadly defined as independent
professional
services that improve the quality of information for decision
makers. In the
literature, continuous assurance also appears to be a broad term
for services that
aim to provide continuous assurance to the buyer of these
services or to a third
party (Best et al. 2004; Alles et al. 2002; Elliot 2002; Rezaee et
al. 2002; Sutton
2006; Jones & Xiao 2003; Yu et al. 2000; Murthy & Groomer
2004; Searcy &
Woodroof 2003; Nelson 2004). The term continuous assurance
is a more far-
reaching term than continuous auditing as the latter service
focuses on assurances
only related to the annual financial report (Alles et al. 2002).
Continuous
assurance usually focuses on the quality of information used in
internal decision
making, publicly disclosed information and measures and
controls for
safeguarding assets (Elliot 2002; Alles et al. 2002).

To implement this process in an enterprise system environment,
two main
approaches have been proposed. These are the Embedded Audit
Module (EAM)
43
approach and the Monitoring and Control Layer (MCL)
approach.
The EAM approach, its benefits, drawbacks, technologies and
processes have
been discussed for many years (Groomer & Murthy 1989;
Groomer & Murthy
2003; Alles et al. 2004; Murthy & Groomer 2004, Debreceny et
al. 2005; Alles et
al. 2006). EAMs are basically independent software modules
embedded in an
information system where they monitor transactions and
activities. Research
indicates that this approach runs into practical difficulties
(Debreceny et al 2005;
Kuhn & Sutton 2006). For example, concerns include having a
“foreign” code in
its enterprise system that is controlled by a third party – i.e. the
external auditors.
The maintenance of an EAM can be difficult given the changes,
updates and
modifications that routinely take place in enterprise systems.
There are also legal
liability issues should the EAM damage the host system in some

way – a liability
that an external auditor may be keen to avoid. Consequently,
the use of EAM is
limited (Debreceny et al. 2005; Alles et al. 2006).
As an alternative to EAM, the use of a MCL has been suggested.
This approach
also has a rather long history in the context of information
systems dating as far
back as 1991 (Vasarhelyi & Halper 1991; Vasarhelyi et al.
2004; Kuhn & Sutton
2005; Alles et al. 2006; Kuhn & Sutton 2006; Du & Roohani
2007; Li et al.
2007). The MCL differs from the EAM in that it is an
independent non-integrated
software solution that uses middleware to extract data from the
enterprise system
which is to be monitored. This data can then be compared to a
predefined set of
rules or analysed. Currently, this approach seems more viable
than the EAM
approach as it does not have the same concerns regarding
software maintenance,
legal liability and client independence (Kuhn and Sutton 2006).
Moreover, this
approach is the one followed by many of the software vendors
currently offering
software solutions for continuous monitoring. It is also the
approach explored in
the section on automated continuous fraud detection later in this
paper.
The monitoring activities conducted in both the EAM and the
MCL approaches
can focus on transaction data, which is monitored for violations
of preset
standards or unusual patterns. Examples could be postings on
certain accounts

exceeding some maximum posting limits or transaction flows
exhibiting some
unusual characteristics over a certain period of time. The
monitoring activities
may also focus on user behaviour. In most enterprise systems,
users’ activities are
logged. Changes in configuration, security and master records,
and financial
transactions are tagged with date/timestamps, user
identification, and workstation
identification which are collected in various audit trails. As will
be discussed later,
these audit trails are of different types but usually an integrated
part of the system.
Some audit trails must be activated before they become
functional; others are a
standard part of the system and are automatically present. These
audit trails can
then be extracted from the system and analysed for atypical user
activity,
authorization breaches, and profiling the activities of particular
users.
In the following sections, we will discuss audit trails in
enterprise systems, their
44
form in mySAP, and the detection of a vendor fraud using audit
trail analysis.
4. AUDIT TRAILS AND ENTERPRISE SYSTEMS

Audit trails are records of user activity. They may be
maintained by the operating
system and by application software such as enterprise systems.
Operating system
audit trails record user actions, including successful and failed
logins and
programs executed, as well as resources consumed. Enterprise
systems typically
incorporate authentication processes and user roles/profiles that
restrict access to
the application and limit a user’s capabilities to those
associated with his/her job
function. Potential fraud threats and related principles of
segregation of duties
should guide the design of user roles/profiles. Audit trails
maintained by
enterprise systems may include security audit logs, records of
changes in master
records and details of accounting transactions.
It is important to point out that these audit trails do not
necessarily involve EAM
nor MCL. These audit trails are part of enterprise systems and
often have their
own reporting facilities. However, in the context of continuous
auditing they can
be used for monitoring user activity. As such they can be a part
of either EAM or
MCL approaches.
Enterprise system security audit logs typically record details of
each user action.
These logs often include successful logins, failed logins,
starting a transaction
(e.g. entry of an invoice), failed attempts to start transactions
(i.e. prevented by the
user’s role/profile), automatic locking of a user’s account

because of multiple
failed logins, creation of new roles/profiles and changes in user
master records.
Configuration of the security audit log defines what events are
recorded. For
example, only failed activity may be recorded. These audit trails
may be retained
for periodic review, then archived and/or deleted.
Master records, such as those for vendors, are an important
ingredient in many
fraud schemes. In order for the system to distribute funds
through a cheque or
EFT payment, a master record must be created or modified (e.g.
temporarily
changing a vendor’s banking details). Records of such changes
in master records
show user identification, type of change (e.g. create, delete,
change), and contents
of fields created/deleted/changed. Accounting audit trails are
sets of records that
permit tracing accounting transactions from their source to the
updating of
accounting balances, or tracing any account balance back
(‘drilling-down’) to the
relevant source transactions. They provide the organization with
the ability to
maintain sufficiently detailed records to answer enquiries from
customers or
vendors, to produce detailed reports and monthly statements for
customers, and to
provide data for managerial decision-making. Master record
changes and
accounting audit trails are retained on-line usually for the entire
fiscal year, and
archived for several years to satisfy the requirements of taxation
and company

legislation.
The audit trails of enterprise systems can serve several
purposes:
45
1. Review of access: Audit trails allow examination of the
history of access
by individual users or groups of users, showing actions
performed or
attempted. Audit trails also can report which users have
performed
specific functions, such as changes to vendor master records or
the entry
of vendor invoices. Analysis of audit trails may also reveal
limitations in
the organization’s security model and its implementation.
2. Review of changes in security: Changes made to the security
of the
system can be reviewed periodically by an independent person
for
authorisation and integrity.
3. Review of attempts to by-pass security: Audit trails may be
reviewed for
attempts and repeated attempts by users and intruders to
perform
unauthorised functions.

4. Deterrent against attempts to by-pass security: Users should
be aware of
the existence of audit trails and their routine review as a
deterrent against
attempts to by-pass security.
5. Fraud detection: Audit trails can be used to detect potential
fraud by
searching for red flags. Fraudulent activity may be perpetrated
by real
users acting in their own name, by users acting in collusion with
other
users, by real users masquerading as other users, or by intruders
masquerading as authorised users. In each case, the actions of
these
‘users’ are recorded in audit trails and these can be scrutinised
for
activities that are recognised as red flags for particular types of
fraud.
The next section examines how these types of audit trails are
implemented in
mySAP.
5. MYSAP AND SYSTEM SECURITY
The mySAP solution combines complete and scalable software
for enterprise
resource planning with a flexible, open technology platform (the
SAP
NetWeaver) that can leverage and integrate SAP and non-SAP
systems. It builds
on and extends functionalities in earlier SAP solutions (SAP
R/2 and SAP R/3),
which have been on the market since the 1970s. SAP offers
integrated modules
for accounting, production planning, materials management,

sales and
distribution, quality management, project management and
more. mySAP allows
complex enabling companies to integrate most financial, people,
asset and data
management tasks in one comprehensive IT infrastructure. The
mySAP
framework includes four individual solutions: (1) mySAP
Financials, (2) mySAP
Human Capital Management, (3) mySAP Operations and (4)
mySAP Corporate
Services.
The system provides functionality supporting internal control
assessment, such as
reporting on changes in user profiles and segregation of duties.
End-users and
‘system’ users access the system through the same
authentication process
46
requiring the entry of a client identification, user name,
password and language.
These users share the same main menu to access accounting,
logistics
(procurement, sales, production) and human resource
transactions, as well as the
mySAP program development, security administration and
configuration
functions. Accordingly, access controls must be implemented to

restrict the
actions of all users in conformance with their assigned roles.
Access and user controls are implemented in mySAP using
roles, profiles and
authorizations which are assigned to users. The individual
functions (menu
options) are identified within the system using transaction
codes. For example, the
function to change vendor master records has the transaction
code FK02. Entry of
a vendor invoice is FB60. Associated with each transaction code
is a set of
authorizations which must be assigned to a given user to allow
them to perform
that function. User profiles consisting of sets of authorizations
and other profiles
should be designed according to principles of segregation of
incompatible
transaction codes in order to reduce opportunities for fraud
(Little & Best 2003).
Any user who has the authority to change a vendor’s banking
details and enter a
vendor invoice has the opportunity to commit fraud.
Security administrators use mySAP’s profile generator software
to design generic
roles which may be assigned to individuals. To illustrate, a role
may be designed
for vendor maintenance officers, consisting of just the
transaction codes required
for that role and considering relevant segregation of duties
principles. Such a role
should not include the transaction code FB60 Enter Vendor
Invoice. Profile
generator automates the process of building profiles with the
required
authorizations for roles. Given the large number of transaction

codes in the
system (at least 125,000) and some uncertainty regarding
appropriate segregation
principles, some users may be assigned authorizations which
permit certain fraud
schemes. Accordingly, there is a need for auditing of access
controls and
automated approaches for fraud detection which analyse audit
trails.
Auditors typically plan to evaluate and test the client’s security
model for
compliance. This model consists of a set of roles (or profiles)
and their
assignment to users. The transactions (and authorizations)
assigned to each role
are also documented. The security model is ‘desk-checked’ for
completeness and
proper segregation of duties, and then tested for proper
implementation on a
‘sample’ basis by interrogating authorizations, profiles, roles
and user master
records. Proper segregation of organizational responsibilities is
a critical concern
in this process.
Authorizations may also be audited by interrogating system
security tables to
identify authorizations assigned to users and the corresponding
transaction codes
which may be executed. This may be accomplished using
software developed in-
house or acquired from third-party providers, or using standard
mySAP reports.

47
6. DETECTING VENDOR FRAUD WITH AUDIT TRAIL
ANALYSIS IN MYSAP
mySAP offers managers and auditors increased facilities for
monitoring user
activities in the system, including potential fraudulent
activities. These activities
are collected automatically in mySAP’s audit trails. Below we
describe these
facilities and illustrate how a vendor fraud based on changes in
vendor banking
details and duplicate invoice entry may be detected through
audit trail analysis.
The security audit log facility provides a high-level overview of
user activity at
the transaction code level. A profile is created and filters are
defined specifying
which events are recorded in the log (transaction SM19).
Selected events are
stored in a daily audit file on each application server. These
audit files are retained
until deleted.
Filters specify which clients and users are to be monitored.
Events may be
selected for logging according to audit class, such as logons,
transaction starts,
and user master changes, or according to event class - critical
events, critical
events combined with important events, or all events.
Alternatively, a set of
individually selected events may be selected as a detailed audit

configuration.
Once the filter(s) and profile are activated, the application
server must be restarted
and then logging commences.
Table 1 illustrates the relationship between audit classes, event
classes and the
message text for individual events.
Audit records contain the following fields for each logged
event: Date, Time,
Client, User-id, Transaction Code, Terminal Name (computer
name from
Windows), Message Identifier, and Message Text. A reporting
facility is provided
for the security audit log. Reports may be produced for
specified date ranges,
users, transaction codes, audit classes, event classes and
messages.
48

Audit Class Event
Class
Message Text
Dialog Logon Non-Critical User Logoff
Important Logon Successful (Type = $A)
Important Logon Failed (Reason = $B, Type = $A)
Critical Logon Failed (Reason = $B, Type = $A)
Critical User &B Locked in Client $A after Erroneous
Password
Attempts
Critical User &B in Client &A Unlocked After Being Locked
Due
to Invalid Password Entered
Transaction Start Non-Critical Transaction &A Started
Critical Start Transaction &A Failed
User Master Change Non-Critical Password changed for user
&B in client &A
Important User &A Deleted
Important User &A Locked
Important User &A Unlocked
Important Authorizations for User &A Changed
Important User Master Record &A Changed
Important Authorization/Authorization Profile &B Created
Important Authorization/Authorization Profile &B Deleted
Important Authorization/Authorization Profile &B Changed
Critical User &A Created
Critical Authorization/Authorization Profile &B Activated
Other Events Important Download &A Bytes to File &C
Important Digital Signature (Reason = &A, ID = &B)
Critical Digital Signature Error (Reason = &A, ID = &B)
Critical Password check failed for user &B in client &A

System Critical Audit Configuration Changed
Critical Application Server Stopped
Critical Application Server Started
Critical Audit Slot &A Inactive
Critical Audit Active Status Set to &1
Table 1: Security Audit Log – Examples of events that can be
logged
These functionalities can be used to detect fraudulent user
behaviour. Figure 1
presents an excerpt from the security audit log showing a range
of logged events.
Of particular note are the following:
• User HACKERW uses workstation 1 in room S826 (see
column 6 –
Terminal).
• On 01.04.2008, HACKERW attempted to run transaction F110
(column 5 – Transaction Code) Vendor Payments
unsuccessfully.
Message-id AU4 signifies a failed action.
• HACKERW performed changes to vendor master records using
transaction FK02 on 03.04.2008 and 05.04.2008.
• User SMITHY apparently had 3 failed logons on 08.04.2008
from the
same workstation as used by HACKERW. The user was
automatically
locked and had to be unlocked by a security administrator
ZADMIN01.

49
• On 24.04.2008, ZADMIN01 used transaction SU01 to create
user
ZMYUSER. Authorizations were assigned to this user.
• On the same day at 11:31:25, ZADMIN01 used transaction
PFCG
Profile Generator to create a new role Z:VENDM50 (which is
assigned
a series of transaction codes).
• Transaction SUPC (Generate Profiles) was then used to
generate the
authorizations and profile for the new role.
• ZADMIN01 then proceeded to assign the new role to user
ZMYUSER.
• User ZMYUSER then apparently logged on to client 600 and
was
required to change the initial password.
• ZMYUSER used transaction FK02 to perform vendor
maintenance and
then logged off.
• User ZADMIN01 used transaction SU01 to delete user
ZMYUSER
(This can be done even after this user has performed activity in
the

system).
Changes in master records are stored in two tables – CDHDR
Change Document
Headers and CDPOS Change Document Items. Changes include
creation and
deletion of master records and changes in fields. Each change
document header
record in table CDHDR specifies: Client, Object class of the
master record, e.g.
category of vendor, customer, general ledger account, cost
centre, etc., Object
value, i.e. vendor number, cost centre code, Change document
number, User
name who made the change, Date, Time, and Transaction code,
e.g. FK02
Change Vendor Master Record.
For each change document number, there are corresponding
change document
items in the CDPOS table. Change document items have the
following fields:
Client, Object class of the master record, e.g. category of
vendor, customer,
general ledger account, cost centre, etc., Object value, i.e.
vendor number, cost
centre code, Change document number, Table name, e.g. LFBK
– Vendor Master
(Bank Details), Table record key, Field name, Change type -
U(pdate), I(nsert). E
(delete single field), D(elete).
Figure 2 illustrates how changes in banking details for vendor
100163 would
appear in these tables. The original bank recording number and
account number is
123-456 1234567. This vendor was created by user SMITHY on
15.02.2008

using transaction code FK01 (See first row in Table CDHDR
and first row in
Table CDPOS). On 03.04.2008, these details were changed by
user HACKERW
to 123-456 7777777 (see second row in Table CDHDR and
second row in Table
CDPOS), and then restored to the original values on 05.04.2008
(see the third row
in each of the Tables).
50
Date Time Client User Trans
Code
Terminal Message
Id.
Message Text
01.04.2008 08:55:04 600 HACKERW S826-01 AU2 Logon
Failed (Reason = 1, Type = A)
01.04.2008 08:56:30 600 HACKERW S826-01 AU1 Logon
Successful (Type=A)
01.04.2008 11:25:09 600 HACKERW S826-01 BU2 Password
changed for user HACKERW
01.04.2008 12:31:54 600 HACKERW FK01 S826-01 AU3

Transaction FK01 Started
01.04.2008 13:43:11 600 HACKERW F110 S826-01 AU4 Start
Transaction F110 Failed
01.04.2008 18:18:12 600 HACKERW S826-01 AUC User
Logoff
03.04.2008 08:37:40 600 HACKERW AU1 Logon Successful
(Type=A)
03.04.2008 10:20:25 600 HACKERW FK02 S826-01 AU3
03.04.2008 10:23:44 600 HACKERW FB60 S826-01 AU3
Transaction FB60 Started
05.04.2008 17:14:31 600 HACKERW FK02 S826-01 AU3
08.04.2008 08:55:04 600 SMITHY S826-01 AU2 Logon Failed
(Reason = 1, Type = A)
08.04.2008 08:55:09 600 SMITHY AUM User SMITHY
Locked in Client 600 After Erroneous Password
Checks
08.04.2008 09:05:01 600 ZADMIN01 SU01 B315-01 AU3
Transaction SU01 Started
08.04.2008 09:05:02 600 ZADMIN01 B315-01 AUN User
SMITHY in Client 600 Unlocked After Being Locked Due
to Inval. Password Entered
24.04.2008 11:15:33 600 ZADMIN01 B315-01 AU1

Logon Successful (Type=A)
24.04.2008 11:16:16 600 ZADMIN01 SU01 B315-01 AU3
24.04.2008 11:18:38 600 ZADMIN01 SU01 B315-01 AU7
User ZMYUSER Created
24.04.2008 11:18:39 600 ZADMIN01 SU01 B315-01 AUB
Authorizations for User ZMYUSER Changed
24.04.2008 11:28:34 600 ZADMIN01 SU03 B315-01 AU3
24.04.2008 11:31:09 600 ZADMIN01 SU03 B315-01 AUU
Authorization Z:AUTH5001/F_KNA1_BUK Activated
24.04.2008 11:31:25 600 ZADMIN01 PFCG B315-01 AU3
Transaction PFCG Started
24.04.2008 11:33:05 600 ZADMIN01 SUPC B315-01 AU3
Transaction SUPC Started
24.04.2008 11:36:23 600 ZADMIN01 B315-01 AUU
Authorization Z:VENDM50_00/ F_BKPF_BEK Activated
24.04.2008 11:36:24 600 ZADMIN01 B315-01 AUU
Authorization Z:VENDM50_00/ F_BKPF_BLA Activated
24.04.2008 11:36:24 600 ZADMIN01 B315-01 AUU
Authorization Z:VENDM50_00/ F_BKPF_BUK Activated
24.04.2008 11:36:24 600 ZADMIN01 B315-01 AUU
Authorization Z:VENDM50_00/ F_BKPF_GSB Activated
24.04.2008 11:36:24 600 ZADMIN01 B315-01 AUU
Authorization Z:VENDM50_00/ F_BKPF_KOA Activated
24.04.2008 11:36:24 600 ZADMIN01 B315-01 AUU
Authorization Z:VENDM50_00/ F_LFA1_AEN Activated
24.04.2008 11:36:24 600 ZADMIN01 B315-01 AUU
Authorization Z:VENDM50_00/ F_LFA1_APP Activated
24.04.2008 11:36:24 600 ZADMIN01 B315-01 AUU
Authorization Z:VENDM50_00/ F_LFA1_BEK Activated
24.04.2008 11:36:24 600 ZADMIN01 B315-01 AUU
Authorization Z:VENDM50_00/ F_LFA1_BUK Activated
24.04.2008 11:36:24 600 ZADMIN01 B315-01 AUU
Authorization Z:VENDM50_00/ F_LFA1_GEN Activated
24.04.2008 11:36:24 600 ZADMIN01 B315-01 AUU

Authorization Z:VENDM50_00/ F_LFA1_GRP Activated
24.04.2008 11:36:24 600 ZADMIN01 B315-01 AUU
Authorization Z:VENDM50_00/
S_TCODE Activated
24.04.2008 11:36:24 600 ZADMIN01 B315-01 AUU
Profile Z:VENDM50_ Activated
24.04.2008 11:37:15 600 ZADMIN01 SU01 B315-01 AU3
24.04.2008 11:37:47 600 ZADMIN01 SU01 B315-01 AUD
User Master Record ZMYUSER Changed
24.04.2008 11:37:48 600 ZADMIN01 SU01 B315-01 AUB
Authorizations for User ZMYUSER Changed
24.04.2008 11:38:10 600 ZMYUSER B315-01 AU1
Logon Successful (Type=A)
24.04.2008 11:38:18 600 ZMYUSER B315-01 BU2
Password changed for user ZMYUSER in client 600
24.04.2008 11:39:00 600 ZMYUSER FK02 B315-01 AU3
24.04.2008 11:40:07 600 ZMYUSER B315-01 AUC
User Logoff
24.04.2008 11:56:16 600 ZADMIN01 SU01 B315-01 AU3
24.04.2008 11:58:38 600 ZADMIN01 SU01 B315-01 AU8
User ZMYUSER Deleted
24.04.2008 18:18:12 600 ZADMIN01 B315-01 AUC User
Logoff
Figure 1 - mySAP Security Audit Log

51
Figure 2 - Changes in Vendors Banking Details in mySAP
Figure 3 provides an overview of tables storing mySAP
financial accounting audit
trails. In following the audit trail from Figure 2 to Figure 3, it
can be seen that
HACKERW used transaction code FB60 (see table BKPF) to
enter a vendor
invoice on 03.04.2008. This transaction was recorded as
document number
1000000201 in table BKPF Accounting Document Headers. The
user name, date
and transaction code are stored in this record. There are three
debit/credit entries
corresponding to this document in table BSEG Accounting
Document Line Items.
Every posting to a general ledger reconciliation (control)
account also specifies
the relevant subsidiary ledger record. Since account number
209000 (Table
SKAT) is the Accounts Payable account, the vendor number
(100163) is also
recorded in the line item record (Table LFA1). Tables BKPF
and BSEG store the
posting history for both general ledger accounts and subsidiary
ledger records,

thereby facilitating both integration of data and automatic
reconciliation of
subsidiary ledgers with reconciliation accounts. General ledger
account texts
(names) are stored in table SKAT. Vendor general data
including vendor name,
date created and creating user are stored in table LFA1.
As can be seen in the above, the data describing the fraud is
well-documented in
the audit trails in the enterprise system. However, detecting user
activities and
analysing them for fraud potential is a laborious task if done
manually. We
propose a methodology based on automated continuous analysis
of audit trails.
52
Figure 3 - mySAP Audit Trail
7. AUTOMATED CONTINUOUS FRAUD DETECTION
METHODOLOGY
Using mySAP as an example, we propose an MCL-based
methodology for fraud
detection that utilises the security audit logs, changes in master
records and

accounting audit trails present in mySAP. This methodology is
comprised of two
stages: (1) threat monitoring, which involves high-level
surveillance of security
audit logs for ‘red flags’, and (2) automated extraction and
analysis of data from
audit trails to provide documentation of user actions. These two
stages are
demonstrated for the vendor fraud scenario.
Stage 1 involves threat monitoring (routine scanning) of
security audit logs. These
logs should be extracted for regular review and retained to
provide a permanent
actual user profile for each user. The organization may develop
a database
application storing security audit logs for the past year, and
user profiles (the set
of transaction codes performed by each user during specific
time periods, e.g. last
week, last month). Queries should be available to list users who
have performed
specified transaction codes. Standard reports should be
available to present any
specified user’s profile and to highlight changes in users’
profiles over time. A
knowledge base system may also be developed to generate
forecasts of expected
user activity. Changes in actual user behaviour may then be
detected promptly
and investigated (Best et al. 2004).
To detect specific fraud threats, a standard report should present
a list of users and
log details where a critical combination of transaction codes has
been performed
by a user. For example, any user who has performed vendor
master record

changes (transaction code FK02) and vendor invoice entry
(FB60) should be
classified as suspicious, since the combination of these
functions may signal the
53
flipping of bank details and vendor fraud as described in the
diction on deductive
fraud auditing. A table of suspects should be generated to
facilitate detailed
analyses of master record changes and accounting transactions.
In Figure 1,
HACKERW, who executed these transactions, would be
identified as a potential
suspect. Identification of the affected vendors requires data
extraction from the
appropriate audit trails.
Stage 2 requires routine extraction of master record changes and
accounting audit
trails, as a foundation for further analysis of suspect behaviour
for the set of
chosen fraud schemes. The following data may be extracted
from mySAP through
the data dictionary or using remote function calls.
1. Change document headers: Records are extracted from table
CDHDR (see Figure 2) for changes involving vendor account
groups, the current fiscal year and critical transaction codes
(e.g.

FK02).
2. Change document items: Records are extracted from table
CDPOS
(see Figure 2) for INSERT (I) changes involving vendor account
groups, table LFBK, and field KEY.
3. Accounting document headers: Records are extracted from
table
BKPF (see Figure 3) for documents involving the target
company
code, current fiscal year, and transaction codes associated with
fraud
schemes (e.g. FB60 – vendor invoice entry, F110 – vendor
payment).
4. Accounting document line items: Records are extracted from
table
BSEG (see Figure 3) for postings (rows) involving the target
company code, current fiscal year, and accounts payable general
ledger accounts.
Change document headers and change document items may be
used to produce a
detailed analysis of the banking details changes performed by
the suspect users. In
particular, the relevant vendor numbers are identified. For
example, examining
the data in Figure 2, it is evident that HACKERW has changed
the banking details
for vendor 100163, on 03.04.2008 and switched them back on
05.04.2008. The
accounting document headers and line items may be used to
present the
accounting transactions entered by the suspects and invoice and
payment

transactions for the associated vendors. The invoice (FB60)
posted by
HACKERW on 03.04.2008 was for $77,000 (including sales tax)
to vendor
100163. Such an analysis may be correlated to test for specified
sequences of
events such as: changed vendor details, entered invoice,
payment of invoice,
changed vendor details. If payment occurs before 05.04.2008, it
appears that
HACKERW may have successfully perpetrated a vendor fraud
since payment is
made to the changed banking details before they are flipped
back. A thorough
investigation is still required to determine whether this is the
case.
54
8. CASE STUDY RESULTS – A LARGE AUSTRALIAN
COMPANY
The application of this methodology assisted in a fraud
investigation for a large
Australian company with a very large mySAP system
implementation.
Basic application of threat monitoring of the security audit log
revealed that a
terminated system administration person (SADMIN01) had
since logged in and

changed a password and the profile of his spouse, also in system
administration
(SADMIN02). A high risk of unauthorised activity and/or fraud
was identified,
possibly involving SADMIN01, SADMIN02 or both users
working in collusion.
The findings from the application of this methodology are
summarised below.
More thorough threat monitoring was instituted covering a
period of over four
years. It seemed that both SADMIN01 and SADMIN02 had been
engaged in
vendor maintenance (FK02) and invoice entry (FB60) activity.
However, other
system administrators had also performed similar functions, in
some cases to a
much larger extent. Concern was raised that members of the
SADMIN group
could be working in collusion with SADMIN01 and/or
SADMIN02. These users
were also responsible for user security, including the creation
and maintenance of
user master records and profiles. There was also an increased
risk of fake users in
the system, engaged in fraudulent activities.
SADMIN01, SADMIN02, SADMIN04, SADMIN06 and
SADMIN11 had made
changes to vendors (FK02) as follows:
• SADMIN01 – 2 changes to only 2 vendors. No flipping of
bank details
was feasible.
• SADMIN02 – 689 changes, with more than 1 change to only
13 vendors.
Flipping was feasible. No changes were made to vendors

maintained by
SADMIN01.
• SADMIN04 – 7 changes with more than 1 change to only 2
vendors.
Flipping was feasible. No changes were made to vendors
maintained by
SADMIN01.
• SADMIN06 – 2585 changes with more than 1 change to more
than 500
vendors. No changes were made to vendors maintained by
SADMIN01.
• SADMIN11 – 4403 changes with more than 1 change to more
than 400
vendors. 1 change was made to a vendor maintained by
ZADMIN01.
The vendors maintained by SADMIN01 and SADMIN02 were
targeted to
investigate the presence of flipping activity. Numerous changes
to banking details
of vendors were performed by SADMIN11 on Christmas Eve in
year 1, which
were subsequently changed (back in some cases) by SADMIN02
after the
Christmas/New Year break. The apparent flipping of bank
details occurred for
large numbers of vendors, but these details remained in force
for several weeks. A

55
small number of immaterial financial transactions were entered
for these vendors
during this period by SADMIN04 and SADMIN06. There was
no evidence of
exploiting the changed bank details during this period to
commit material fraud.
Internal audit were charged with the task of investigating this
unusual set of
events.
Flipping of bank details could be indicated by the apparent
sharing of bank
accounts. This occurs when an invoice is paid to the account of
a vendor, which
has the same bank details as another vendor in the system. Some
evidence of bank
account sharing by vendors was revealed, but these cases
involved spouses or
multiple vendor master records for the same vendor. These were
examined and
were considered genuine.
SADMIN users were also engaged in the entry of financial
transactions, including
FB60. An examination was performed on the financial
transactions entered by
SADMIN01 and SADMIN02 for the vendors changed by these
users. These
postings were trivial in amount. Only five were payments.
Financial transactions
for these vendors entered by other SADMIN users appeared
normal and did not
involve the redirection of payments to other bank accounts.
Despite the alert raised on discovery of the abnormal activity by

SADMIN01 (and
SADMIN02), there was no evidence found of material fraud by
that user. It
seemed that SADMIN users performed the functions of normal
users –
maintaining vendors, entering invoices and paying vendors.
There were breaches
in the normal segregation of duties principles: (1) separating the
functions
performed by accounting users from those of system
administrators; and (2)
separating vendor maintenance, entry of invoices/postings and
payment functions.
The financial transactions entered by SADMIN01 and
SADMIN02 appeared
trivial vendor changes.
This investigation led to wide changes to user profiles in this
company.
Segregation amongst normal users seemed to be following
appropriate
segregation principles. However, vendor maintenance and
invoice entry were not
adequately segregated. Two accounts payable personnel were
subsequently
assigned new profiles for vendor maintenance and invoice entry
respectively. It
was determined that SADMIN users had been able to perform
vendor
maintenance, invoice entry and payment transactions because of
their assigned
user profiles. These were mainly SAP_ALL profiles which give
the user
unlimited access to system functions. It was necessary to design
new profiles for
SADMIN users that explicitly provided authorizations for their
roles in system

administration. This had the effect of removing their ability to
perform the
functions of accounting users.
This investigation highlights the potential vulnerability to
vendor fraud that may
arise from inadequate segregation of duties and the need for
automated
continuous fraud detection solutions.
56
9. LIMITATIONS
It is important to acknowledge the limitations of the fraud
detection methodology
presented in this paper. The audit trails that are maintained by
enterprise systems
are the basis for this methodology. As such, their integrity is
paramount in
assessing the usefulness of this methodology for detecting
actual fraud.
The behaviour of individual users will be recorded in detail in
the audit trails.
However, system administrators, often called ‘super-users’
given their unlimited
privileges, may be able to selectively edit audit trail data, such
as entries in the
security audit log, to remove evidence of ‘red flags’ associated
with their own
activity. Similarly, intruders in the system who are
masquerading as authentic

users may target these super-users and exploit these capabilities
to remove any
trace of their activities in the system.
Accordingly, it is acknowledged that the fraud detection
methodology proposed in
this paper may not be useful in detecting fraud by super-users,
nor intruders who
masquerade as these powerful users. However, this methodology
is very useful in
detecting fraudulent behaviour by normal users or intruders
masquerading as such
users, who lack these capabilities. Most reported cases of fraud
seem to be
perpetrated by such unsophisticated users.
10. CONCLUSION
This paper has addressed some of the challenges enterprise
systems and
continuous assurance pose to the accounting and auditing
professions. One
important challenge is how fraud detection can be integrated
into continuous
assurance services in the enterprise system. This paper has
demonstrated one
possible method for continuous fraud detection in enterprise
systems based on
extraction of data from audit trails. It proposes a methodology
using audit trail
analysis where user behaviour is monitored and analysed to
detect specific fraud
scenarios. Its application was demonstrated using the mySAP
solution. The
application of this methodology in investigating potential
material fraud was also
demonstrated using a case study of an Australian company.
Looking at the enterprise systems market and current vendor

strategies,
developments could be expected to take one of two routes. One
is that
continuous assurance tools continue to be stand-alone
applications that extract
data from the enterprise system – i.e. the MCL approach. The
other is that
enterprise system vendors will incorporate these systems in
their enterprise
systems solutions and develop EAM for use by auditors.
Accounting information systems have undergone considerable
change over the
past decade, and more extensive changes are likely to come in
the future.
Assurance services and associated technologies must keep pace
with these
changes. Accordingly, the development of continuous
monitoring tools and
fraud detection will be rich research areas. This includes further
research into
the applicability of EAM and MCL approaches respectively, the
differences
57
and similarities between different enterprise system vendor
approaches, the
practices of auditing firms regarding continuous auditing and
determinants of
market demand for continuous assurance and continuous

assurance tools.
11. REFERENCES
Albrecht, W.S., Albrecht, C.C., Albrecht, C.D. and Zimbelman,
M. (2009),
Fraud Examination, Third Edition, Thomson/South-Western,
Mason OH.
Alles, M., Kogan, A. and Vasarhelyi, M.A. (2002), “Feasibility
and Economics
of Continuous Assurance”, Auditing, 21(1): 126-138.
Alles, M., Kogan, A. and Vasarhelyi, M.A. (2004), “Restoring
Auditor
Credibility: Tertiary Monitoring and Logging of Continuous
Assurance
Systems”, International Journal of Accounting Information
Systems, 5: 183-
202.
Alles, M., Brennan, G., Kogan, A. and Vasarhelyi, M.A. (2006),
“Continuous
Monitoring of Business Process Controls: A Pilot
Implementation of a
Continuous Auditing System at Siemens”, International Journal
of
Accounting Information Systems, 7: 137-161.
Bae, B. and Ashcroft, P. (2004), “Implementation of ERP
systems: Accounting
and Auditing Implications”, Information System Control
Journal, 5: 43-56.
Baker, K. (1999), Internal Control and Fraud Prevention in
Hospitality
Operations, Pearson Education - Hospitality Press, Sydney.
BDO (2008), ‘BDO Not-For-Profit Fraud Survey’,
www.bdo.com.au,
15/1/2009.
Best, P.J., Mohay, G. and Anderson, A. (2004), “Machine-
Independent Audit

Trail Analysis – A Decision Support Tool for Continuous Audit
Assurance”,
International Journal of Intelligent Systems in Accounting,
Finance and
Management, 12: 85-102.
Bologna, J.G. and Lindquist, R.L. (1995), Fraud Auditing and
Forensic
Accounting: New Tools and Techniques, Wiley, New York.
Chapman, C., and Chua, W.F. (2003), ‘Technology-driven
integration,
automation and standardisation of business process:
Implications for
accounting’, in Management Accounting in the Digital
Economy, ed. Bhimani,
A., Oxford University Press, Oxford, 74-79.
Chapman, C. (2005), “Not Because They are New. Developing
the
Contribution of Enterprise Resource Planning Systems to
Management Control
Research”, Accounting, Organizations and Society, 30: 685–
689.
Debreceny, R.S., Gray, G.L., Jun-Jin Ng, J., Siow-Ping Lee, K.
and Yau, W.
(2005), “Embedded Audit Modules in Enterprise Resource
Planning Systems:
Implementation and Functionality”, Journal of Information
Systems, 19(2): 7-
58

27.
Du, H. and Roohani, S. (2007), “Meeting Challenges and
Expectations of
Continuous Auditing in the Context of Independent Audits of
Financial
Statements”, International Journal of Auditing, 11(2): 133-146.
Elliot, R.K. (2002), “Twenty-First Century Assurance”,
Auditing, 21(1): 139-
146.
Groomer, S.M., and Murthy, U.S. (1989), “Continuous Auditing
of Database
Applications: An Embedded Audit Module Approach”, Journal
of Information
Systems, 3(2): 53-69.
Groomer, S.M. and Murthy, U.S. (2003), “Monitoring High
Volume On-line
Transaction Processing Systems Using a Continuous Sampling
Approach”,
International Journal of Auditing, 7: 3-19.
Institute of Internal Auditors (2003), Proactively Detecting
Occupational Fraud
Using Computer Audit Reports, Institute of Internal Auditors
Research
Foundation, Altamonte Springs, Florida.
ITGI – IT Governance Institute (2006), IT Control Objectives
for Sarbanes-
Oxley, Second Edition.
IT Governance Institute, Rolling Meadows IL, www.isaca.org,
21/4/2008.
Jones, J.M. and Xiao, J.Z. (2003), “Internet Reporting: Current
Trends and
Trends by 2010”, Accounting Forum, 27(2): 132-165.
Koletar, J.W. (2003), Fraud Exposed: What You Don’t Know
Could Cost Your
Company Millions, Wiley, New York.
KPMG (2008), ‘KPMG 2008 Fraud Survey’, www.kpmg.com.au,

20/1/2009.
Kuhn, J.R. and Sutton, S. (2005), ‘Learning from WorldCom:
Implications for
Fraud Detection Through Continuous Assurance’, 10th World
Continuous
Auditing and Reporting Symposium, November, Newark, NJ.
Kuhn, R. and Sutton, S. (2006), Commentary On “Embedded
Audit Modules
In Enterprise Resource Planning Systems: Implementation And
Functionality”,
Working Paper, Kenneth G. Dixon School of Accounting,
University of
Central Florida.
Li, Y., Roget, J.N., Rydl, L. and Hughes, J. (2007), “Achieving
Sarbanes-
Oxley Compliance with XBRL-Based ERP and Continuous
Auditing”, Issues
in Information Systems, 8(2): 430-436.
Little, A.G. and Best, P.J. (2003), “A Framework for
Segregation of Duties in
an SAP R/3 Environment”, Managerial Auditing Journal, 13(5):
419-430.
Nelson, L. (2004), “Stepping into Continuous Audit”, Internal
Auditor, April,
27-29.
59
Norris, G., Wright, I., Hurley, J.R., Dunleavy, J. and Gibson, A.
(1998), SAP:

An Executive’s Comprehensive Guide, Wiley, New York.
Murthy, U. and Groomer, S.M. (2004), “A Continuous Auditing
Web Service
Model for XML-Based Accounting Systems”, International
Journal of
Accounting Information Systems, 5: 138-163.
PCAOB (2007), Auditing Standard No. 5 An Audit of Internal
Control Over
Financial Reporting that is Integrated with an Audit of Financial
Statements.
Rezaee, A., Sarbatoghlie, A., Elam, R. and McMickle, P.L.
(2002),
“Continuous Auditing: Building Automated Auditing
Capability”, Auditing,
21(1): 145-163.
Rikhardsson, P.M. and Kraemmergaard, P. (2006), “Identifying
the Impacts of
Enterprise System Implementation and Use: Examples from
Denmark”,
International Journal of Accounting Information Systems, 7(1):
36-49.
Searcy, D. and Woodroof, J.B. (2003), “Continuous Auditing:
Leveraging
Technology”, The CPA Journal, May: 46-48.
Shanks, G., Seddon, P.B. and Willcocks, L.P. (2003), ‘ERP –
The Quiet
Revolution?’ in Second-Wave Enterprise Resource Planning
Systems:
Implementing for Effectiveness, eds. Shanks, G., Seddon, P.B.
and Willcocks,
L.P., Cambridge University Press, Cambridge, 1-22.
Srinidhi, B. (1994), “The Influence of Segregation of Duties on
Internal
Control Judgements”, Journal of Accounting, Auditing &
Finance, 9(3): 423-
444.

Spathis, C. (2006), “Enterprise Systems Implementation and
Accounting
Benefits”, Journal of Enterprise Information Management,
19(1): 67-82.
Standards Australia (2008), ‘Australian Standard AS 8001-2008
- Fraud and
Corruption Control’,
www.saiglobal.com/shop/Script/search.asp, 10/2/2009.
Sutton, S. (2006), “Extended-Enterprise System Impact on
Enterprise Risk
Management”, International Journal of Accounting Information
Systems,
19(1): 97-114.
Vasarhelyi, M.A., Alles, M. and Kogan, A. (2004), “Principles
of Analytic
Monitoring for Continuous Assurance”, Journal of Emerging
Technologies in
Accounting, 1: 1-21.
Vasarhelyi, M.A. and Halper, F.B. (1991), “The Continuous
Audit of Online
Systems”, Auditing: A Journal of Practice and Theory,
10(1):110-125.
Yu, C.-C., Yu, H.-C. and Chou, C.-C. (2000), “The Impact of
Electronic
Commerce on Auditing Practices: An Auditing Process Model
for Evidence
Collection and Validation”, International Journal of Intelligent
Systems in
Accounting, Finance & Management, 9: 195-216.
60

Zack, G.M. (2003), Fraud and Abuse in Non-Profit
Organizations, Wiley, New
York.
Reproduced with permission of the copyright owner. Further
reproduction prohibited without permission.
AUTOMATING VENDOR FRAUD DETECTION IN
ENTERPRISE SYSTEMS
Singh, Kishore; Best, Peter; Mula, Joseph. The Journal of
Digital Forensics, Security and Law : JDFSL8.2 (2013): 7-42.
Turn on hit highlighting for speaking browsers by selecting the
Enter button
Hide highlighting
Abstract (summary)
Translate Abstract
Fraud is a multi-billion dollar industry that continues to grow
annually. Many organizations are poorly prepared to prevent
and detect fraud. Fraud detection strategies are intended to
quickly and efficiently identify fraudulent activities that
circumvent preventative measures. In this paper, we adopt a
DesignScience methodological framework to develop a model
for detection of vendor fraud based on analysis of patterns or
signatures identified in enterprise system audit trails. The
concept is demonstrated by developing prototype software.
Verification of the prototype is achieved by performing a series
of experiments. Validation is achieved by independent reviews
from auditing practitioners. Key findings of this study are: (a)
automating routine data analytics improves auditor productivity

and reduces time taken to identify potential fraud; and (b)
visualizations assist in promptly identifying potentially
fraudulent user activities. The study makes the following
contributions: (a) a model for proactive fraud detection; (b)
methods for visualizing user activities in transaction data; and
(c) a stand-alone Monitoring and Control Layer (MCL) based
prototype. [PUBLICATION ABSTRACT]
Full Text
· Translate Full text
· Turn on search term navigation
Headnote
ABSTRACT
Fraud is a multi-billion dollar industry that continues to grow
annually. Many organizations are poorly prepared to prevent
and detect fraud. Fraud detection strategies are intended to
quickly and efficiently identify fraudulent activities that
circumvent preventative measures. In this paper, we adopt a
DesignScience methodological framework to develop a model
for detection of vendor fraud based on analysis of patterns or
signatures identified in enterprise system audit trails. The
concept is demonstrated by developing prototype software.
Verification of the prototype is achieved by performing a series
of experiments. Validation is achieved by independent reviews
from auditing practitioners. Key findings of this study are: (a)
automating routine data analytics improves auditor productivity
and reduces time taken to identify potential fraud; and (b)
visualizations assist in promptly identifying potentially
fraudulent user activities. The study makes the following
contributions: (a) a model for proactive fraud detection; (b)
methods for visualizing user activities in transaction data; and
(c) a stand-alone Monitoring and Control Layer (MCL) based
prototype.
Keywords: fraud detection, enterprise system, SAP, vendor
fraud, continuous monitoring, audit trails, visualisation, data
analytics
1. INTRODUCTION

According to the Association of Certified Fraud Examiners
(ACFE) Report to the Nations on Occupational Fraud & Abuse,
"a typical organization loses five percent of its annual revenue
to fraud. Applied to the estimated 2011 Gross World Product of
$70.28 trillion, this figure translates to a potential total fraud
loss of more than $3.5 trillion" (ACFE, 2012, p. 8). These
figures are clear evidence that fraud is a major problem, which
requires serious study by researchers to minimize illegal
activities.
There are two principal methods of getting something from
others illegally. They can either be physically forced, or they
can be deceived into giving up their assets. The first type is
called robbery and the second is fraud. Albrecht et al. (2009)
defines fraud as a deception made for personal gain. Deception
is key. The most common definition of fraud according to
Webster's Dictionary (2001, p. 380) is:
Fraud is a generic term that embraces all the multifarious means
which human ingenuity can devise, which are resorted to by one
individual, to get an advantage over another by false
representations. No definite and invariable rule can be laid
down as a general proposition in defining fraud, as it includes
surprise, trickery, cunning and unfair ways by which another is
cheated. The only boundaries defining it are those which limit
human knavery.
The ACFE (2010, p. 6) defines occupational fraud as:
...the use of one's occupation for personal enrichment through
the deliberate misuse or misapplication of the employing
organization's resources or assets...
Occupational fraud is very broad and it encompasses a range of
transgressions by employees at all levels of an organisational
hierarchy. These include: (a) asset misappropriations, which
involve theft or misuse of an organisation's assets; (b)
corruption, in which employees wrongfully use their influence
in business transactions to gain some benefit for themselves or
another person, contrary to their duty to their employer; and (c)
fraudulent statements, which usually involve falsification of an

organisation's financial statements.
Fraud can be committed by anyone. Perpetrators cannot usually
be distinguished from other people on the basis of demographic
or psychological factors. Individuals involved in fraud are
regular people that have compromised their integrity and
become involved in fraud (Cressey, 1953). Several theories
exist in the literature as to why individuals commit frauds. A
common theme in each of the theories is one of conflict of
interest. If this situation arises between the owner(s) and
employees, it may lead to dissatisfaction among employees.
Affected employees may seek relief by resorting to fraudulent
behaviour when an opportunity presents itself (Fama and
Jensen, 1983; Jensen and Meckling, 1976).
Owners incur costs in order to monitor opportunistic behaviour
of employees. By implementing an accounting system, owners
are able to leverage an essential in-built business function of
providing adequate controls to safe guard organisational assets.
An accounting system provides a means of implementing and
improving the internal control structure of an organisation. An
effective accounting system provides an audit trail that allows
frauds to be discovered and makes concealment difficult.
Potential fraud can be discovered in accounting records by
examining transactions that are anomalous or appear otherwise
unreasonable (Albrecht et al., 2009; Romney and Steinbart,
2009).
With advances in information technology and emergence of
electronic business, modem enterprise systems may record
millions of transactions annually. An auditor may extract a
small sample of these during a financial audit. Suppose a
fraudster perpetrates only a few frauds annually, it is plausible
that none of them may be discovered by the financial audit.
Many fraudsters rely on this to conceal fraud. Thus, while
opportunities to commit fraud continue to increase, it appears
that insufficient resources are being deployed to improve
detection using internal controls (Figure 1).
Implementing a well-designed internal control policy enables an

organization to reduce opportunities for employees to commit
occupational fraud. Further reduction in fraud may be achieved
by introducing proactive fraud detection mechanisms that use
computer-based technology (Broady and Roland, 2008) to
monitor and analyze business processes at an "unprecedented
level of detail" (Alles, et al., 2006, p. 138).
This study adopts a Design-Science methodological framework
(Hevner et al., 2004) to answer the key research question: Can a
generalised model for proactive detection of vendor fraud in
enterprise systems be developed? The remainder of this paper is
organised as follows: scope of the study; methodology used;
conceptual model; development of a framework for fraud
detection; approaches for continuous monitoring and fraud
detection; research propositions; level of support enterprise
systems provide for fraud detection; design and development of
automated fraud detection strategies; validation of prototype;
and discussion of some limitations and future research.
2. SCOPE OF THE STUDY
When considering an automated solution for proactive fraud
detection, the focus has to be on questions that can be answered
with the aid of computerised tools (Lanza, 2007). Some
questions are too subjective, for example, Are the vendor's
goods or services of good quality? Any effort to develop an
automated solution will require evidence that is documented in
an enterprise system's audit trails and that can be investigated
using data analytics tools. Transactions that occur outside an
enterprise system cannot be investigated using this
methodology.
The ACFE (2010) classifies occupational fraud into three broad
categories; asset misappropriation, corruption and fraudulent
statements. Asset misappropriation is the most common
category of fraud perpetrated by nonmanagement employees,
occurring in more than 86% of all cases (Table 1). The median
loss from asset misappropriation was $135,000. (Note: the sum
of percentages in Table 1 exceeds 100% because several cases
involved schemes from more than one category).

Asset misappropriation schemes involve theft of cash and non-
cash assets. Cash assets are more frequently targeted than non-
cash assets. Billing schemes was the most common method used
to misappropriate cash assets (26%) having a median loss of
$128,000 (Table 2).
Large scale implementations of enterprise systems have resulted
in many organisations being highly automated and fully
integrated. The development of this enterprise system
environment provides the necessary infrastructure for the
effective evolution of the auditing function from a periodic
event to an ongoing process through the use of computer-based
technology. Enterprise systems software are available from
several vendors, including SAP, Oracle and Microsoft, and
collectively has 71% of market share world-wide. For several
years, however, Germany-based enterprise software company
SAP has consistently been the market leader (Lager and Tsai,
2008; SAP, 2010). In 2010, Gartner (2010) recognised SAP as
the leading vendor of enterprise systems software accounting
for 22% of the market. Many organisations have realised that
SAP solutions are important to their success. Several Fortune
500 companies, including IBM, Toyota, Apple, Coca-Cola, and
Google use SAP exclusively for their core day to day operations
including accounting and financial applications, procurement,
order processing and supplier management, inventory
management, and HR management and payroll functions (BOS,
2009; CMU 2011; Gartner, 2010). The prototype developed in
this research exploits SAP audit trails for proactive detection of
vendor fraud schemes.
The scope of this study is therefore limited to detection of
vendor fraud schemes involving shell companies and non-
accomplice vendors in an SAP enterprise system using
prototype software developed for this purpose. The study makes
no claims to be able to identify any 'actual' fraudulent activities
but is limited to extracting data that provide symptomatic
evidence that fraudulent activities might have occurred.
Throughout this study the term fraud, fraud detection, or fraud

detection tool means potential fraud not actual fraud. In the next
section, we discuss the methodology adopted by this study.
3. METHODOLOGY
This study adopts Hevner et al. (2004) Design-Science
methodological framework. The framework requires creation of
an innovative, purposeful artefact (guideline 1) for a specified
problem domain (guideline 2). Evaluation of the artefact is
crucial (guideline 3). The artefact must be innovative (guideline
4) and rigorously designed and evaluated (guideline 5). It must
enact an effective solution to a problem space (guideline 6) and
results of the research must be presented effectively to both
technology- and managementoriented audiences (guideline 7).
This study adopts the following methodology:
1. Literature review - to recognise theories and concepts that
underpin this study (guidelines 1, and 2).
2. Create a catalogue of fraud symptoms (guidelines 1,2, and 4).
3. Identify data requirements to detect fraud in an SAP
Enterprise System (guidelines 2, 3, 4, and 6).
4. Design, develop, and implement prototype software
(guidelines 1, 2, 4, and 5).
5. Perform experiments to verify program functionality of the
prototype (guidelines 3, 6, and 7).
6. Seek support from experts for validation of the prototype
(guideline 7).
The primary objective of this study is to explore and develop
innovative methods for proactively detecting vendor fraud in
enterprise systems. The intention is to build a model for
detection of vendor fraud based on analysis of patterns or
signatures. This study adopts a methodology for proactive fraud
detection that exploits audit trails in enterprise systems. The
concept is demonstrated by developing a prototype. The aim of
the prototype is to confirm the feasibility of implementing
proactive vendor detection in practice. The prototype is a
software application that analyses transaction data from an SAP
enterprise system for indicators of vendor fraud. Reports and
visualisations highlighting anomalous activities are produced.

Further investigation of these findings may be initiated at the
discretion of an auditor. A conceptual model for the study is
developed in the next section.
4. CONCEPTUAL MODEL
The conceptual model for this study (Figure 2) incorporates
Albrecht et al.'s (2009) essential steps in detecting fraudulent
activities:
* understanding the business or operations.
* performing a risk analysis to identify the types of frauds that
can occur.
* cataloguing the symptoms that the most likely frauds would
generate.
* using computer technology to identify fraud symptoms.
* analysing the results.
* investigating suspicious transactions.
The model represents the fundamental nature of fraud and its
detection. Firstly, the model incorporates factors that motivate
an individual to perpetrate fraud. It identifies mental states that
fraudsters experience prior to perpetrating frauds. A fraudster
may mentally enact several fraud scenarios until a suitable one
is found. Once a fraudster determines what to steal, the next
decision is how to steal it. A fraudster has to determine a
specific method of perpetrating fraud. The chosen method may
entail a series of steps taken to achieve the desired outcome of
perpetrating a fraud and concealing it to avoid detection. The
key concept identified in this part is opportunity. Secondly, the
model focuses on detection of vendor fraud in an organisation.
This is achieved by:
* Creation of a catalogue of fraud symptoms.
* Translation of fraud symptoms into detection strategies that
can be implemented in a prototype.
* Design and development of a prototype.
* Experiments performed with enterprise system data.
The conceptual model provides an understanding of the nature
of fraud symptoms and its detection in enterprise systems.
Fraud is a complex social condition that evolves from

underlying factors such as dissatisfaction or despair. The
eventual outcome is that an individual is motivated to
misappropriate assets that belong to an organisation. In the next
section, we develop a framework for detecting fraud.
5. FRAMEWORK FOR DETECTING FRAUD
Perpetration of vendor fraud may require the creation of a shell
company and the submission of fictitious invoices to an
organisation for payment (Best et al., 2009; O'Gara, 2004;
Wells, 2002a). To successfully perpetrate this type of fraud, the
fraudster needs to access to the following enterprise system
elements (Best et al., 2009; Narayan, 2008; Padhi, 2010):
* Creation or modification of vendor master records.
* Invoice entry sub-system.
Vendor master records can be created or modified in the
following ways (Best, 2008; O'Gara, 2004; Singleton et al.,
2008):
* Create a fake vendor.
* Temporarily modify an existing vendor (flipping).
* Permanently modify an existing vendor.
* Use a one-time account.
Invoices can be entered in an enterprise system in the following
ways (Best, 2005; Singleton et al., 2008):
* Create a fake invoice.
* Use a legitimate invoice.
* Create or use a duplicate invoice.
Key components of the framework for vendor fraud detection
include defining data requirements for fraud detection; and
creating a catalogue of fraud symptoms. The catalogue of fraud
symptoms comprises critical combinations of user activities and
known vendor fraud symptoms.
5.1 Critical Combinations
Many frauds occur because fraudsters exploit the lack of
internal controls or they may override existing internal controls
that are poorly implemented. For example, an employee that
creates or modifies a vendor master record should not be able to
enter an invoice. Having this capability does not indicate that a

fraud has taken place, but it does create an opportunity for fraud
to be perpetrated. By detecting these critical combinations of
user activities:
* an auditor can further investigate transactions that match
known fraud symptoms, or appear otherwise anomalous, and
* an organisation can take steps to correct the situation thereby
reducing the probability of future fraud.
The concept of separating critical business activities in order to
reduce fraud is termed segregation of duties. In its simplest
form, the Segregation of Duties (SoDs) principle states that
sensitive tasks should be divided into two or more steps with
each step being performed by a different user (Li et al., 2007).
This study supports the following principles of SoDs within the
accounts payable function as proposed by Little and Best
(2003):
* SoDs principle 1: users who can create and modify master
records should not be able to post transactions.
* SoDs principle 2: payments should be performed by someone
other than the person who enters vendor invoices.
5.2 Known Vendor Fraud Symptoms
Vendor fraud schemes occur when a fraudster causes an
organization to issue a payment by submitting invoices for
fictitious goods or services, inflated invoices, or invoices for
personal purchases. Activities that violate segregation of duties
are indicators of potential fraud and require further
investigation. These activities may be investigated to determine
whether they match known vendor fraud symptoms, or appear
otherwise anomalous. Methods to detect several known vendor
fraud symptoms are specified in Table 3.
In the next section, we identify and describe two major
approaches to continuous monitoring and fraud detection.
6. APPROACHES FOR CONTINUOUS MONITORING AND
FRAUD DETECTION
Automated fraud detection requires continuous monitoring of an
organisations transaction data. Continuous monitoring increases
the probability of detecting fraudulent activities (Coderre and

Warner, 1999; Potla, 2003). The traditional or manual audit
approach is limited because it reviews only a small percentage
of a large population of transactions. Large accounting data
files with several thousands of transactions are difficult to
analyse or monitor manually in realtime. The alternative
therefore is to automate this process by using information
technology (Broady and Roland, 2008).
Continuous monitoring is a way to provide constant monitoring
and surveillance of transaction data in a real or near real-time
basis against a set of predetermined rule sets (Kuhn Jr. and
Sutton, 2010). It enables auditors to provide a degree of
assurance on information shortly after disclosure (Rezaee et al.,
2002). It is a step in the path of the evolution of the financial
audit from manual to computer-based methods. These systems
analyse data and search for specific patterns or combination of
activities. Potentially fraudulent activities can therefore be
identified shortly after they occur. Widespread adoption of
computer-based accounting information systems in general, and
Enterprise Resource Planning (ERP) systems in particular, has
contributed to the increasing demand for continuous monitoring
(Vasarhelyi et al., 2004). However, presently only 2.6% of
organisations use data monitoring to proactively detect fraud
(ACFE 2010) (Figure 1).
Two major approaches to continuous monitoring exist. These
are Embedded Audit Modules (EAMs), and Monitoring and
Control Layer (MCL).
6.1 Embedded Audit Modules (EAM)
EAMs are software modules that are built into application
programs and are specifically designed to continuously capture
and monitor audit related information (Groomer and Murthy,
1989). If a pre-programmed constraint is violated an alert is
generated, an auditor is informed, and transaction data is saved
in a file (Best et al., 2009; Debreceny et al., 2005; Groomer and
Murthy, 1989; Weber 1999).
Weber (1999) describes EAMs as modules that are placed at
specific points within a system to gather material information

about events or transactions. EAMs are therefore intended to
detect and capture data as transactions are processed in the
enterprise system. When a violation occurs the offending
transaction can either be rejected or allowed and an error is
logged. ERP systems are designed to process transactions
efficiently and promptly. It is therefore not practical to disallow
every offending transaction from being processed. Depending
on the severity of the violation, some transactions could be
conditionally processed whilst others are rejected. The level of
severity of errors that would cause a transaction to be rejected
needs to be negotiated and accepted by the client organisation
(Groomer and Murthy, 1989).
6.2 Monitoring and Control Layer (MCL)
The Monitoring and Control Layer (MCL) introduced by
Vasarhelyi et al. (2004) is an alternative continuous monitoring
and auditing approach to EAMs. MCLs do not replace EAMs,
instead they offer an alternative solution to cater for different
circumstances (Kuhn and Sutton, 2010). In this approach the
continuous monitoring and auditing system is separate from the
client's enterprise system. MCLs are stand-alone systems that
rely on comparisons of extracted transaction data with pre-
determined constraints that allow for continuous monitoring of
systems and identification of violations (Du and Roohani,
2007).
The MCL primarily operates as a discrepancy-based audit
monitoring tool, i.e., audit by exception (Vasarhelyi et al.,
2004). The MCL continuously captures enterprise data and
analyses it to detect any deviations from the norm. When an
exception is detected, it is recorded. It will require further
review by compliance personnel in order to identify the
underlying problem. These further reviews are at the discretion
of internal auditors.
In the next section, the study's research propositions are
developed.
7. RESEARCH PROPOSITIONS
To facilitate answering the study's key research question, the

following research sub-questions and propositions have been
formulated. Each of the propositions directs attention to a
specific issue that needs to be examined within the scope its
research sub-question. The propositions assist in directing the
study towards the desired outcome of answering the primary
research question and proving the conceptual model.
SQ1: How do enterprise systems support proactive detection of
potential fraud in financial transactions?
To answer this research sub-question, three propositions have
been formulated.
RPla: Enterprise system audit trails document adequate data to
allow retrospective monitoring of user activities.
RPlb: Violations in segregation of duties can be identified by
analysing audit trails for critical combinations of user activities.
RPlc: Potentially fraudulent transactions can be identified by
investigating user activities that violate segregation of duties,
match known fraud symptoms, or appear otherwise anomalous.
SQ2: How can detection of potential fraud in enterprise systems
be effectively and efficiently automated to ensure minimal
auditor interaction?
To address this research sub-question, three propositions have
been formulated.
RP2a: Software can be developed to identify potentially
fraudulent activities and report these using an intuitive visual
interface.
RP2b: Threat monitoring and potential fraud detection can be
implemented on a stand-alone external computer system
operating independently of an organisation's enterprise system.
RP2c: Efficiency and effectiveness of the audit process can be
improved by using technology to perform continuous
monitoring of an organisation's enterprise system.
The next section examines the level of support enterprise
systems provide for proactive fraud detection.
8. ENTERPRISE SYSTEM SUPPORT FOR PROACTIVE
FRAUD DETECTION
Audit trails are records of users' activities within an information

system (Best, 2005; NIST, 2005). Audit trails are maintained by
the operating system and applications such as database systems
and enterprise systems (Best et al., 2004). The information
captured in an audit trail is dependent on what events are being
audited by the system (SAP-AG, 2009). In conjunction with
appropriate tools and procedures, audit trails can assist in
detecting fraudulent activities. For example, an audit trail on a
payment of a vendor invoice begins with the receipt of the
invoice. The invoice is tracked through accounts payable, all the
way through to payment in order to settle the debt (Tatum,
2010).
To detect fraudulent activities in an enterprise system, some
fundamental data is required. At a minimum, to detect fraud
schemes listed in Table 3, an MCLbased application will require
access to generic data items that define the event (who, when,
where, and how) as well as specific data items relating to each
scheme. Accordingly, this data should minimally include:
* user name - name of the user that performed the transaction.
* date - that the transaction was performed.
* time - that the transaction was performed.
* computer workstation - that the transaction was performed on.
* transaction performed - the specific transaction that the user
performed (e.g., entering an invoice, posting a payment).
* transaction details - data relating to the transaction performed
(e.g., vendor bank details, invoice amount).
8.1 SAP Enterprise System Audit Trails
SAP audit trails provide detailed descriptions of functions
performed within an enterprise system. Each function in SAP
has a transaction code associated with it. A transaction code (or
tcode) consists of letters, numbers, or both (for example, FB60-
Enter Vendor Invoice). A transaction code is a shortcut that
takes the user directly to a SAP application rather than having
to navigate through the menu system (Padhi, 2010). Each
transaction code executed by a user is recorded in the audit trail
(Best, 2000). The audit trail data required for this study is
stored in several tables within the SAP enterprise system.

Changes to master records are stored in two tables, CDHDR
Change Document Headers, and CDPOS Change Document
Items (Best, 2005; Best et al., 2009; Hirao, 2009; Padhi 2010).
Changes to master records include creation and deletion of
master records and changes to fields. For every change
document number, there is a corresponding change document
item in the CDPOS table.
Accounting audit trails are stored in tables BKPF-Accounting
Document Header, BSEG-Accounting Document Line Item,
SKAT-General Ledger Account Texts, and LFAl-Vendor
General Data. Tables BKPF and BSEG store posting histories
for general ledger, and subsidiary ledger accounts. This
facilitates integration of data and automatic reconciliation of
subsidiary ledgers with reconciliation accounts. General ledger
account texts (names) are stored in table SKAT. Vendor general
data including vendor name, date created and creating user are
stored in table LFA1.
8.2 Identifying Critical Combinations and Known Vendor Fraud
Symptoms
The segregation of duties (SoDs) principles previously
discussed may be detected in SAP by examining tcodes of
functions performed by users. This data allows association of
actions with users'. A list of critical combination of activities a
user has to perform in order to violate each of the SoDs
principles is shown in Table 4. If any of these violations are
identified then further investigation of an offending user's
activities is necessary to determine whether any fraudulent
transactions have been performed.
Given the ability to identify violations in segregation of duties,
it is feasible to detect fraudulent transactions made possible by
these violations. For example, the ability to identify users who
have changed vendor details, entered an invoice and paid the
invoice permits detection of vendor fraud. In addition, further
vendor fraud can be detected through examination of other
anomalous activities (Table 3).
Data describing user activities is well-documented in the audit

trails of SAP enterprise systems. Analysing user activities for
vendor fraud, however, is a difficult task if done manually.
Computer based data analytics can be used to detect fraudulent
activities that have already occurred, as well as determining the
propensity for frauds occurring in the future (Edge and
Sampaio, 2009).
An automated methodology for vendor fraud detection is
proposed and developed in the next section.
9. AUTOMATING FRAUD DETECTION IN ENTERPRISE
SYSTEMS
Modem integrated enterprise systems may record several
thousands of transactions daily. This enormous amount of
transactions makes it difficult to find a few instances of fraud
among legitimate transactions. For large organisations, this
means monitoring hundreds of thousands of transactions and
then investigating suspicious ones in depth at considerable
expense. A concern often raised in the literature regarding
continuous fraud detection systems relates to information
overload (Alles et al., 2006; Alles et al., 2008; Kuhn and
Sutton, 2006). Simple detection of fraudulent activities is
insufficient. Approaches that reduce the burden of excessive
information presented to an auditor are more likely to contribute
to the overall effectiveness of the audit process. One method is
to use visualisation to present information graphically (Fetaji,
2011; Liang and Miranda, 2001). Visualisation is a general term
used to describe any technology that enable users to 'see'
information in order to help them better understand and put it in
an appropriate context (GraphViz, 2010; TechTarget, 2010).
Visualisation tools go beyond the standard charts and graphs,
displaying data in more sophisticated ways such as dials and
gauges, heat maps, tree maps and detailed bar and pie charts.
Patterns, trends and correlations that might go undetected in
text-based data can be exposed and recognised easier with
visualisation. Details on how the prototype addresses these
issues are provided in the next section.
This study proposes a two-phase MCL-based strategy for

detection of vendor fraud in a SAP enterprise system. In phase
one, transaction data is periodically extracted from SAP. Data is
extracted through the SAP data dictionary. The following data
are extracted:
* Change document headers: extracted from table CDHDR to
identify transactions that violate SoDs.
* Change document items: extracted from table CDPOS to
identify Insert (I) changes involving vendors, table LFBK, and
field KEY.
* Accounting document headers: extracted from table BKPF for
documents involving target user and transaction codes
associated with invoices and payments.
* Accounting document line items: extracted from table BSEG
for postings involving target user and accounts payable general
ledger accounts.
* Vendor general data: extracted from table LFA1 for
identifying vendor account information.
Phase two involves the analysis of extracted transaction data by
a software application. This occurs in two stages. Stage one
consists of profiling users to determine whether any violations
in SoDs principles have occurred. In stage two, transactions
processed by these particular users may be investigated by
compliance personnel to determine whether any are fraudulent.
9.1 Prototype Development
A prototype is a partial or simplified implementation of a
complete system (Asur and Hufnagel 1993; Davis, 1992) built
for a specific purpose such as:
* formulating and evaluating requirements, specifications and
designs.
* demonstrating feasibility, system behaviour or performance.
* identifying and reducing risks of system mis-development.
* communicating ideas, especially among diverse groups.
* answering questions about specific properties of proposed
systems (Luqi and Steigerwald, 1992).
Two key advantages for constructing software prototypes
relevant to this study are (Asur and Hufnagel, 1993; Budde and

Züllighoven, 1990):
* to provide users with a 'tangible' idea of the problem solution
being sought after.
* to demonstrate the technical feasibility of a specification.
The prototype is intended to demonstrate that the concept of
proactive detection of vendor fraud is feasible in practice. It is a
limited version meant for showcasing the concept and for
testing purposes only. It produces a combination of user- and
vendor-centric reports and visualisations. A Fraud Analytics
Dashboard provides a high-level overview of activities
performed in the system (Figure 4). Transaction activities are
summarised using pie and bar charts (Figure 5) and link node
diagrams (Figure 6). These presentation methods augment
standard text-based reports produced by the prototype and
support a reduction in information presented to an auditor.
These visualization methods serve to reduce the problem of
information overload by presenting voluminous information
graphically.
9.2 Prototype Verification using Test Data
Software verification and validation is the process of checking
that a software system meets specifications and that it fulfils its
intended purpose. It is a disciplined approach to assessing
software products that strives to ensure that quality is built into
the software and that it satisfies user requirements (IEEE, 2004;
Wallace et al., 1996).
Verification is an attempt to ensure that the product is built
correctly and that the outputs of activities meet specifications
imposed on them during the design phase. Software verification
looks for consistency, completeness, and correctness of the
software and its supporting documentation. Software testing is
one of many verification activities intended to confirm that
software development output meets its input requirements.
Other verification activities may include code and document
inspections, walkthroughs, and other techniques (USDoHHS,
1997).
The prototype is an Expert System intended to support a human

expert in the decision making process. It is based on
computational rules and a knowledge base. The power of the
prototype is in the effectiveness and quality of the knowledge it
contains. To ensure quality, the knowledge base needs to be
verified. Potential problems can be grouped into (Cojocariu et
al., 2005):
* Consistency problems - caused by unnecessary conditions,
redundant or conflicting rules; and
* Completeness problems - caused by missing rules, errors, or
gaps in the inference chains.
Verification of the prototype was achieved by performing a
series of tests using simulated test data involving simulated
activity over a period of one month. Initially, a series of
"manual" experiments were performed on the test data to
establish control values. These experiments were performed
using Microsoft Excel. The same experiments were
subsequently performed using the prototype and the values
produced were reconciled with the control values.
Inconsistencies in results were used to correct errors in the
prototypes computational rules and knowledge base. These tests
served to assess whether the software performed correctly, that
it met the specifications imposed on it, and to provide a
demonstration of the potential use of the prototype.
Additional experiments were performed to determine the
processing capabilities of the prototype.
93 Analysis of Processing Times
A series of experiments were performed to determine whether
the effectiveness and efficiency of the audit process can be
improved by using technology. Experiments were performed
using large and small data-sets. Processing time remained
comparatively constant regardless of the size of the data-set
(Table 5). Transaction data can be extracted, downloaded, and
pre-processed in approximately 40 minutes. An auditor then has
the rest of the working day to analyze the data and conduct
further detailed investigations of users or vendors. These tests
indicate that auditor productivity may be improved when using

the prototype to support the audit process. Independent reviews
and an expert panel demonstration, discussed in the following
section, provide further evidence in support of this conclusion.
9.4 Analysis of Case Study Data using Prototype
Six months of actual transaction data was processed using the
prototype. This data was obtained from a large international
manufacturing company. These tests exposed the prototype to
live data. [Data was also collected on processing times]. A
detailed trace of the processing of this data was generated. The
scope of analysis was as follows:
9.5 Summary of Findings from Case Study
ICT support staff performed functions of normal users including
entering invoices and paying vendors. This situation is not
recommended as it violates normal segregation of duties
principles of: (a) separating users from SAP support functions;
and (b) separating entry of invoices/postings and payment
functions. This poses a considerable fraud risk and requires
review.
Several postings were made using SAP transaction code FB01-
Post Document. It is generally recommended that users not use
FB01 for entry of transactions. This transaction code allows the
user to post any financial transaction including general ledger,
customer, vendor, inventory, or asset transactions. The user
enters a document type (e.g., SA, for GL postings) as part of the
header data and then enters relevant data. Security guidelines
usually recommend that no user be granted access to this
transaction code; rather their profile should allow access to a
set of specific transaction codes associated with their position
(e.g., an accounts payable clerk). This provides proper
segregation of duties.
Several users performed vendor maintenance, invoice entry, and
payment processing activities. These activities violate
segregation of duties principles. Roles of all users that have
performed these activities require review and appropriate
restrictions ought to be applied to their SAP profiles.
Several postings with round dollar amounts were identified.

Round dollar values have a higher probability of being
fraudulent (Wells, 2011, p. 113). These transactions require
review to determine whether they are genuine.
It was observed that several vendors were sharing bank
accounts. These appear to involve vendors with multiple vendor
numbers for the same vendor. These vendors should be
examined to check that they are genuine. There were also
several vendors with multiple bank accounts. These appear to
involve vendors with multiple master records. Duplicate vendor
master records are a potential fraud risk and should be
eliminated. It is recommended that the vendor master file be
periodically cleaned.
Several cases of flipping banking details were observed.
Flipping occurs when a vendor's payment details are
temporarily changed, a payment is made, and banking details
are changed back to the original. This may be indicative of
fraud where the fraudster redirects payments to their personal
bank account. These transactions should be examined by
internal audit to ensure that changes were authorized.
Benford's Law gives expected frequencies of digits in numerical
data. Contrary to belief, digits are not equally likely and are
biased towards lower digits. Benford's Law analysis of the first
two digits for vendor invoices revealed large spikes at 11, 22,
27, 36, 45, 54, and 67. Spikes also occurred at 22, 27, 36, 37,
and 45 for vendor payments. Other smaller spikes were also
observed for invoices and payments. Large spikes are indicative
of potential fraud. These transactions require further
examination to determine whether they are genuine.
9.6 Comments on Findings from Case Study
It should be noted that in organizations with Accounts Payable
sections having small numbers of staff, complete segregation of
duties may not be feasible. These organizations may implement
other compensating manual processes that safeguard against
inappropriate activity. However, SAP support staff roles should
be quite distinct from normal user roles, given they can also
create dummy user accounts. If they run batch jobs to process

large volumes on behalf of users, there should be manual
processes for approving and reviewing these jobs.
The results of the case study analysis require close examination
by internal audit to determine whether these
vulnerabilities/anomalies were actually associated with
fraudulent activities.
In the next section, the prototype is reviewed by independent
auditing practitioners in order to determine that it is the right
product and that it fulfils its purpose.
10. PROTOTYPE VALIDATION
Validation is an attempt to ensure that the right product is built
and that the product fulfils its specific intended purpose.
Validation therefore is the confirmation by examination and
provision of objective evidence that software specifications
conform to user needs and intended uses, and that the particular
requirements implemented through software can be consistently
fulfilled. Validation includes useability testing and user
feedback.
Validation of the prototype was achieved by obtaining
independent reviews from auditing practitioners. In each case,
the reviewer(s) were provided with a summary paper (Singh et
al., 2011), a one-hour presentation, and demonstration of the
prototype. The demonstration involved processing and analysing
using both simulated test data and actual transaction data.
Feedback was requested on the following issues [results are
discussed in Section 10.1]:
a) The importance of such a project for auditing in an
organisation.
b) The role that automated fraud detection software could play
as an auditing tool for internal auditors.
c) The desirability of a retrospective analysis software tool
implemented on a standalone computer system as compared with
a system embedded within an enterprise system.
d) The functionality of the prototype, in particular the user
interface, reporting and graphical features.
e) Further comments or suggestions for improvement to the

Journal of Digital Forensics, Security and Law, Vol. 4(1) .docx

Journal of Digital Forensics, Security and Law, Vol. 4(1) .docx

Recommended

Recommended

More Related Content

Similar to Journal of Digital Forensics, Security and Law, Vol. 4(1) .docx

Similar to Journal of Digital Forensics, Security and Law, Vol. 4(1) .docx (20)

More from priestmanmable

More from priestmanmable (20)

Recently uploaded

Recently uploaded (20)

Journal of Digital Forensics, Security and Law, Vol. 4(1) .docx