International Journal of Accounting Information …...R. Kim et al. International Journal of Accounting Information Systems 27 (2017) 30–54 31 In this paper we ﬁrst provide the

Contents lists available at ScienceDirect

International Journal of Accounting InformationSystems

journal homepage: www.elsevier.com/locate/accinf

A framework for analytics and simulation of accountinginformation systems: A Petri net modeling primer

Rosemary Kima, Jagdish Gangollyb,*, Philip Elsasc

a School of Business, Loyola Marymount University, United Statesb College of Engineering & Applied Sciences, State University of New York at Albany, United Statesc Computational Auditing Inc., Canada

A R T I C L E I N F O

Keywords:Petri netSystem documentationModel of accounting information systemsAnalyticsSimulationVerification of system properties

A B S T R A C T

Accountants have modeled and documented accounting information systems (AIS) throughsystem flowcharts, which have also been used to study internal controls. However, when AIS arelarge, complex, and distributed, their system flowcharts are difficult to comprehend, challengingto use, and insufficient to support decision making in system design and implementation. In thisprimer we propose a set of requirements for modeling and documenting complex AIS that addressthose concerns. Since most other models such as SSAD, UML, and BPMN used to represent AIS areinfluenced by or can be reduced to Petri net models, we compare system flowcharts with Petri netrepresentation of AIS. We evaluate systems flowcharts and Petri nets for their suitability inmodeling AIS. We find that Petri nets are an attractive alternative due to their extensive cap-ability to perform analytics and simulation. Analytics can be used to study structural and be-havioral properties while simulations can help study run-time behavior of systems to evaluatecomputing capacity and system performance. We provide a detailed description and guidelines ofhow design analytics and implementation analytics can be achieved based on the Petri net fra-mework. With this unified modeling strategy, we also describe how it can support the process ofaudit analytics. Petri nets are popular in computer science, engineering, manufacturing, supplychain management, and business process reengineering. We explore this viable method for rig-orous study of AIS modeling and documentation.

1. Introduction

System flowcharts have been used in accounting and auditing since the 1960s to model the flow of documents in accountinginformation systems (AIS). The fundamental concepts underlying systems flowcharts were earlier introduced by Gilbreth and Gilbreth(1921). The systems flowcharts augmented by annotations and narratives provided a smooth transition from the flow of documents toprogramming the control panels on early accounting machines such as IBM 402. Systems flowcharts were initially used to documentAIS, train personnel, and aid auditors in understanding internal controls. Since most AIS were then substantially manual, thedominant view was to study them through the flow of accounting documents.

AIS have evolved over the years to support the growth in volume of transactions handled, velocity of transactions supported,amount of data processed, varieties of datatypes collected, and sources of data including sensors and external entities. Such complexaccounting systems require significant investments and it is critical to minimize errors in AIS. The quality of AIS is likely to besuperior when all relevant information is used to build it. In particular, we highlight the value of design, implementation, and audit

http://dx.doi.org/10.1016/j.accinf.2017.09.002Received 3 November 2016; Received in revised form 6 July 2017; Accepted 27 September 2017

* Corresponding author.E-mail addresses: [email protected] (R. Kim), [email protected] (J. Gangolly), [email protected] (P. Elsas).

International Journal of Accounting Information Systems 27 (2017) 30–54

1467-0895/ © 2017 Elsevier Inc. All rights reserved.

MARK

http://www.sciencedirect.com/science/journal/14670895

https://www.elsevier.com/locate/accinf

http://dx.doi.org/10.1016/j.accinf.2017.09.002


mailto:[email protected]




http://crossmark.crossref.org/dialog/?doi=10.1016/j.accinf.2017.09.002&domain=pdf

analytics in facilitating optimal decisions. Design analytics involves study of the properties and behavior of the system. For example,the design must ensure that each transaction is processed correctly and completely just once while minimizing conflicts of intereststhat increase risks of fraud (see Sections 4.2, 4.3, and 4.4). This can be accomplished through analytics of properties discussed inSection 6 and the suggested research opportunities in Section 10. Implementation analytics, on the other hand, involves the study ofdecisions such as processing capacity, task scheduling, planning, and system performance (see Sections 4.5 and 4.6). This can beaccomplished through either analytical models or simulation as suggested in Section 10. For example, the implementation mustensure that there is sufficient capacity to process the transactions correctly and efficiently based on simulated performance data,which is obtained by load testing the chosen system against demanding scenarios. Performance of analytics in design and im-plementation requires a coherent description of the AIS, which a formal model provides. The unified view provided by the model alsoenables us to support audit analytics by providing a way to express internal control rules and audit procedures. For example, auditanalytics can be performed on logs of transaction processing to verify that control rules are operating as intended, and to detectanomalies and possible fraud (see Section 4.7). While design, implementation, and audit analytics can be performed in the absence ofa formal model, it would be difficult to ensure a unified view of AIS to support accounting and auditing.

To meet the continuing need for high performance and reliability of AIS, we must examine new ways to formally model anddocument accounting systems, going beyond system flowcharts. In order to advance the ways in which systems are modeled, thereare modeling techniques such as structured systems analysis & design, Integration Definition (IDEF), Event-driven Process Chains(EPC), Unified Modeling Language (UML), and Business Process Modeling Notation (BPMN). These methods, as we will discuss inSection 2 are either influenced by or can be transformed into a well-founded model called the Petri net, which is widely accepted inthe study of Discrete Event Dynamical Systems (DEDS). The concept of Petri net was introduced by Petri (1966) in his seminaldissertation on Kommunikation mit Automaten over half a century ago to model DEDS. According to van Hee (1994), AIS are examplesof DEDS. They are discrete event systems because events occur at an instant in time, and only a finite number of transactions canoccur in any given finite time interval. For example, a typical sales system is a discrete event system because a sales transaction occursat a point in time, but the number of sales transactions occurring between any two points in time is finite. AIS are dynamical systemsbecause their state, defined by the status of transactions in processing, changes with time. Continuing with our example, the salessystem is dynamic because between any two points in time, the position of transactions in the processing cycle can change. In thisprimer we compare systems flowcharts with Petri nets for modeling the flow of work in AIS. We choose the former because of theirdominance in current practice, and the latter because most alternative ways of modeling are either influenced by or can be trans-formed into them. We also choose Petri nets because of their sound mathematical foundations, their facility for analytics and si-mulation with software support, and their prominence in modeling in computer science and engineering.

Petri nets have been used extensively in the modeling of computers, communications networks, computer operating systems(Karimov and Moharrami, 2012), manufacturing systems, and in general in the modeling and design of distributed DEDS. In ac-counting, two prior attempts were made to apply Petri nets in the context of internal controls in accounting systems by Verghese(1988) and Chen and Lee (1992), however, they did not gain traction in accounting literature partly because analytics for Petri netswere not as developed then as they are today. Additionally, these studies were heavily focused on the modeling of internal controlsand segregation of duties rather than the broader issues of modeling accounting systems. Later, Krishnan et al. (2005) used BPMNnotation to study internal controls in accounting systems, and Bai et al. (2012) used the same notation to study error propagation andmitigation of risks in accounting systems. While these studies deal with individual business processes, the seminal work of Elsas(1996) presents a top level model of the operating cycle in Petri net framework. Formal modeling makes it possible to verify thecorrectness and ensure reliability of AIS design, and Petri net is an ideal choice since its foundation lies in the mathematical modelingof systems. It also facilitates analytics and simulation. The use of Petri net oriented tools in the design of business information systemsprovides an opportunity to establish a unified model that supports development of information systems for accounting and auditing.Using Petri net minimizes the resources spent on documenting accounting systems and facilitates the use of analytics and simulation.

In this paper we provide a primer especially tailored for researchers in AIS. There are many primers and tutorials for Petri nets(Murata, 1989; Zurawski and Zhou, 1994; Mary Ann Blätke, 2011; Reisig, 2013), but there are no primers that deal specifically withPetri nets in the context of AIS. It is the objective of this primer to fill this void. In this primer we consider lower level businessprocesses for modeling accounting systems. This is appropriate since accounting systems are typically studied through lower levelprocesses and then such details are integrated into a comprehensive AIS model.

Our contributions in this paper include the following. First, we present a comprehensive set of requirements that all AIS modelsshould satisfy in order to be useful for design and implementation. We also describe the criteria and measures that can be used tomeet those requirements. We believe that each requirement presents opportunities for AIS research. The second contribution is inexamining how structural properties of Petri nets can be used to verify correctness of AIS design. Correctness ensures that the systemwill be free from anomalies such as information loss because of attempts to process transactions in excess of system capacity, ortransactions that are hung in their processing. Correctness is a structural property of the system that can be analyzed using well-known Petri net algorithms based on incidence matrices and reachability graphs (see Sections 6.2 and 6.3). Correctness of AIS havenot been explored in the literature, and therefore presents an opportunity for further investigation. Our third contribution is inexamining how Petri net simulation of AIS can be used to gather data to aid in system implementation decisions such as taskautomation as well as hardware and processing capacity. Information relating to tasks in Petri nets can be used to implement modelsof internal control rules such as segregation of duties (SoD) and rotation of duties by developing AIS specific algorithms for as-signment of tasks to people.

R. Kim et al. International Journal of Accounting Information Systems 27 (2017) 30–54

31

In this paper we first provide the rationale for choosing systems flowcharts and Petri nets for comparison in Section 2 and follow itwith a brief historical review in Section 3. In Section 4 of this paper, we propose specific requirements that any model and doc-umentation of AIS should satisfy. In Section 5, we describe how workflows in business processes can be represented as Petri nets, givean accounting example, and develop its mathematical model. In Section 6 we discuss structural and behavioral properties of Petri netsand their significance in the design of AIS. In Section 7 we introduce the workflow net corresponding to the Petri net example inSection 5 and briefly discuss soundness of workflow nets in the context of verifying the accuracy and integrity of AIS design. InSection 8 we briefly discuss how Petri nets have been extended by relaxing the assumptions leading to colored, stochastic, timed Petrinets, etc. Section 9 presents an assessment of systems flowcharts and Petri nets in meeting the requirements presented in Section 4. InSection 10 we discuss how Petri nets provide AIS researchers opportunities to enhance models in computer science and managementscience by incorporating AIS specific constraints. In Section 11 we provide our concluding observations.

2. Rationale for comparing systems flowcharts and Petri nets

Systems flowcharts ranked as the tool most frequently used by practitioners for analysis and design of AIS (Smith and Smith,2003; Bradford et al., 2007), and is the most often used modeling tool for instruction in AIS and auditing courses (Bradford et al.,2007). We use this predominant tool for comparison with alternative methods identified by Carnaghan (2006) which includestructured systems analysis & design (SSAD), Integration Definition (IDEF), Event-driven Process Chains (EPC), Unified ModelingLanguage (UML), and Business Process Modeling Notation (BPMN). For a detailed discussion of the evolution of modeling methods,see Rosemann et al. (2006).

These alternative methods have characteristics that their models can be transformed into Petri nets. Bosilj-Vuksic et al. (2001)suggest ways in which IDEF diagrams can be transformed into Petri nets, and that IDEF diagrams are especially valuable in the earlystages of business process modeling. EPC models which do not have OR-connectors (ie., either or both) can be mapped into Petri netsso that verification of model properties can be performed (van der Aalst, 1999). Such verification is important to ensure the cor-rectness of system design, which we further discuss in Section 4.3. Hu and Shatz (2004) discuss a framework for transformation ofUML models into colored Petri nets, and (Fahland, 2008) present ways to transform activity diagrams created in IBM WebsphereBusiness Modeler into Petri nets. Merseguer and Campos (2004) propose a method for transforming UML statecharts, activity dia-grams, and sequence diagrams into labelled stochastic Petri nets to study the behavior of the system. And finally, Raedts et al. (2007)describe a method for transformation of BPMN models to Petri nets, and then specifying them in the process algebra language mCRL2to perform verification. Fundamentally, all these alternative models can be mapped to Petri nets for verification, analysis, andsimulation; Raedts et al. (2007) describe many of the alternative model transformations in Fig. 1. Since these alternative methods canbe transformed in to Petri nets we use it as an exemplar for comparison with system flowcharts.

3. Systems flowcharts and Petri nets: a brief historical review

The modeling of systems for business processes has advanced from systems flowcharts in the unit record era to the Petri net basedmodels in the web-based systems era. As modeling has become progressively comprehensive in terms of four aspects of informationsystems, viz., function, structure, data, and behavior, Petri net has gained momentum with each stage of development. In the fol-lowing we describe this evolution in three stages.

In the first stage, system flowchart was the dominant technique for modeling business systems. System flowchart is primarilyconcerned with modeling the interactions between functions of the system, and data appear only to clarify such interactions.Structure of the system can not be documented in the system flowchart and it is not possible to study system behavior in the absenceof a formal model. In summary, systems flowcharts emphasize function and data interactions, but abstract away structure andbehavior.

In the second stage, SSAD and IDEF (Yourdon, 2003; Noran, 2004) were the dominant techniques for modeling. Examples of SSADand IDEF models include dataflow diagram (DFD) and entity-relationship diagrams (ERD) respectively. DFDs incorporate data-function interactions and ERDs elaborate the data in DFDs. Leveling of DFDs provide a way of specifying the structure of the system.The coherence and consistency of the system design can be verified by reconciling the DFDs with the ERDs. However, SSAD and IDEFdo not support study of system behavior because of the inability to simulate how the system works. In summary, SSAD and IDEFsupport structure, function, and data, but not behavior.

In the later period of this stage, Unified Modeling Language (UML) was introduced which addressed all four aspects of informationsystems mentioned above (Booch et al., 2007): class diagrams for structure; object diagrams for data; interfaces1 of classes forfunction; activity, sequence, and state diagrams for behavior. The symbols in the diagrams in UML have richer semantics than SSAD,and there is support for simulation primarily to support debugging and validating the system architecture. However, full support wasintroduced in IBM Rational System Architect in the third stage below after the integration of BPMN (Mohlin, 2010).

In the third stage, web-based systems are the prevalent modeling technique. An example is the 3-tier system which consists of afront-end user interface layer, a middle business logic layer, and a back-end database layer. The web-based systems necessitatemodeling of business process workflows so that transaction processing can be controlled. This led to the development of workflowlanguages such as Yet Another Workflow Language (YAWL) and products such as Oracle Fusion. Business process modeling notation

1 Interfaces to classes are defined by member functions in languages such as C++ and Java.


32

(BPMN) and business process execution language (BPEL) were also developed to support such web-based systems. Most of these areeither based on an underlying Petri net model or can be reduced to it (Kalenkova et al., 2014; Wohed et al., 2006; Verbeek and vander Aalst, 2005; van der Aalst, 1998). When these systems are based on the Petri net, they fully support study of structure, function,data, as well as behavior.

Modeling of business processes has advanced from systems flowcharts to more sophisticated modeling that are influenced by Petri nets,which include analysis, design, verification of architecture, debugging, and simulation. On the other hand, modeling of AIS is stilldominated by systems flowcharts. As a result, there is no way to verify correctness of AIS design, simulate its behavior, and thereby collectdata for measuring efficiency of transaction processing. In Sections 9 and 10, we discuss how Petri net can be used to enrich the design ofAIS through analytics and simulation to harmonize the modeling of AIS with the modeling used for business processes.

Fig. 1. Purchase business process Petri net.


33

4. Framework for evaluating AIS models

In developing the framework for evaluating AIS models we adapt Moody and Shanks (1994) framework for evaluating the qualityof data models. His framework consists of four constructs: qualities (desirable properties of a data model), metrics (ways of measuringeach quality), weightings (relative importance of each quality), and objectives (what the designer aims to achieve). In this primer weuse three of his constructs and exclude the construct “weightings” because it depends on the project's scope and the designer'sperspective. The three constructs in our framework are requirements (desirable properties of AIS model), metrics (ways of measuringeach quality), and objectives (what the designer aims to achieve). See these constructs in the first three columns of Table 1.

There are many ways to represent an accounting systems in a model. However, an ideal model must highlight the essential andrelevant features of the system, and help address issues encountered during its analysis, design, and implementation phases.Therefore, our first construct “requirements” addresses these issues encountered. We present seven major requirements: parsimony ofthe model; design of accounting function; processing capacity, task scheduling, and planning; correctness of accounting systems;performance of the accounting system; completeness assertion; and automation of auditing. Each major requirement in turn consistsof sub-requirements that are important to evaluating the quality of AIS or its auditability. Our second construct, objectives, describethe ideal outcomes of design and implementation decisions. For example, for SoD the objective is to minimize such violations byproperly assigning tasks to people. Our third construct is the metric, which is the number of SoD violations observed. Next we discusseach of the requirements in detail. Later in Section 9 we compare the systems flowcharts with Petri nets for modeling and doc-umentation of AIS using the three constructs described above.

4.1. Requirement 1: model should be parsimonious

The first requirement is that any system documentation should use minimum number of symbols required to adequately expressthe flow of transactions through their processing. Too many symbols and annotations in documentation impose a cognitive burden onthe designers and users. Using minimal number of symbols makes it easier to understand, analyze, and use the system. As the systemgrows in size so does the documentation, causing difficulty in comprehension. The documentation of an accounting informationsystem, even for a relatively small process, can run into dozens of pages and so manually identifying the internal controls can be adaunting task when a large number of symbols are used. Therefore, the objective should be to minimize number of symbols used inmodeling. The metric for measuring parsimony of symbols is the actual number of symbols used in the model.

4.2. Requirement 2: model should support analytics for design of accounting function

The system model should aid in the design of the accounting function. This consists of four sub-requirements (2.1–2.4 of Table 1):assignment of accounting tasks to people (or programs), rotation of duties, segregation of duties, and assignment of tasks to eithermanual or program mode. Assignment of tasks to people and rotation of tasks that people perform are two fundamental ideas inauditing (Dicksee, 1905).

First, it is critical that every task in the accounting system be assigned either to a person or a program so that accountability isestablished and use of resources are optimized. The objective is to minimize the number of unassigned tasks so as not to wasteresources, and relevant metric is the number of tasks unassigned. The risks of improper assignment of tasks to people includeinefficient use of people and skills and non-compliance with SoD rules. Second, from the internal control standpoint, it is critical torotate duties without violating SoD rules. Such rotation is especially important when it relates to custody or authorization. Theobjective here is to minimize the number of SoD violations, and the relevant metric is the number of such violations. Risks ofimproper rotation of duties include violation of SoD or internal control rules that can lead to fraud.

Third, the objective is to design accounting information system such that it has minimum number of SoD violations, the relevantmetric being the number of violations. If it is not possible to eliminate SoD violations in the design, then it is important thatcompensating controls be adopted and related violations be monitored. Risk of not verifying compliance with SoD include violationsof company policy and fraud due to collusion. Fourth, the decision whether a task should be performed by people or by programsmust be based on factors such as the differences in cost, availability of relevant skills, tolerable error in transaction processing, andthe latencies in transaction processing. The objective here is to choose the alternative which minimizes cost, and the metric is the costof manual or automated activity. The risk of improperly designating tasks as manual or automated include inefficient use of re-sources. Overall, to meet this requirement the system model and its documentation should aim to provide data and support devel-opment of algorithms for design decisions.

4.3. Requirement 3: model should support analytics for the correctness of AIS

The first sub-requirement is that for an accounting system design to be correct, it should ensure that transactions are executedfully and committed to the database. For this to be accomplished, the accounting system must avoid anomalies and have certaindesirable properties. The anomalies include redundancy, hung tasks, and deadlocks. Redundant tasks make an accounting systeminefficient because they consume resources that can be utilized in more productive ways. Hung tasks can prevent a transaction frombeing executed fully. Deadlocks freeze the execution of transactions so that the whole accounting system comes to a halt.

The second sub-requirement is that their design must reflect desirable properties such as boundedness, safeness, and reversibility.Boundedness ensures that the transactions do not exceed the buffers set up in the system because when they do exceed, errors can


34

Table1

Req

uiremen

tsformod

elsof

AIS.

AIS

mod

elrequ

irem

ents

Objective

sformod

elrequ

irem

ents

Metrics

forev

alua

tion

ofmod

els

Evalua

tion

ofsystem

flow

charts

Evalua

tion

ofPe

trine

ts

1.Mod

elshou

ldbe

parsim

onious

Minim

izethenu

mbe

rof

symbo

lsNum

berof

symbo

lsMan

ysymbo

lsTh

reesymbo

ls

2.Ana

lyticsof

design

ofthe

accoun

tingfunctio

n2.1Assignm

entof

tasksto

peop

leMinim

izenu

mbe

rof

unassign

edtasks

Num

berof

unassign

edtasks

2.1,

2.2,

2.3,

2.4Accom

plishe

dman

ually

2.1,

2.2,

2.3Algorithm

scanbe

deve

lope

dto

perform

assign

men

t,rotation

,and

segreg

ation

2.2Rotationof

duties

Minim

izenu

mbe

rof

SoD

violations

dueto

rotation

sNum

berof

SoDviolations

due

torotation

s2.3Se

greg

ationof

duties

(SoD

)Minim

izeSo

Dviolations

Num

berof

SoD

violations

2.4Ta

sksdo

neman

ually

orby

prog

ram

Cho

osethede

cision

tominim

izeco

stof

man

ualor

prog

ram

activity

Costof

man

ualor

prog

ram

activity

2.4Accom

plishe

dman

ually

3.Mod

elshou

ldsupportan

alyticsof

thecorrectnessof

AIS

3.1Ano

maliesof

AIS

(Red

unda

ncies,hu

ngtasks,an

dde

adlocks)

Detectan

omalies

Absen

ceof

anom

alies

System

flow

charts

dono

tsupp

ort

detectionof

anom

alies

4.1,

4.2Ana

lyticalcapa

bilitiesof

Petrine

tsen

able

detectionof

anom

aliesan

dprop

erty

violations

3.2Prop

erties

ofAIS

(Bou

nded

ness,

safene

ss,r

eversibility,

and

soun

dness)

Verifytheprop

erties

Presen

ceof

prop

erties

Prop

erties

ofAIS

canno

tbe

expressedin

system

flow

charts

andtherefore,

prop

erty

violations

canno

tbe

detected

4.Mod

elshou

ldsupportan

alyticsfor

thecompletenessassertion

4.1Con

trolsrelating

toco

mpleten

essassertion

Ade

quateco

ntrols

over

completen

ess

Deg

reeof

controlov

erco

mpleten

ess

Evalua

tion

ofco

mpleten

ess

controls

canbe

acco

mplishe

dman

ually

Evalua

tion

ofco

mpleten

essco

ntrols

canbe

canbe

performed

withPe

tri

nets

atruntime

4.2Integrationof

controls

withthe

econ

omic

mod

elAde

quateintegrationof

controls

andecon

omic

mod

elDeg

reeof

integrationof

controls

andecon

omic

mod

elIntegrationof

controls

withinthe

econ

omic

mod

elis

notpo

ssible

sinc

ethequ

antitative

controls

cann

otbe

expressedin

system

flow

charts

Theecon

omic

mod

elcanalso

beexpressedas

aPe

trine

tan

dtherefore,

theintegrationof

the

econ

omic

mod

elwiththede

sired

quan

titative

controls

ispo

ssible

5.Mod

elshou

ldsupportan

alyticsof

processing

capa

city,task

schedu

ling,

andplan

ning

5.1Iden

tify

themosteffi

cien

tway

oforga

nizing

thework

Paralle

lizetasks,sync

hron

ize,

choreo

grap

hbu

sine

ssproc

esses

Ave

rage

timeto

commit

tran

sactionto

databa

se,idle

timeof

tran

sition

s,an

dnu

mbe

rof

tran

sactions

completed

perun

ittime

Diffi

cultto

visualize

paralle

lizationwhe

nflow

charts

arelarge

Easier

toch

oreo

grap

htran

saction

proc

essing

dueto

supe

rior

grap

hical

andan

alytical

capa

bilitiesof

Petri

nets

(con

tinuedon

next

page)


35

Table1(con

tinued)

AIS

mod

elrequ

irem

ents

Objective

sformod

elrequ

irem

ents

Metrics

forev

alua

tion

ofmod

els

Evalua

tion

ofsystem

flow

charts

Evalua

tion

ofPe

trine

ts

5.2Assessco

mpu

ting

capa

city

need

edMinim

umco

mpu

tercapa

city

tope

rform

alltasks

Floa

ting

pointsop

erations

per

seco

nd(FLO

PS)

Not

possible

tosimulatewitho

utbu

ildingan

inde

pend

entmod

elCom

puting

capa

city

canbe

estimated

throug

hsimulation/

anim

ationof

Petrine

ts5.3Determinetasksthat

need

tobe

executed

inreal-tim

ean

dwhich

canbe

batche

d

Balanc

eco

stsof

hardware,

max

imum

backlogtolerated,

andco

stof

buffersto

hold

data

Costof

performingthetasks

Not

possible

todirectly

determ

ine

bottlene

cksin

theproc

essing

oftran

sactions,to

decide

batchvs.

real-tim

e

Simulationof

thePe

trin

etprov

ides

inform

ationon

tran

saction

backlogs,w

hich

canbe

used

tode

term

inereal-tim

evs.b

atch

proc

essing

5.4Ev

alua

tewha

thu

man

resources

arerequ

ired

toop

eratethe

compu

teren

vironm

ent

supp

orting

theacco

unting

system

Minim

izeco

stof

human

resourcesforrunn

ing

compu

ting

environm

ent

Costof

human

resourcesto

runtheco

mpu

ter

environm

ent

Diffi

cultto

estimatehu

man

resourcesrequ

ired

toop

eratethe

compu

ting

environm

entdirectly

from

system

flow

charts

Simulationof

thePe

trine

tcan

prov

ideinform

ationon

human

resourcesrequ

ired

torunthe

compu

ting

environm

ent

6.Mod

elshou

ldsupportan

alyticsof

AIS

performan

ce6.1Su

pportproc

urem

entde

cision

sforha

rdwarean

dsoftware

Minim

izetotalco

stof

hardwarean

dsoftware

Totalco

stSy

stem

flow

charts

dono

tsupp

ort

simulations

ofop

erations

foran

yha

rdware/softwareco

nfigu

ration

Petrine

tsimulationof

alternative

hardware/softwareco

nfigu

ration

canprov

ideda

teto

supp

ort

proc

urem

entde

cision

s6.2Sy

stem

performan

ceEstimatesystem

performan

ceEstimates

oftran

saction

volumes

supp

ortedan

dtran

sactionba

cklogs

byusing

simulationstatistics

Sinc

eon

ecanno

tdirectly

simulatefrom

system

flow

charts,

system

performan

cecanno

tbe

stud

ied

System

performan

cecanbe

estimated

throug

hsimulationof

Petrine

ts

7.Mod

elshou

ldsupporta

nalyticsan

dau

tomationof

auditin

g7.1Com

pile-tim

eve

rification

ofinternal

controls

Minim

izeviolations

for

compile-tim

eStatistics

onviolations

inco

mpile-tim

eCom

pile-tim

eve

rification

ofco

ntrols

ispe

rformed

man

ually

,as

itiscu

rren

tlydo

neby

auditors;

howev

er,itcanno

tbe

automated

7.1,

7.2Bo

thco

mpile-tim

ean

drun/

execution-timeve

rification

ofinternal

controls

arepo

ssible

with

automationusingPe

trine

ts7.2Run

/Execu

tion

-tim

eve

rification

ofinternal

controls

Minim

izeviolations

forrun/

execution-time

Statistics

onviolations

inrun/

execution-time

Run

/execu

tion

-tim

eve

rification

canon

lybe

done

man

ually

,asitis

curren

tlydo

neby

auditors;

howev

er,itcanon

lybe

automated

inba

tchmod

e


36

occur in transaction processing. Safeness ensures that only one transaction can be processed at a time. Reversibility ensures that atany stage in transaction processing, there is a way to get back to the original point of transaction; this is important if a partiallyprocessed transaction needs to be rolled back or cancelled. In the context of workflows, soundness is another desirable propertywhich ensures accuracy and integrity as discussed in Section 7. The objective of accounting systems design should be to eliminate allanomalies and to ensure that all the desirable properties of AIS manifest in the design. If the model used to design the accountingsystem is also used for execution of transactions, then the correctness of the design should ensure the correctness of execution. Such amodel will provide a detailed template for transaction processing as well as all controls embedded in its design. The metrics for thedesirable anomalies and properties discussed above are expressed in binary variables: their presence or absence. The choice of adesign is based on the absence of anomalies and presence of every desirable property.

4.4. Requirement 4: model should support analytics for the completeness assertion

The system model must aid in gathering and providing evidence to test the completeness assertion. This includes the two sub-requirements: completeness of evidence gathering from internal and external sources, and completeness in the sense of reconciliationof such internal and external evidence with the economic model.

The importance of capturing and recording internal accounting information as well as external independent evidence has beenemphasized by Carmichael (2004). Completeness of evidence gathering is important since externally generated evidence is becomingpervasive. For example, in case of lockbox arrangements, examination of completeness includes reconciliation of lockbox data andthe internal accounting data. The controls that need to be incorporated in the system model include segregation of duties, properauthorization, and other accounting controls.

Completeness also involves reconciliation of internal and external data with the economic model, which ensures that the data isconsistent with the expectations of the economic model (Weigand and Elsas, 2012). For example, in the hotel industry a control mightbe that total profit should equal the product of number of units rented and profit per unit, where units rented is based on theoccupancy captured by sensors in the room. The accounting system must reconcile the occupancy data from sensors with the oc-cupancy data generated by the revenue system in order to test the completeness assertion for revenue recognition. If no revenue isrecorded when the sensor data indicates occupancy, then the revenue is deemed incomplete. On the other hand, if revenue isrecorded when the sensor data shows no occupancy, then there is possibility of money laundering. The objective of this sub-re-quirement is to ensure that the accounting system data is reconciled with what the economic model predicts.

4.5. Requirement 5: model should support analytics for processing capacity, task scheduling, and planning

The four sub-requirements (3.1–3.4 of Table 1) are identifying the most efficient way of organizing the flow of work, determiningthe computing capacity needed, assessing which tasks need to be executed in real-time vs. batched, and estimating the humanresources required to operate the accounting system.

The model of AIS must support analytics for these four sub-requirements. The answers can be based on the study of the behaviorof the system designed, either through analytics of its properties or through simulation. First, business processes need to be orche-strated through parallelization of tasks which are synchronized so that the work is efficiently organized. This is a task commonlycalled business process re-engineering. For this to be accomplished, the model representing accounting systems must facilitate si-mulation of the system in order to continuously improve the design of the system. This activity is similar to engineers building a scalemodel and testing it to improve the design. The efficiency of design can be measured by thru-put of the system, efficient use oftangible system resources, and quality of service provided by the design (Pitt et al., 1995). The metrics that can be used for thru-putinclude average time to commit a transaction to database, number of transactions completed per unit time. The metrics for efficiencyof use of tangible system resources include idle time for transitions and unused data storage capacity. The metrics for quality ofservice can include responsiveness measures such as latency in processing transactions. The choice of the design for implementationdepends on trade-offs between these measures of thru-put, efficiency of tangible resources, and the tolerable responsiveness.

Second, to estimate computing capacity, one can simulate the operations of the system based on transaction volumes andmaximum tolerable processing backlog. Such capabilities are already available for information systems in medicine (Höhne, 2013).The metric for computing capacity that can be used is floating point operations per second (FLOPS), and the metric for data storage isbytes of storage. The choice of design for implementation is based on minimizing the cost of the system. Third, the decision betweentasks to be done in real time and those to be batched involve balancing the costs of hardware, maximum backlog tolerated, and thecosts of buffers to hold the data. The metric here is the cost of performing the task, and the choice of design for implementation isbased on minimizing the total cost of the system. Fourth, once the above questions are answered and the hardware/software con-figuration are chosen, one can estimate the labor requirements to support the computing environment. The relevant metric is the totalcost of labor.

4.6. Requirement 6: model should support analytics of AIS performance

The first sub-requirement is that the system model should support analytics and simulation to aid in hardware/software pro-curement decisions as well as in the choice of lowest cost system configuration based on operating performance. The former involves


37

analysis of system simulations for procurement alternatives. The latter involves cost/performance comparison of available hardware/software configurations for assumptions of transaction volume, density, and tolerable transaction backlog. The choice of systemconfiguration therefore involves gathering data on system performance through simulation and then determining the efficient costconfiguration. The metric to use for this requirement is the total procurement cost of hardware and software. The simulation resultscan also be used to establish norms for evaluating the implemented system. The ability to perform rigorous analysis and simulateperformance is important for accounting systems because investments are substantial and reliable performance is critical.

4.7. Requirement 7: model should support analytics and automation of auditing

Auditors examine if the AIS has both static and dynamic internal controls, which are the basis for our two sub-requirements. Staticcontrols ensure integrity of design whereas dynamic controls ensure integrity of transaction execution. Static internal controls areintegrated in the design of AIS to ensure proper authorization of transactions and application of SoD. The auditor's examination ofstatic controls is referred to as compile-time verification. Our first sub-requirement is that AIS model should support compile timeverification. Dynamic controls on the other had enforce accurate processing of transactions for authorization and SoD duringtransaction processing. To prevent any disruptions in the course of business, some duties may be reassigned on the fly to a differentemployee because the assigned personnel is unavailable. Such deviation from static controls are detected during transaction pro-cessing. The auditor's examination of dynamic controls is referred to as run-time or execution-time verification. Our second sub-requirement is that AIS model should facilitate run-time verification.

Run-time verifications can be performed either in real-time as the transactions are processed, or periodically by examining thelogs of such transactions processed. The advantage of performing this verification in real-time is that internal controls can be enforcedas the transactions are being processed, resulting in greater system integrity. Periodic verification of run-time controls is a forensicexercise since such verification based on analysis of transaction logs performed after the violations have already occurred and so isdetective in nature while real-time verification of controls on the other hand can be preventive in that violations are avoided. Forexample, in the processing of a transaction if an employee tries to approve a document that she had prepared, run-time SoD controlscan detect the violation, suspend the transaction, and present the transaction for independent review. Such run-time verification ofcontrols is of critical importance in large and complex accounting systems. The metrics for both compile-time and run-time ver-ification are the number of violations of internal controls, and the objectives are to minimize such violations.

Both compile-time and run/execution time verification depend on the specification of conflict-of-interest and other business rules.Run/execution time verification of transactions yields data that itself can be subject to analytics to determine rule-compliance as wellas determination of thresholds for control rules. For example, if the run/execution verification logs indicate frequent violation of SoDrules, the cause may be due to way in which the rules are designed, the way tasks are assigned to people, or personnel shortages thatlead to rules being compromised. One use of audit analytics can be to perform analysis of run-time verification log data to identifysuch anomalies.

In the above discussions we have presented our requirements for the model of AIS to best meet the needs of designing complexand distributed AIS. This includes facilitating: parsimony in modeling, design of accounting function, verification of system design,completeness assertion, decision on processing capacity, system performance, and automation of auditing. In the next section, weexamine an alternative way of modeling, called Petri net, which has been used extensively to model distributed systems. We describethe evolution of Petri net and how the modeling methodology can be used to represent business processes (van der Aalst and Stahl,2011a) and design of accounting systems.

5. Business processes as Petri nets

A business process is a collection of activities or tasks all of which must be performed in order to achieve a specific goal. Each taskin the business process has certain pre-conditions which must be satisfied for the task to be initiated, and the completion of a tasksignifies the post-condition of a subsequent task. When the precondition for the first task is satisfied, the business process is initiated,and when all the tasks in the business process have been performed it is terminated. Therefore business processes have a definitebeginning and ending. Business processes can be represented as Petri nets where symbols used refer to pre or post-conditions, tasks,and the flow of information. Business processes lack mathematical basis to analyze their structural and behavioral properties, and theadvantage of representing business processes as Petri nets is that we can exploit their analytical and simulation capabilities to studythe structural and behavioral properties of AIS. In this section we define a Petri net, give an accounting example of a business processrelating to purchase transactions, provide a graphical representation of the Petri net, and formalize the example as a Petri net. Finallywe discuss how complex accounting systems can be built by composing basic patterns of tasks, pre/post-conditions, and informationflows. The structural and behavioral properties of AIS in the context of Petri nets are discussed in Section 6.

A Petri net is a bi-partite graph consisting of a set of information flows and two types of nodes: places (P) and transitions (T)connected by information flows. Places are buffers that store information in the system and are denoted by circles. Places hold tokenswhich represent information. The tokens represent data objects such as a purchase order that is represented as a tuple in a relationaldatabase or an object in object-oriented database, and is represented by a bullet (large solid dot). Transitions are tasks such as‘approve purchase order’ which are represented by solid bars. The information flows consist of input and output flows which arerepresented by arrows or directed arcs. Input flows are directed arcs from places to transitions, and output flows are directed arcsfrom transitions to places. A Petri net therefore depicts the processing of transactions by transitions utilizing information in theirinput flows. In a Petri net, information flows are not allowed between any two places or between any two transitions. Transitions are


38

the only active components while the places are inactive components. The state of the system in a Petri net is represented the locationof tokens in places. The places immediately preceding a transition are called its pre-conditions, and the places immediately succeedinga transition are called its post-conditions. Each arrow in a Petri net has a weight. A transition is said to be enabled if for every pre-condition, the number of tokens exceeds the weight of the corresponding arrow. A transition can be fired only if it has been enabled.A transition when fired, accepts tokens from its input places, transforms such input tokens into output tokens, and places the outputtokens in its output places. This kind of a network is also referred to as State-Transition net (or S/T net). We illustrate a Petri net for apurchase system in Section 5.1.

The above description of a Petri net forms a good metaphor for an accounting system. In manual accounting systems the work isperformed by a set of people each of whom has an input tray and output tray. The work performed consists of taking the contents ofthe input tray, transforming them into outputs and putting them into the output trays. The flow of information from person to personis facilitated by a mail system that delivers such work from person to person. The trays form the buffers in the manual system; theypermit the smooth functioning of the whole system by balancing the workloads of the people in the system. It is the job of the systemsdesigner, by choosing buffer capacities and transitions, to design an optimal accounting system. In the Petri net terminology, the traysare places, the persons are transitions, and the mail systems are arrows.

5.1. An accounting example: purchase system

We now provide in Fig. 1 a simple illustration of a Petri net for a purchase system2. It describes a business process where apurchaseRequisition (p1) is processed to produce a purchaseOrder (p6, p7, and p8) up to the last task when a check is sent tothe vendor checkToVendor (p14). The various activities (transitions or solid bars) as well as the states (places or circles) in Fig. 1 areannotated, and all arrows have weights of 1. In this paper we present one business process for study since most accounting in-formation systems are usually designed one process at a time. Then, issues of synchronization of interacting business processes, andtheir choreography are usually undertaken in the real world at the systems integration phase.

When a purchase requisition (p1) has one token, it enables the transition distributePR (t1) which when fired yields twoparallel flows resulting in a token each in unapprovedPR for department manager (p2) (for budget) and unapprovedPR for pur-chasing manager (p3). A token in p2 enables the transition review & approve purchase requisition (t2), when fired leads to a token inapprovedPO (p4). Similarly, a token in p3 enables the transition review & approve purchase requisition (t3), when fired leads to atoken in approvedPO (p5). The two parallel activities of the department and purchasing managers are synchronized by the transitiondistributeApprovedPO (t4), which is enabled when there is a token each in p4 and p5. When transition t4 is fired, three copies ofthe purchase order are transmitted by placing a token each in vendor PO (p6), receiving department PO(Qty) (p7), and accountingdepartment PO (p8) for matching the documents when the goods are received.

A token in p6 enables the transition sendPOtoVendor (t5) which when fired results in placing a token each in billOfLading(p9) and vendor Invoice VI (p10). When p7 and p9 have a token each, the transition prepareReceivingReport (t6) is enabled, andwhen fired, puts a token in the receiving report RR (p11). When the goods are received and there is a token in each of the places p8,p10, and p11, the transition matchPO,RR, & VI (t7) is enabled. When t7 is fired, a token is put in unapprovedPaymentVoucher(PV) (p12). When there is a token in p12 the transition approveVendorInvoice (t8) is enabled, and when fired places a token inapprovedPV (p13). This leads to issuePayment (t9) resulting in checkToVendor (p14) and finally mailToVendor (t10), whichplaces the token back in the initial position p1. In this description, a purchase transaction is initiated when a purchase requisition (p1)is prepared, and ends when the check to the vendor (p14) is ready. The transition mailToVendor (t10) is added in order to completethe transaction processing cycle and to study its structural and behavioral properties as a Petri net.

5.2. Development of the mathematical model for Petri net

In this subsection, we express the mathematical model for a generic business process as a Petri net, and then in Section 5.3 expressthe mathematical model for the purchase system in Fig. 1 as a Petri net.

Consider a business process whose Petri net is represented by ℬ. We define the Petrinet ℬ as a quintuple {P,T,F,ω,μ0}, where

1. P a set of places2. T a set of transitions, such that P ∩ T=Φ and P ∪ T≠Φ, ie., places and transitions are distinct sets.3. a set of information flows defined by the mapping

⊆ × ∪ ×F P T T P( ) ( ) (1)

4. a set of weights ω defined by the mapping

�→ +ω F: (2)

where �+ is the set of positive integers. The weights are sometimes referred to in the literature as cardinalities or multiplicities. Seechapter 5 on “Simple Petri nets” Zimmermann (2008).

2 In this description we use typewriter fonts for places and transitions.


39

5. an initial marking, a vector consisting of the tokens in places in the Petri net, given by

= … …μ μ μ μ μ[ ]i P1 2 | | (3)

where |P| is the cardinality of the set P.

We now provide a brief discussion of concepts needed to perform analytics of Petri nets. We define information flows alternativelyin terms of the information flows immediately preceding a transition, which we call input flows or pre-conditions, and informationflows that immediately succeed a transition, which we call output flows or post-conditions. For any transition t ∈ T we define its pre-conditions (•t) as the set of places p such that there is a directed arc (p,t) ∈ (P×T), and similarly post-conditions (t•) as the set ofplaces p such that there is a directed arc (t,p) ∈ (T×P). In other words,

= ∈ ∈ ×t p P p t P T• { |( , ) ( )} (4)

= ∈ ∈ ×t p P t p T P• { |( , ) ( )} (5)

The set of all input (I) and output (O) flows in a Petri net can be defined as

= ⋃∈

I t•t T (6)

and

= ⋃∈

O t•t T (7)

The information flows in the above formulation can be represented mathematically in an incidence matrix C constructed bydefining each element in it as follows:

=⎧

⎨⎩

∈ ∉− ∈ ∉c

p t p tp t p t

1 if • and • ,1 if • and •,

0 otherwise.ij

i j i j

i j i j

(8)

5.3. Formalization of the accounting example

We now formulate the model for Fig. 1 using the formalism in the previous subsection. The Petri net for the accounting example isgiven by A = P T F ω μ{ , , , , }0 , where

1. P={p1,p2,p3,p4,p5,…,p13,p14}2. T={t1,t2,t3,t4,p5,…,p9,p10}, such that P ∩ T=Φ and P ∪ T≠Φ3. a set of information flows defined by the mapping

⊆ × ∪ ×F P T T P( ) ( ) (9)

where the set of all input (I) and output (O) flows are given by

= ⋃ =∈

I t p t p t p t p t p t p t p t p t p t p t p t p t

p t p t

• {( , ),( , ),( 3, ),( , ),( , ),( , ),( , ),( , ),( , ),( , ),( , ),( , ),

( , ),( , )}t T

1 1 2 2 3 4 4 5 4 6 5 7 6 8 7 9 6 10 7 11 7 12 8

13 9 14 10 (10)

and

= ⋃ =∈

O t t p t p t p t p t p t p t p t p t p t p t p t p

t p t p

• {( , ),( , ),( , ),( , ),( , ),( , ),( , ),( , ),( , ),( , ),( , ),( , ),

( , ),( , )}t T

1 3 1 2 2 4 3 5 4 6 4 7 4 8 5 9 5 10 6 11 7 12 8 13

9 16 10 1 (11)

yielding the information flows F in our purchase example given by

= ∪ =F I O t p t p t p t p t p t p t p t p t p t p t p t pt p t p p t p t p t p t p t p t p t p t p t p t p tp t p t p t

{( , ),( , ),( , ),( , ),( , ),( , ),( , ),( , ),( , ),( , ),( , ),( , ),( , ),( , )( , ),( , ),( 3, ),( , ),( , ),( , ),( , ),( , ),( , ),( , ),( , ),( , ),( , ),( , )}

1 3 1 2 2 4 3 5 4 6 4 7 4 8 5 9 5 10 6 11 7 12 8 13

9 16 10 1 1 1 2 2 3 4 4 5 4 6 5 7 6 8 7 9 6 10 7 11 7

12 8 13 9 14 10 (12)

4. a set of weights ω shown on each information flow in Fig. 1. Since each information flow has weight 1, the vector of weightsdefined in the mapping �→ +ω F: is the unit vector of dimension |F|.

5. an initial marking, a vector of dimension |P| where the first component is set to 1 and all other components are set to zero, given by

=μ [1 0 0 0 0 0 0 0 0 0 0 0 0 0]0 (13)


40

5.4. Basic patterns in business processes

The principal objective of AIS is to shadow business processes in order to exercise control over them. It is therefore important thatany system for their documentation be able to handle issues of concurrency and synchronization that characterize the coordination inmost business processes. Those issues can be catalogued into certain patterns that form basic building blocks of any concurrentsystem. Fig. 2 illustrates six such patterns based on example in Fig. 1: action (A), sequence (B)), parallel split (C), merge of concurrentsystems (D), concurrency (E), and synchronization (F). While action and sequence are the basic patterns, the other four are needed forthe choreography of business processes. Parallel split and synchronization are needed for the initiation and termination of parallelprocesses. Figs. 1 and 2 depict that synchronization and merge of concurrent systems are similar except that the former terminatesone set of parallel activities and initiates another.

In the extant literature Jensen and van der Aalst (2009) suggest two additional patterns, illustrated in Fig. 3. In exclusive choice(G) the place has two output arcs that are mutually exclusive in that only one of them can be realized so that only one of thetransitions can be enabled, depending on a condition. Exclusive choice makes a business process non-deterministic (Gold, 2004).Nielsen and Thiagarajan (1984) refer to this as situation of conflict or non-determinism. Simple merge (H), on the other hand, is similarto merge of concurrent systems. For instance, the system in Fig. 1 can be altered to include the simple merge pattern by inserting aplace just prior to match PO, RR, and VI to replace places p8, p10, and p11. van der Aalst et al. (2003) list a much richer varieties ofpatterns. Petrinets with such patterns do not pose any problems in analysis, but they are beyond the scope of this paper. A system of

Fig. 2. Basic patterns in a business process.


41

arbitrary size can be built by combining these eight patterns which are the basic building blocks.

6. Properties of AIS as Petri nets

Petri nets, as a formalism, derives its power and usefulness in the context of AIS through its rigorous mathematical foundation inbipartite graphs and linear algebra. Such a foundation makes analytics and simulation possible. Its affinity to well studied models ofnetworks and optimization under constraints (integer linear programming) makes it an ideal tool for the study of AIS as discrete eventsystems. In Section 6.1 we will introduce the execution semantics of Petri nets which is important to the simulation of accountingsystems as dynamical systems and the study of the properties of AIS. This is followed in Section 6.2 by a brief discussion ofreachability graphs which are useful in the study of some of the behavioral properties (boundedness, safeness, liveness, and dead-locks) of AIS as Petri nets. Section 6.3 defines the structural properties of place-invariants and transition-invariants, two importantconcepts in the study of Petri nets based on their matrix formulation. In Section 8 we discuss extensions by imposing structure onPetri nets (heirarchical Petri nets), making tokens distinguishable (colored Petri nets), permitting types of arcs (such as inhibitor andreset arcs), tokens that carry a time-stamp and there is a simulation counter clock (timed Petri nets), and permitting transitions to fireat specified rates (stochastic Petri nets).

6.1. Execution semantics

Unlike other diagramming tools such as systems flowcharts, UML diagrams, SSADM (Structured Systems & Design Methodology)diagrams, Petri nets have a precise mathematically defined semantics of their execution which makes the definition of their propertiesprecise, and the simulation of the system possible.

As discussed in Section 5, a transition is enabled when for each place in its pre-conditions the number of tokens is at least equal tothe weight of the arc connecting such pre-condition place and the transition. For example, in the initial marking shown in Fig. 1, theonly transition enabled is t1 (distributePR) since its precondition p1 (Purchase Requisition) contains one token which is equal to theweight of the arc connecting p1 and t1. No other transition in Fig. 1 is enabled in the initial marking.

When the transition t1 (distributePR) fires (ie., it is executed), the tokens in its precondition p1 equal to the weight of the arcconnecting p1 and t1 are removed (or consumed), tokens equal to the weights of the arcs connecting t1 to each of the places in its post-conditions are produced and put in them. For example, when t1 is fired, a token each is put into places p2 and p3. Now transitions t2and t3 are enabled. Firing of t2 consumes one token in place p2 and puts one token in place p4, and so on. The process continues untiltransition t10 is fired and a token is finally placed in p1 which denotes the completion of the business process.

The execution of the business process in Fig. 1 proceeds by a series of firings of transitions which can be represented by a firingsequence. An example of a firing sequence for Fig. 1 could be σ1 {t1,t2,t3,t4,t5,t6,t7,t8,t9,t10}. In general a firing sequence is not unique.In our example σ2 {t1,t3,t2,t4,t5,t6,t7,t8,t9,t10} is also a possible firing sequence. In some Petri nets, some transitions can also be firedmore than once, if there are cycles in the net.

The state of the system represented by the Petri net in Fig. 1 is given by the marking, which can be represented as a 10-dimensional vector whose first component is one, and the rest of the components are zeroes.

As the transitions are fired, the system state changes from one marking top the next. To capture the dynamics of the system changewe first compute the incidence matrix given in Eq. (8) for the Petri net in Fig. 1 as

Fig. 3. Basic patterns in a business process.


42

=

⎡

⎣

⎢⎢⎢⎢⎢⎢⎢⎢⎢⎢⎢⎢⎢⎢

−−

−−−

−−

−−

−−

−−

−

⎤

⎦

⎥⎥⎥⎥⎥⎥⎥⎥⎥⎥⎥⎥⎥⎥

C

1 0 0 0 0 0 0 0 0 11 1 0 0 0 0 0 0 0 01 0 1 0 0 0 0 0 0 00 1 0 1 0 0 0 0 0 00 0 1 1 0 0 0 0 0 00 0 0 1 1 0 0 0 0 00 0 0 1 0 1 0 0 0 00 0 0 1 0 0 1 0 0 00 0 0 0 1 1 0 0 0 00 0 0 0 1 0 1 0 0 00 0 0 0 0 1 1 0 0 00 0 0 0 0 0 1 1 0 00 0 0 0 0 0 0 1 1 00 0 0 0 0 0 0 0 1 1 (14)

Now suppose the firing sequence is given by σ {t1,t2,t3,t4,t5,t6}, i.e., the first six transitions are fired in sequence. This can berepresented by a 14-dimensional vector v with ones in the first six components as in

=v [1 1 1 1 1 1 0 0 0 0 0 0 0 0]T (15)

where vT indicates that it is the transpose of the column vector v. Now if the initial markingM0 for the Petri net in Fig. 1 has one tokenin place p1, we can give the expression for marking Mσ for the state of the system after the firing sequence σ {t1,t2,t3,t4,t5,t6} by theequation as follows:

= +M M C v•σ 0 (16)

where • is the matrix product. This equation is called the state equation since it resembles the state equation of a discrete-time linearsystem.

It is easy to verify that

=M [0 0 0 0 0 0 0 1 0 1 1 0 0 0]σ (17)

or, that after the firing sequence σ {t1,t2,t3,t4,t5,t6} is executed, the resultant system state will have tokens in places p8,p10 and p11.In general, a transition can be fired more than once, in which case we can represent a firing sequence by a firing count vector u

whose components are positive integers.

6.2. Reachability graph and behavioral properties

Properties of AIS are studied either through the use of reachability graphs or through the matrix formulation of such nets inincidence matrices and the state vectors. In this section we study the properties through the use of reachability graphs.

The reachability graph of a Petri net consists of a set of markings (states) and a set of arcs connecting them, and so can beexpressed asR M T= ( , ). There is an arc t between two markings m1,m2 ∈ℳ if there is a transition t ∈ T of the corresponding Petrinet such that it changes the state from marking m1 to m2.

In the reachability graph Fig. 3 for the Petri net in Fig. 1, we represent the marking by indicating the number of tokens in eachplace by

∑∈

M p p( )p P (18)

This provides a compact notation for expressing vectors with a large number of components, and is referred to as functionalnotation for Petri net markings (Peterson, 1981). For example, in Fig. 1, in its initial state (represented in Fig. 4 as s0) there is onetoken with zero tokens in all other places, which we can write as p1, and so we have s0=p1. If we were to use the vector notation wewould have to write a vector with fourteen components where the first component is one with zeroes for all remaining components.Similarly, for place s2 we have s2=p7+p8 indicating that there is one token each in places p7 and p8. There is an arc from s0 to s1since the transition t1 takes the marking of the Petri net from s0 to s1. It is easy to verify that Fig. 4 is the reachability graph of thePetri net in Fig. 1.

Six properties of Petri nets expressed in terms of reachability graphs are boundedness, safeness, liveness, deadlock freeness, andreversibility. We will now describe these properties in the context of the system described in Fig. 1.

6.2.1. Boundedness and safenessA Petri net P T F ω μ{ , , , , }0 is said to be k-bounded if and only if the number of tokens in each place is less than or equal to k for

any marking reachable from the initial marking (Murata, 1989). More formally, we have

R M T∀ ∈ ∀ ∈ ⩽m p P M p k( , )& , ( ) (19)

If k=1, the Petri net is said to be safe. If a Petri net is safe, then the number of tokens in any place p ∈ P is either 0 or 1 and so anymarking of the net can be expressed as a set of |P| Boolean conditions. The safeness property is important in case of physical systemsbecause the Boolean nature of state representation enable such systems to be implemented through flip-flops (Peterson, 1981). An


43

examination of the reachable states in Fig. 4 reveals that the Petri net in Fig. 1 is both bounded and safe.A k-bounded Petri net has at most (k+1)|P| markings, and a safe Petri net has at most 2|P| markings (Muscholl (2016). In other

words, the limit on the number of markings of safe and k-bounded Petri nets is a function of only the number of places. This isimportant since in general Petri nets can have infinite markings. Since the Petri net in Fig. 1 is safe and has 14 places, it can have atmost 214=16384 markings; it can be seen from Fig. 4 that it has only 11 markings.

6.2.2. Liveness and deadlocksFor a Petri net P T F ω μ{ , , , , }0 , a transition t ∈ T is said to be live if given an initial marking m0, for any markingR M T∈m ( , ), there exists a transition sequence σ resulting in some marking m′ which enables t. In other words given an initial

marking a transition t is live if for any marking reachable from m0 there exists a transition sequence which takes the systems state to amarking where the transition t is enabled. A Petri net is said to be live if and only if all of its transitions are live. Liveness is usually aminimum requirement for a well designed system.

In Fig. 4, the initial marking is s0=p1. From the above definition of liveness of a transition, any transition t is live if, for anymarking reachable from s0 there must exist a transition sequence σ such that we arrive at a marking where the transition t is enabled.For example, if we consider the marking s2 which is reachable from s0, we have the transition sequence σ=(t2,t4,t5,t6,t7,t8,t9,t10)which takes us to the marking s0 where the transition t1 is enabled. So, the transition t1 is live. It is easy to verify from the reachabilitygraph in Fig. 4 that every transition in Fig. 1 is live, and therefore the Petri net in Fig. 1 is live.

Deadlock-freeness is a very important property of any well designed AIS. In a Petri net, a marking is said to be a deadlock if notransition is enabled and the system freezes. Deadlocks are not always easy to detect manually but they can be detected throughalgorithmic evaluation methods described below. One way of verifying if a Petri net is deadlock-free is through its reachability graphthat is strongly connected, where there is a directed path (transition sequence) from every marking to every other marking. Hence,the reachability graph in Fig. 4 is strongly connected and the corresponding Petri net in Fig. 1 is deadlock-free. One exception to theuse of reachability graphs to verify deadlock-freeness is when a Petri net is not bounded and so there is no limit on the number oftokens that can accumulate in places and the number of markings is not finite.

Another way to verify deadlock-freeness is through the method described in Wegrzyn et al. (2004):

Fig. 4. Reachability graph for the Petri net in Fig. 1.


44

A subset of places P of a Petri net P T F{ , , } is said to be a deadlock if

⊂P P• • (20)

where •P and P• are respectively the sets of the input and output transitions of the places in P. Deadlock is a structural property ofPetri nets and therefore the initial marking is not relevant. Since in a deadlock the input transitions are a subset of the outputtransitions, “once all of the places in the deadlock become unmarked,… no transition can place a token in the deadlock because thereis no token in the deadlock to enable a transition which outputs to a place in the deadlock” (Wegrzyn et al., 2004). Since no transitioncan fire, the system comes to a halt. It is important to note that a live Petri net is deadlock-free, but a deadlock-free Petri net is notnecessarily live. Cardoso and Camargo (1999) give an example of a non-live Petri net which is deadlock-free.

6.2.3. ReversibilityA Petri net P T F ω μ{ , , , , }0 is said to be reversible if, for any marking m reachable from the initial marking there exists a

transition sequence σ such that mσ yields the marking m. More formally, a Petri net P T F ω μ{ , , , , }0 is said to be reversible if

M∀ ∈ ∃ ∋ =m σ m m, σ (21)

To show that the Petri net in Fig. 1 is reversible, given the initial marking s0 in the reachability graph in Fig. 4, consider anymarking reachable from s), say s3. There is a transition sequence σ=(t3,t4,t5,t6,t7,t8,t9,t10) that gets us back to the initial marking s0. Itis easy to verify that for any marking reachable from s0 in Fig. 4, there exists a transition sequence that gets us back to s0. Thereforethe Petri net in Fig. 1 is reversible.

6.3. Structural properties: place & transition invariants

Place and Transition invariants are structural properties of Petri nets because they depend exclusively on the structure of suchnets. These properties have to do with the stability of token distribution in places expressed as token conservation laws for places, andtasks that depend on individual cases (tokens) when not all tasks are performed on all cases (tokens). When the tokens are indis-tinguishable, this can happen only when the net is non-deterministic. We will discuss place invariants first, and then the transitioninvariants.

6.3.1. Place invariants (P-invariants)A P-invariant is a subset of places such that the weighted number of tokens in the subset are constant in any marking. More

formally, a place vector p=[P0 P1 P2 … P13 P14] of a Petri net is called a p-invariant or a place invariant if it satisfies

=C p• 0T T (22)

where the exponent T stands for transpose and • stands for matrix multiplication. P-invariants are sequentially linked execution pathsin a Petri net (Lautenbach, 1975, 1987; Kostin, 2006). The weighted number of tokens in an execution path in any such executionpath in a Petri net must be constant. In particular, in case of workflow net as in our example, at any time during the execution of thepurchase process, the number of tokens in any such place invariant execution paths must be 1. Another way to express this is to saythat in a place invariant execution path, at any time during execution, one and only one transition (task) is enabled. In case of ourexample, solution of Eq. (24) yields eight equations, each relating to an execution path of the Petri net in Fig. 1:

+ + + + + + + + =M P M P M P M P M P M P M P M P M P( 1) ( 3) ( 5) ( 6) ( 9) ( 11) ( 12) ( 13) ( 14) 1 (23a)

+ + + + + + + + =M P M P M P M P M P M P M P M P M P( 1) ( 2) ( 4) ( 6) ( 9) ( 11) ( 12) ( 13) ( 14) 1 (23b)

+ + + + + + =M P M P M P M P M P M P M P( 1) ( 3) ( 5) ( 8) ( 12) ( 13) ( 14) 1 (23c)

+ + + + + + =M P M P M P M P M P M P M P( 1) ( 2) ( 4) ( 8) ( 12) ( 13) ( 14) 1 (23d)

+ + + + + + + =M P M P M P M P M P M P M P M P( 1) ( 3) ( 5) ( 7) ( 11) ( 12) ( 13) ( 14) 1 (23e)

+ + + + + + + =M P M P M P M P M P M P M P M P( 1) ( 2) ( 4) ( 6) ( 10) ( 12) ( 13) ( 14) 1 (23f)

+ + + + + + + =M P M P M P M P M P M P M P M P( 1) ( 3) ( 5) ( 6) ( 10) ( 12) ( 13) ( 14) 1 (23g)

+ + + + + + + =M P M P M P M P M P M P M P M P( 1) ( 2) ( 4) ( 7) ( 11) ( 12) ( 13) ( 14) 1 (23h)

The eight execution paths corresponding to the equations are illustrated in Figs. 5 and 6. For example, Eq. (23a–h) relates to Fig. 5panel A, and the corresponding place invariant consist of the sequence of places {p1,p3,p5,p6,p9,p11,p12,p13,p14}. At no time during theexecution of the purchase process can there be more than one token in the places in this path. This constraint on the number of tokensis referred to in the literature as a token conservation law. The token conservation law also imposes other constraints on the number oftokens in subsets of places in the sequence. For example, if you consider the subset {p12,p13,p14}, there can be exactly one token in thissubset of places. The remaining panels B to H in Figs. 5 and 6 can be similarly interpreted. The token conservation laws serve asinternal control rules that constrain the processing capacity of the purchase process. The analysis of the Petri net for an accountinginformation system provides us through the place invariants the internal control rules which can be verified during the executiontime through checking the tokens.


45

6.3.2. Transition invariants (T-invariants)T-invariants list all possible execution paths (transition sequences) from the initiation of the business process to its conclusion for

any case. That enables detection of any dangling transitions because in that case the process will not come to its conclusion (Girault

Fig. 5. Place invariants for the purchase system example.


46

and Valk, 2001). T-invariants can be computed by solving the following (Lautenbach, 1975, 1987; Kostin, 2003, 2006):

=C t• 0 (24)

where t is a non-negative integer transition vector whose components are the number of firings of the corresponding place. Solving

Fig. 6. Place invariants for the purchase system example.


47

this equation for the problem in Fig. 1 yields the only T-invariant

[1 1 1 1 1 1 1 1 1 1] (25)

Which means that the only execution path that takes a token from the initial marking to the same marking involves execution ofeach transition in the net exactly once. In general however, a transition in the net can fire more than once.

Place and transition invariants provide us important internal control tools for accounting: place transitions by their token con-servation laws and transition invariants by detecting dangling transitions. These can be verified at the design stage in the devel-opment of accounting systems.

7. Petri nets, business processes, and workflow nets

We now discuss the relationship between Petri nets and a common way of representing business processes known as workflownets (WF-nets) which are a subclass of Petri nets (van der Aalst and Stahl, 2011b; Van der Aalst and Van Hee, 1996). All the analyticaltools for Petri nets can be used for WF-nets. WF-nets can be automatically generated from event logs of accounting transactions usingprocess mining technique (van der Aalst and Weijters, 2005; Jans et al., 2014). This is accomplished by software such as ProM (vander Aalst et al., 2009; Kalenkova et al., 2014) or Flexiconn Disco (Ailene et al., 2012; Günther and Rozinat, 2012). Due to suchautomatic generation of WF-nets, the overall process of documenting AIS can be more efficient because the amount of fieldworkrequired to gather and manually construct WF-nets for AIS is reduced. Auditors can compare automatically generated WF-nets withcompany policies to determine the compliance of processing accounting transactions. Since a WF-net derives most of its analyticalpower as a sub-class of Petri net, it can serve as a unified model for accounting systems and auditing.

A WF-net represents the processing of one transaction at a time using three symbols: pre-post conditions (circles), tasks (solidbars), and arcs connecting pre/post conditions and tasks. The transitions in the WF-nets correspond to the tasks in the businessprocesses; the places in the WF-nets correspond to the pre/post conditions of the tasks in the business processes. For a transaction toprocess, a token is placed in the pre-condition of the source task. Once all pre-conditions are satisfied and the task is completed, atoken is placed in the post-conditions of the task. As an example of a WF-net, we reduce the Petri net in Fig. 1 to its originating WF-netas follows: we delete transition t10 and the two arcs incident (p14,t10) and (t10,p1) to obtainA =′

′ ′ ′ ′P T F ω μ{ , , , , }A A A A 0 . This reduced

Petri netA ′ is called a WF-net if it satisfies the following properties: (i) it has one node p1, called source node which has no arc leadingto it, (ii) one node p14, called terminating node which has no arc emanating from it, and (iii) every node P T

A A∈ ∪′ ′n is on a path

from source node p1 to terminating node p14 (van der Aalst, 2000). The Petri netA is called the extended Petri net of the WF Net PetrinetA ′. van der Aalst (1997) show that a WF-Net Petri netA ′ is sound if and only if the corresponding extended Petri netA is liveand bounded (see Theorem 11, page 416). Soundness of a WF-net is a behavioral property that ensures accuracy and integrity of thesystem by verifying that a transaction is completed in its entirety without leaving any debris. Soundness property is met by twocriteria: (i) when the transaction processing is complete there is one token in the terminating node and no tokens in all the otherplaces in the WF-net; (ii) where there is no dead transition. The first condition ensures that the transaction has been processedcompletely. The second condition ensures that there is no transition that can never fire.

Workflow nets depict a procedure for processing of transactions in a business process. The procedure is sound if it terminateseventually, and when it terminates there is a token in the terminating node and all the other places are empty (van der Aalst, 1997).van der Aalst (1997) has also shown that soundness of workflow procedure can be verified in polynomial time if we restrict ourselvesto free choice Petri nets. A free choice Petri net rules out interference between conflicts and synchronization issues. Specifically, aPetri net is free choice if for any arc from a place s to a transition t, there is an arc from any input place of t to any output transition ofplace s (Desel and Esparza, 2005).

Workflow nets implemented through BPMN are becoming popular and are supported by software platforms such as Oracle Fusion(http://www.oracle.com/us/technologies/bpm/overview/index.html) and IBM Business Process Manager. In the future accountingworkflows are likely to be designed and implemented using such software platforms. The affinity between workflow nets and Petrinets gives researchers the opportunity to closely examine how Petri nets can elevate the analytics and simulation capabilities of AISworkflows.

8. Petri net extensions

Petri nets are very parsimonious since they have just three symbols: places, transitions, and information flows. The Petri net wehave illustrated in this paper is one of the simplest where a place can hold at most one token, the token does not have any internalstructure, and no assumptions are made regarding the firing of transitions or their timing. All these assumptions are relaxed in theextensions in order to model more complex real world problems. We will now provide a classification based on extensions to the threesymbols: places, transitions, and information flows.

The database of Petri net tools at the University of Hamburg (https://www.informatik.uni-hamburg.de) provides a classificationof Petri nets. This classification is suggested by Monika Trompedeller in 1995 based on a survey in Bernardinello and Cindio (1992).In the Trompedeller classification, at the top level, based on the extension to places, there are three types of Petri nets depending onthe number and structure of tokens: in Level 1 Petri nets, places can be marked by at most one unstructured token, and therefore themarking of a place is a boolean value. The illustration in Fig. 1 is an example of a Level 1 class since a place can hold at most oneunstructured token. In level 2 Petri nets, the places can hold multiple unstructured tokens, and in level 3 Petri nets, the places can


48

http://www.oracle.com/us/technologies/bpm/overview/index.html

https://www.informatik.uni-hamburg.de

hold multi-sets of structured tokens, ie., there can be many types of tokens and a place can hold more than one token belonging toeach token type. An example of a level 3 a Petri net is colored Petri netwhere the tokens have color which can be an arbitrary datatype.A purchase order can be assigned a blue token with all relevant data. For detailed discussion of colored Petri nets see Jensen (2013)and Jensen and Kristensen (2009).

Extensions to the transitions in Petri nets can be in the form of putting priorities on the firing of transitions by a priority function πwhich maps transitions to a set of priority classes. A transition can not fire if any transition of a higher priority is enabled. Such netsare called prioritized Petri nets (Balbo, 2007). On the other hand, transitions can be timed, as for example in the case of, say, purchaserequisitions which might be processed once a day or every 2 hours. Or, transitions can be fired randomly following, for example, anexponential distribution. These extensions lead to timed Petri nets (Silva and Del Foyo, 2012) and stochastic Petri nets (Balbo, 2007). Intimed Petri nets, firing rates can be modeled as following the exponential distribution. In stochastic Petri nets, on the other hand,delays in the firing after a transition has been enabled can be stochastic, modeled using a probability distribution, usually exponentialdistribution, as in Zimmermann (2008).

Petri nets can also be extended by introducing various types of information flows such as reset the tokens in a place reset arcs(Zhang et al., 2014), transfer arcs (Geeraerts, 2009), and inhibitor arcs (Murata, 1989). All of these arcs to Petri nets are from places totransitions. In case of reset arcs, when the transition is fired, the tokens in the place are deleted. Reset arcs are useful in the design ofaccounting systems to incorporate cancellations of transactions or parts of transactions. In case of transfer arcs, when the transition isfired, all tokens in the place are transferred to another place. An inhibitor arc imposes the condition on the transition that it can fireonly if the place is empty. For example, in a purchase and sale system with rudimentary inventory policy (a purchase order is placedonly when inventory is exhausted), there can be an inhibitor arc between a place inventory on hand and a transition placepurchase order. In such a system, the transition place purchase order is enabled/fired only when there is no token (inventory)in the place inventory on hand. The above extensions provide a rich set of formalisms to design complex AIS using Petri nets.

9. Assessment of systems flowcharts and Petri nets for modeling AIS

Earlier in Section 3 we proposed seven requirements that any model and documentation of AIS must fulfill. For each of thoserequirements, we now examine how system flowcharts and Petri nets meet them.

9.1. Assessment of requirement 1: model should be parsimonious

Systems flowcharts use many symbols and annotations. For example, the popular system flowcharting software Conceptdraw lists25 symbols under Integration DEFinition modeling language for system and software engineering. Additionally, most systemsflowcharts in the real world run into dozens of pages and therefore it is challenging for users to comprehend as symbols can haveambiguous meaning. For example, input/output, manual input, and keyboard input are unclear as they can refer to either themovement of data or the physical act of moving data. Since the symbols in systems flowcharts lack semantics beyond their shapes andlabels, analysis through properties of the system is not possible. While manual analysis is possible, it can be very time consuming andprone to errors.

In comparison, Petri nets use only three symbols: places, transitions, and information flows. This simplicity allows Petri nets tofocus on the substance of what is done in the business processes rather than how it is done. Petri nets show only processes (tran-sitions) in terms of descriptions of what is done and represented as information flows or transitions. If more complex accountingfeatures need to be described, Petri nets add colors for tokens and symbols for reset, transfer, or inhibitor arcs. Parsimonious use ofsymbols to express operations of the system makes semantics clearer without losing the intended meaning. This balance betweenparsimony and expressivity makes Petri nets an ideal way to model complex accounting systems.

9.2. Assessment of requirement 2: model should support analytics for design of accounting function

The four sub-requirements in the design of the accounting function (2.1 – 2.4 of Table 1) include assignment of tasks (and roles) topeople, rotation of duties, verification of SoD compliance, and the decision to make the tasks manual or automated. System flow-charts are sufficient to meet these requirements when the systems to be designed are relatively small, but for larger systems they donot support the business processes that must be choreographed. This involves synchronization of parallel tasks so that time, resources,and costs for transaction processing are minimized. Also if people are performing tasks in various systems flowcharts that areinterrelated, it becomes very difficult to manually identify system inefficiencies and internal control weaknesses. With shapes andsymbols that lack internal structure and semantics, it is not possible to determine attributes such as prepared by, approved by, and timestamp of a task except through annotations. The four sub-requirements can be satisfied only if the flowcharts are first annotated withattributes, and then translated into a more formal model with richer semantics in order to perform the role of a decision supportsystem. To facilitate the choice of automation of tasks, data structures for the algorithms will have to extracted from the annotatedtranslated systems flowchart. All these factors make systems flowcharts inefficient and costly choice for documenting large ac-counting systems.

In comparison, Petri nets can provide decision data to facilitate: development of algorithms for assignment of tasks to people,rotation of duties, verification of SoD, and choice of automation of tasks. For example, based on skills required and employeesavailable, algorithms can be developed to match tasks to employees such that no tasks remain unassigned, segregation of dutiesrequirements are satisfied, and rotations are scheduled so as to minimize risks. To properly assess if a task should be performed


49

manually or automated, Petri net models provide data for decision making by simulating run-time behavior based on task perfor-mance times (using variables such as skill levels and hardware/software configurations). Therefore, Petri nets support analytics ofdesign of accounting systems.

9.3. Assessment of requirement 3: model should support analytics for correctness of AIS

This requirement involves choice based on the absence of undesirable anomalies and the presence of desirable properties in thesystem designed. Systems flowcharts can not be used to specify an execution model for transactions. Therefore, even if the design iscorrect, the integrity of the execution of transactions can not be ensured because errors can exist in the translation from the spe-cification model to the execution model. Also, anomalies such as redundancy, hung tasks, and deadlocks can not be detected becausesystems flowcharts lack a formal model. For the same reason the properties of boundedness, safeness, reversibility, and soundness cannot be verified.

Petri nets, because of its sound mathematical foundations, enable detection of anomalies as well as verification of desirableproperties. If the AIS is large, then the properties also can be verified through simulation.

9.4. Assessment of requirement 4: model should support analytics for the completeness assertion

With system flowcharts, completeness assurance is difficult to verify for complex and large accounting systems because internalcontrols can not be easily expressed with the flowcharts. They can be added through annotations but the process is very timeconsuming. Additionally, systems flowcharts are not expressive enough to represent the economic model. For example, in case ofhotel industry one can not express the fact that each occupied unit must yield per unit profit can not be represented in the systemflowcharts except through annotations.

Assurance of completeness can be achieved with use of Petri net as it can integrate internal and external evidence as well as dataexternal to the accounting system such as sensor data. Additionally, algorithmic verification of completeness can be accomplishedthrough establishing a baseline Petri net model which incorporates norms provided by the economic model. This model, referred to assoll in Elsas (1996) can then be used as the standard for comparison with actual activities in order to test completeness and identifyanomalies such incomplete revenues or money laundering per our hotel example in Section 4.4. See Elsas (1996) for detailed exampleof soll and automatic verification of completeness assertion in the operating cycle.

9.5. Assessment of requirement 5: model should support analytics for processing capacity, task scheduling, and planning

It is perhaps possible for small systems flowcharts to meet some of these sub-requirements. First, labor resources required can beestimated based on transaction volume and processing time, and scheduling of tasks can be prepared based on the smaller size of theaccounting department. However, when the systems are large and complex, the use of systems flowcharts are not as helpful. Due tothe size of flowcharts and number of symbols used, it can be overwhelming to efficiently organize tasks. Second, assessing computingcapacity needs is challenging because it is influenced by balancing of system resources: people, software, and hardware. Withflowcharts this task is not possible because it does not provide capability for simulation. Third, the choice of tasks to be automatedrequires simulation of the system behavior. Systems flowcharts require building a model for simulation from the scratch, whichincreases cost. Fourth, estimation of human resources required to implement the design is difficult with systems flowcharts for thesame reason in that they do not facilitate simulation of the behavior of the system.

On the other hand Petri nets, with only two basic symbols (transitions and places) and capabilities for simulation of systembehavior, make it possible to deal with all four sub-requirements. It is possible to design an accounting system iteratively by usingPetri net software to examine the model properties, simulate the system behavior, and refine the model until it has properties andbehaviors desired. Also, it is possible to perform simulations of what-if scenarios based on costs of hardware, software, and labor. Forexample, given a budget, it is possible to estimate processing capacity needs and system configuration by simulating how the systemoperates based on costs, required transaction load, and tolerable latency. For example, when certain transitions become bottlenecksleading to backlog of transactions to be processed, the throughput can be increased by investing in the capacity of the transition. Onthe other hand, if a transition is idle for considerable time, one can process transactions in batch mode and share the resources withother appropriate business processes. In either case, the advantage is that optimal configurations can be determined through si-mulations to best plan for processing capacity as well as the decision to perform a task in real-time or batch. These decisions areusually taken through a process of trial-and-error, use of personal heuristics, or building ad hoc decision models, whereas Petri netmodeling allows an integrated approach to such decisions.

9.6. Assessment of requirement 6: model should support analytics of AIS performance

Since systems flowcharts lack simulation capability, they can not support hardware/software procurement decisions. Such de-cisions must therefore be based on approximations, and so the total cost may not be minimized. efficiency evaluation of the designedsystem also must be based on estimations through trial-and-error. The choice of system configuration based on operating performancealso can not be supported by system flowcharts for the same reason.

In comparison, Petri nets can simulate run-time behavior of an accounting system by its animation. This provides information tosupport procurement as well as choice of system configuration based on simulated operating performance. For example of a Petri net


50

simulation using animation, see Griffioen et al. (2000).

9.7. Assessment of requirement 7: model should support analytics and automation of auditing

Systems flowcharts were devised mainly to document information systems but not to directly support auditing. While systemsflowcharts may be useful in informal compile-time verification done manually, they make automation of such verification difficult toachieve. Manual verification of run-time internal controls, on the other hand, is impossible for most large accounting systems andtheir flowcharts do not directly aid in automation. Any model of accounting information system must aid in the automation ofauditing.

Petri nets, on the other hand, do enable modeling to automate auditing in a number of ways. For example, Hee et al. (2010)provide ways of expressing business rules and internal controls that in many cases can be translated into Petri nets which can be usedto detect violations. In addition, Knorr and Weidner (2001) and Knorr and Stormer (2001) provide methods for verifying SoDcompliance through Petri nets. Other examples of Petri nets-based methods for auditing include model-based auditing in REA byWeigand and Elsas (2012), knowledge-based audit support by Elsas et al. (1992), and enterprise immunity to solo-fraud by Elsas(2008). It is also possible to embed the Petri net of an accounting system in a database environment to achieve real-time verificationof internal control rules for continuous auditing.

Table 1 summarizes our discussion of flowcharts and Petri nets in the light of the requirements established in Section 2. Thepurpose of the requirements is to provide desirable qualities of the model and documentation of AIS, and understanding what toaccomplish based on a set of determined objectives. The metrics are quantitative measures used to determine if the objectives havebeen met. It can be seen from the table that while many of the requirements can be met by both systems flowcharts and Petri nets,systems flowcharts do not directly contribute to the recommendations addressed by the requirements. On the other hand, Petri netsprovide the analytical framework for addressing the decision areas crucial in the design and implementation of AIS.

For example, 2.3 in Table 1 states that the model and the documentation should aid in the design of accounting function such thatthere is segregation of duties. For this to be accomplished, the goal should be to minimize the number of SoD violations, which canultimately be measured by the count of violations in the designed accounting system. Since symbols in systems flowcharts do not haveclear distinct semantics beyond their shape and label, SoD rules have to be specified outside of systems flowcharts, thus requiring taskassignments to be done manually. On the other hand, Petri nets provide a natural way to express SoD rules. For example, if thetransitions are shown in different colors depending on whether they are execution, recording, or custody, one SoD rule could be asfollows: if a person X performs a custody transition t1, then X can not perform any recording transition, say tk, if there is a path from t1to tk. Algorithms can be developed for task assignments exploiting the network structure of Petri nets. Table 1 shows that for mostrequirements, it is possible to exploit the structure of Petri nets to achieve the desirable qualities discussed in the requirements. Thiscan be accomplished through analytics by developing algorithms to support the objectives laid out in the table.

10. Petri nets and AIS research

The requirements for AIS models that we have discussed in Section 4 arise out of the problems faced by AIS designers in im-plementing accounting systems. Large, complex, and distributed accounting systems entail large investments and therefore they mustbe approached in a rational manner so that the errors in decisions are minimized. Most of the requirements summarized in Table 1 arestudied using analytical optimization models, but others are best examined using simulations. Some of the optimization problems weidentify have been generically addressed in management science as well as computer science, however, there is a significant need tofurther explore these issues in light of domain specific constraints imposed by AIS. This provides AIS researchers opportunities tocontribute to the solution of problems encountered in practice. We discuss two significant areas of AIS research, segregation of dutiesusing analytics and performance of accounting systems using simulation.

10.1. Research opportunities in analytics

Our proposed requirements provide extensive AIS research in analytics of design such as SoD and rotation of duties, and analyticsin processing such as run-time verification of controls. First, SoD can be viewed as conflict-free assignment of employees to tasks. Inmanagement science, task assignments are examined as a linear assignment model as in Burkard et al. (2009) where the goal is toefficiently distribute labor among tasks to minimize total cost. Incorporating SoD constraints was not the primary focus of theirmodel. In computer science, task assignments are formulated as role-based access control (RBAC) model as in Thomas and Sandhu(1998) and for Information Technology (2004) where the goal is to avoid assignments that yield SoD violations. However, the RBACmodel does not include conflicts due to extraneous attributes such as physical proximity and familial relationships. These gapspresent opportunities for AIS researchers to develop algorithms to minimize SoD violations.

Second, rotation of duties involves scheduling of task assignments so that employees do not perform the same tasks for anextended period of time. Preparing rotation schedules requires development of algorithms to minimize same task assignments andoptimize system performance, which present AIS research opportunities.

Third, run-time verification of controls is a powerful tool in auditing to ensure integrity of AIS by detecting irregularities intransaction processing. Implementing run-time verification requires formalizing the control rules and incorporating the algorithms.

These three areas provide AIS research opportunities for analytics by developing control rules and algorithms to be incorporatedin Petri nets through means such as feedback controls as in Yamalidou et al. (1996). Also, errors that propagate through business


51

processes can be studied for mitigation of risks by modeling them as Petri nets as in Bai et al. (2012).

10.2. Research opportunities in simulation

In the literature, analytics through simulations have been used to study system behavior in queueing models as well as Petri netsby Haas (2006), and applied to problems in diverse fields including manufacturing as in Piera et al. (2004), construction as inWakefield and Sears (1997), supply chain management as in Lam and Yip (2014), conceptual modeling of information systems as inRoos-Frantz et al. (2015), interactive web interfaces as in Brant-Ribeiro et al. (2017), and business process simulation as in Heinrichet al. (2017). The requirements in Section 4 of our paper provide ample opportunities for AIS research in areas such as benchmarkingsystem performance as well as decision-making in computing capacity, automation, and organization of accounting function. Each ofthese areas involve analytics of what-if scenarios depending on the choice of various decision variables. For example, bench-markinginvolves study of systems performance for alternative hardware/software configurations, computing capacity involves alternativecost and performance of such configurations, automation decisions involves costs and performance trade-offs, and the decisions onthe organization of the accounting function depends on alternative assumptions regarding configuration of human and computingresources. In each of these areas, understanding of the system run-time behavior is important, especially when it can not be sum-marized in analytically derived statistics and must therefore be obtained from simulations. Petri nets provide a very realistic en-vironment for experimenting with AIS using simulations before extensive investments of resources are made.

11. Conclusion

Increasing complexity and cost demand that AIS models support verification of design through analytics, and provide decisionsupport in optimizing capacity, planning of implementation, testing of system performance, and automation of auditing throughsimulation of the system designed. This primer proposes a set of requirements that AIS models should meet to facilitate analytics andsimulation. We examine the traditional systems flowcharts and Petri nets to evaluate how each method meets the proposed re-quirements. Our choice for using Petri nets to represent the alternative models is predicated on the fact that most models are eitherinfluenced by Petri nets or can be transformed into them. We find Petri nets suitable for modeling AIS due to their support foranalytics as well as simulation to support design, testing, implementation, as well as system performance evaluation for AIS. Weprovide an example using a purchasing cycle to formalize and illustrate Petri net concepts and their properties relevant to accountingand auditing. Petri nets have gained much attention in computer science and engineering, but have been less explored in AIS andauditing. Therefore we have provided some possible areas that AIS researchers can consider for further investigation.

References

Ailene, I., Rozinat, A., Eckert, A., van der Aalst, W.M.P., 2012. Definition and validation of process mining use cases. In: Daniel, F., Barkaoui, K., Dustdar, S. (Eds.),Business Process Management Workshops: BPM 2011 International Workshops, Clermont-Ferrand, France, August 29, 2011, revised selected papers, Part I.Springer Berlin Heidelberg, pp. 75–86.

Bai, X., Krishnan, R., Padman, R., Wang, H.J., 2012. On risk management with information flows in business processes. Inf. Syst. Res. 24 (3), 731–749.Balbo, G., 2007. Formal Methods for Performance Evaluation: 7th International School on Formal Methods for the Design of Computer, Communication, and Software

Systems. Ch. Introduction to generalized stochastic Petri nets. Springer Berlin Heidelberg, pp. 83–131.Bernardinello, L., Cindio, F. d., 1992. A survey of basic net models and modular net classes. In: Advances in Petri Nets 1992, the DEMON Project. Lecture Notes in

Computer Science, vol. 609. Springer-Verlag, London, UK, pp. 304–351.Booch, G., Maksimchuk, R., Engle, M., Young, B., Conallen, J., Houston, K., 2007. Object-oriented Analysis and Design With Applications, 3rd. Addison-Wesley

Professional.Bosilj-Vuksic, V., Giaglis, G.M., Hlupic, V., 2001. IDEF Diagrams and Petri Nets for Business Process Modeling: Suitability, Efficacy, and Complementary Use.

Enterprise Information Systems II. Springer Netherlands, Dordrecht, pp. 143–148.Bradford, M., Richtermeyer, S., Roberts, D.F., 2007. System diagramming techniques: an analysis of methods used in accounting education and practice. J. Inf. Syst. 21

(1), 173–212.Brant-Ribeiro, T., Araújo, R.D., Mendonça, I.E., Soares, M.S., Cattelan, R.G., 2017. Interactive web interfaces modeling, simulation and analysis using colored Petri

nets. Softw. Syst. Model. 16, 1–17.Burkard, R., Dell’Amico, M., Martello, S., 2009. Assignment Problems. Society for Industrial and Applied Mathematics.Cardoso, J., Camargo, H., 1999. Fuzziness in Petri nets. Physica-Verlag.Carmichael, D.R., 2004. The PCAOB and the social responsibility of the independent auditor. Account. Horiz. 18 (2), 127–133.Carnaghan, C., 2006. Business process modeling approaches in the context of process level audit risk assessment: an analysis and comparison. Int. J. Account. Inf. Syst.

7, 170–204.Chen, K.-T., Lee, R.M., 1992. Schematic evaluation of internal control accounting systems. Tech. Rep. Monograph No. RM-1992-08-1. Erasmus University Research

Institute for Decision and Information Systems.Desel, J., Esparza, J., 2005. Free Choice Petri Nets. vol. 40 Cambridge University Press.Dicksee, L.R., 1905. Auditing: A Practical Manual for Auditors. Gee & Company, London, UK.Elsas, P., 2008. X-raying segregation of duties: support to illuminate an enterprise's immunity to solo-fraud. Int. J. Account. Inf. Syst. 9 (2), 82–93.Elsas, P.I., 1996. Computational Auditing. Delloitte Touche Tohmatsu International.Elsas, P.I., van de Riet, R.P., van Leeuwen, J.J., 1992. Knowledge-based audit support. In: Proceedings of the International Conference on Database and Expert Systems

Applications, Valencia, Spain, 1992, pp. 512–518.Fahland, D., 2008. Translating uml2 activity diagrams to Petri nets for analyzing IBM websphere business modeler process.for Information Technology, A. N. S., 2004. Role based access control. Tech. Rep. ANSI INCITS 359-2004. American National Standards Institute, Inc.Geeraerts, G., 2009. On the expressive power of Petri nets with transfer arcs vs. Petri nets with reset arcs. Tech. Rep. Technical Report 572. Université libre de

Bruxelles.Gilbreth, F.B., Gilbreth, L.M., 1921. Process charts. Tech. Rep. American Society of Mechanical Engineers.Girault, C., Valk, R., 2001. Petri Nets for System Engineering: A Guide to Modeling, Verification, and Applications. Springer-Verlag New York, Inc., Secaucus, NJ, USA.Gold, R., 2004. Petri nets in software engineering. Arbeitsberichte Working Papers ISSN 1612-6483. Fachhochschule Ingolstadt University of Applied Sciences.


52

http://refhub.elsevier.com/S1467-0895(16)30125-7/rf0005




































Griffioen, P.R., Elsas, P.I., van de Riet, R.P., 2000. Database and Expert Systems Applications: 11th International Conference, DEXA 2000 London, UK, September 4–8,2000 Proceedings. Springer Berlin Heidelberg, pp. 685–697 Analyzing enterprises: the value cycle approach.

Günther, C.W., Rozinat, A., 2012. Disco: discover your processes. BPM (Demos) 940, 40–44.Haas, P.J., 2006. Stochastic Petri Nets: Modelling, Stability, Simulation. Springer Science & Business Media.Hee, K.V., Hidders, J., Houben, G.-J., Paredaens, J., Thiran, P., 2010. Abstracting common business rules to Petri nets. Enterp. Inf. Syst. 2010 113.Heinrich, R., Merkle, P., Henss, J., Paech, B., 2017. Integrating business process simulation and information system simulation for performance prediction. Softw. Syst.

Model. 16 (1), 257–277.Höhne, K.H., 2013. Pictorial Information Systems in Medicine. Springer Science & Business Media.Hu, Z., Shatz, S.M., 2004. Mapping UML diagrams to a Petri net notation for system simulation. In: Proceedings of the Sixteenth International Conference on Software

Engineering & Knowledge Engineering (SEKE’2004), Banff, Alberta, Canada, June 20–24, 2004, pp. 213–219.Jans, M., Alles, M.G., Vasarhelyi, M.A., 2014. A field study on the use of process mining of event logs as an analytical procedure in auditing. Account. Rev. 89 (5),

1751–1773.Jensen, K., 2013. Coloured Petri Nets: Basic Concepts, Analysis Methods and Practical Use. Springer Science & Business Media.Jensen, K., Kristensen, L.M., 2009. Coloured Petri Nets: Modelling and Validation of Concurrent Systems. Springer Science & Business Media.Jensen, K., van der Aalst, W.M.P. (Eds.), 2009. Transactions on Petri Nets and Other Models of Concurrency II, Special Issue on Concurrency in Process-Aware

Information Systems. vol. 5460 Springer. http://dx.doi.org/10.1007/978-3-642-00899-3.Kalenkova, A., de Leoni, M., van der Aalst, W.M.P., 2014. Discovering, analyzing and enhancing BPMN models using prom. In: Proceedings of the BPM demo sessions

2014 co-located with the 12th International Conference on Business Process Management (BPM 2014), Eindhoven, The Netherlands, September 10, 2014. pp. 36.http://ceur-ws.org/Vol-1295/paper21.pdf.

Karimov, A., Moharrami, S., 2012. Using Petri nets for resource management modeling in the operating systems. IJCSI Int. J. Comput. Sci. Issues January 2012 9 (1),283–288.

Knorr, K., Stormer, H., 2001. Modeling and analyzing separation of duties in workflow environments. In: Sec. Springer.Knorr, K., Weidner, H., 2001. Analyzing separation of duties in Petri net workflows. Information Assurance in Computer Networks. pp. 102–114.Kostin, A., 2003. Reachability analysis in t-invariant-less Petri nets. IEEE Trans. Autom. Control 48 (6), 1019–1024.Kostin, A.E., 2006. Mathematical foundations of computer science 2006: 31st International Symposium, MFCS 2006, Stará Lesná, Slovakia, August 28–September 1,

2006. Proceedings. Springer Berlin Heidelberg, pp. 608–621 A reachability algorithm for general Petri nets based on transition invariants.Krishnan, R., Peters, J., Padman, R., Kaplan, D., 2005. On data reliability assessment in accounting information systems. Inf. Syst. Res. 16 (3), 307–326.Lam, J.S.L., Yip, T.L., 2014. Impact of port disruption on supply chains: Petri net modeling and simulation. In: International Forum on Shipping, Ports and Airports

(IFSPA) 2014: Sustainable Development in Shipping and Transport Logistics.Lautenbach, K., 1975. Liveness in Petri nets. Tech. Rep. GMD-ISF 75-02.1. Gesellschaft fiir Mathematik und Datenverarbeitung, Bonn.Lautenbach, K., 1987. Linear algebraic techniques for place/transition nets. In: Brauer, W., Reisig, W., Rozenberg, G. (Eds.), Petri Nets: Central Models and Their

Properties. Lecture notes in computer science, vol. 254. Springer-Verlag, pp. 142–167.Blätke, Mary Ann, Monika Heiner, W.M., 2011. Tutorial: Petri Nets in Systems Biology. Otto-von-Guericke University Magdeburg. http://www.regulationsbiologie.

de/pdf/BlaetkeTutorial.pdf.Merseguer, J., Campos, J., 2004. Software performance modeling using UML and Petri nets. In: Performance tools and Applications to Networked Systems. Springer,

pp. 265–289.Mohlin, M., 2010. Model simulation in rational software architect: business process simulation. Tech. Rep. IBM Corporation.Moody, D.L., Shanks, G.G., 1994. Entity-relationship approach - ER ’94: business modelling and re-engineering. Lecture Notes in Computer Science 881. Springer

Verlag What makes a good data model? Evaluating quality of entity relationship models.Murata, T., 1989. Petri nets: properties, analysis and applications. In: Proceedings of the IEEE. vol. 77. pp. 541–580.Muscholl, A., 2016, July, July. Petri nets. http://www.labri.fr/perso/anca/FDS/Pn-ESTII.pdf. URL http://www.labri.fr/perso/anca/FDS/Pn-ESTII.pdf.Nielsen, M., Thiagarajan, P.S., 1984. Foundations of Software Technology and Theoretical Computer Science: Fourth Conference, Bangalore, India December 13–15,

1984 Proceeding. Springer Berlin Heidelberg, pp. 89–117 Degrees of non-determinism and concurrency: a Petri net view.Noran, O., et al., 2004. Uml vs IDEF: an ontology-oriented comparative study in view of business modelling. In: Seruca, I. (Ed.), Proceedings of the Sixth International

Conference on Enterprise Information Systems (ICEIS), pp. 674–682.Peterson, J.L., 1981. Petri Net Theory and the Modeling of Systems. Prentice-Hall, Inc., Englewood Cliffs, NJ.Petri, C., 1966. Communication with automata. Technical Report RADC-TR-65-377. vol. 1 New York: Griffiss Air Force Base.Piera, M.À., Narciso, M., Guasch, A., Riera, D., 2004. Optimization of logistic and manufacturing systems through simulation: a colored Petri net-based methodology.

Simulation 80 (3), 121–129.Pitt, L.F., Watson, R.T., Kavan, C.B., 1995. Service quality: a measure of information systems effectiveness. MIS Q. 173–187.Raedts, I., Petkovic, M., Usenko, Y.S., van der Werf, J.M.E., Groote, J.F., Somers, L.J., 2007. Transformation of BPMN models for behaviour analysis. In: Modelling,

Simulation, Verification and Validation of Enterprise Information Systems, Proceedings of the 5th International Workshop on Modelling, Simulation, Verificationand Validation of Enterprise Information Systems, MSVVEIS-2007, in conjunction with ICEIS 2007, Funchal, Madeira, Portugal, June 2007, pp. 126–137.

Reisig, W., 2013. Understanding Petri Nets: Modeling Techniques, Analysis Methods, Case Studies. Springer Publishing Company, Incorporated.Roos-Frantz, F., Binelo, M., Frantz, R.Z., Sawicki, S., Basto-Fernandes, V., 2015. Using Petri nets to enable the simulation of application integration solutions con-

ceptual models. In: 17th International Conference on Enterprise Systems (ICEIS). SCITEPRESS, Barcelona (Spain), pp. 87–97.Rosemann, M., Recker, J., Indulska, M., Green, P., 2006. A Study of the Evolution of the Representational Capabilities of Process Modeling Grammars. In: Advanced

Information Systems Engineering: 18th International Conference, CAiSE 2006, Luxembourg, Luxembourg, June 5–9, 2006. Proceedings. Springer BerlinHeidelberg, Berlin, Heidelberg, pp. 447–461.

Silva, J.R., Del Foyo, P.M.G., 2012. Petri Nets - Manufacturing and Computer Science. Intech: Science, Technology and Medicine Open access Publisher Timed Petrinets.

Smith, K., Smith, L.M., 2003. Tools and techniques for documenting accounting systems. Intern. Audit. 18 (5), 38–45.Thomas, R.K., Sandhu, R.S., 1998. Task-based authorization controls (TBAC): a family of models for active and enterprise-oriented authorization management. In:

Database Security XI. Springer, pp. 166–181.Van der Aalst, W., Van Hee, K., 1996. Business process redesign: a Petri-net-based approach. Comput. Ind. 29 (1), 15–26.van der Aalst, W.M., Stahl, C., 2011a. Modeling Business Processes: A Petri Net-oriented Approach. MIT Press.van der Aalst, W.M.P., et al., 1997. Verification of workflow nets. In: Seruca, I. (Ed.), Application and Theory of Petri Nets 1997, 18th International Conference,

ICATPN ’97, Toulouse, France, June 23–27, 1997, Proceedings, pp. 407–426. http://dx.doi.org/10.1007/3-540-63139-9_48.van der Aalst, W.M.P., 1998. The application of Petri nets to workflow management. J. Circuits, Syst. Comput. 8 (1), 21–66. http://dx.doi.org/10.1142/

S0218126698000043.van der Aalst, W.M.P., 1999. Formalization and verification of event-driven process chains. Inf. Softw. Technol. 41 (10), 639–650. http://dx.doi.org/10.1016/S0950-

5849(99)00016-6.van der Aalst, W.M.P., 2000. Workflow verification: finding control-flow errors using Petri-net-based techniques. In: Business Process Management, Models,

Techniques, and Empirical Studies, pp. 161–183.van der Aalst, W.M.P., Stahl, C., 2011b. Modeling business processes - a Petri net-oriented approach. Cooperative Information Systems Series. MIT Press. http://

mitpress.mit.edu/books/modeling-business-processes.van der Aalst, W.M.P., ter Hofstede, A.H.M., Kiepuszewski, B., Barros, A.P., 2003. Workflow patterns. Distrib. Parallel Databases 14 (1), 5–51. http://dx.doi.org/10.

1023/A:1022883727209.van der Aalst, W.M.P., van Dongen, B.F., Günther, C.W., Rozinat, A., Verbeek, E., Weijters, T., 2009. Prom: the process mining toolkit. In: Proceedings of the Business

Process Management Demonstration Track (BPMDemos 2009), ULM, Germany, September 8, 2009, . http://ceur-ws.org/Vol-489/paper3.pdf.


53















http://dx.doi.org/10.1007/978-3-642-00899-3

http://ceur-ws.org/Vol-1295/paper21.pdf














http://www.regulationsbiologie.de/pdf/BlaetkeTutorial.pdf

http://www.regulationsbiologie.de/pdf/BlaetkeTutorial.pdf







http://www.labri.fr/perso/anca/FDS/Pn-ESTII.pdf

http://www.labri.fr/perso/anca/FDS/Pn-ESTII.pdf


























http://dx.doi.org/10.1007/3-540-63139-9_48

http://dx.doi.org/10.1142/S0218126698000043

http://dx.doi.org/10.1142/S0218126698000043

http://dx.doi.org/10.1016/S0950-5849(99)00016-6

http://dx.doi.org/10.1016/S0950-5849(99)00016-6



http://mitpress.mit.edu/books/modeling-business-processes

http://mitpress.mit.edu/books/modeling-business-processes

http://dx.doi.org/10.1023/A:1022883727209

http://dx.doi.org/10.1023/A:1022883727209

http://ceur-ws.org/Vol-489/paper3.pdf

van der Aalst, W.M.P., Weijters, A.J.M.M., 2005. Process mining. In: Process-aware Information Systems: Bridging People and Software Through Process Technology.Wiley. http://eu.wiley.com/WileyCDA/WileyTitle/productCd-0471663069.html.

van Hee, K.M., 1994. Information Systems Engineering: A Formal Approach. Cambridge University Press.Verbeek, H., van der Aalst, W., 2005. Analyzing BPEL processes using Petri nets. In: Florida International University, pp. 59–78.Verghese, T., 1988. A formalization of internal control evaluation. Ph.D. thesis. Columbia University.Wakefield, R.R., Sears, G.A., 1997. Petri nets for simulation and modeling of construction systems. J. Constr. Eng. Manag. 123 (2), 105–112.Wegrzyn, A., Karatkevich, A., Bieganowski, J., 2004. Detection of deadlocks and traps in Petri nets by means of Thelen's prime implicant method. Int. J. Appl. Math.

Comput. Sci. 14 (1), 113–121.Weigand, H., Elsas, P., 2012. Model-based auditing using REA. Int. J. Account. Inf. Syst. 13 (3), 287–310.Wohed, P., van der Aalst, W.M.P., Dumas, M., ter Hofstede, A.H.M., Russell, N., 2006. On the suitability of BPMN for business process modelling. In: Business Process

Management, 4th International Conference, BPM 2006, Vienna, Austria, September 5–7, 2006, Proceedings, pp. 161–176. http://dx.doi.org/10.1007/11841760_12.

Yamalidou, K., Moody, J., Lemmon, M., Antsaklis, P., 1996. Feedback control of Petri nets based on place invariants. Automatica 32 (1), 15–28.Yourdon, E., 2003. Modern Structured Analysis. Prentice Hall India.Zhang, C., Tam, S., Zhou, K., Yue, X., 2014. Research on workflow model based on Petri net with reset arcs. In: Cao, B.-Y., Nasseri, H. (Eds.), Fuzzy

Information & Engineering and Operations 449 Research &Management. Advances in Intelligent Systems and Computing, vol. 211. Springer-Verlag BerlinHeidelberg, pp. 449–456.

Zimmermann, A., 2008. Stochastic Discrete Event Systems: Modeling, Evaluation, Applications. Springer Berlin Heidelberg New York.Zurawski, R., Zhou, M., 1994. Petri nets and industrial applications: a tutorial. IEEE Trans. Ind. Electron. 41 (6), 567–583.


54

http://eu.wiley.com/WileyCDA/WileyTitle/productCd-0471663069.html








http://dx.doi.org/10.1007/11841760_12

http://dx.doi.org/10.1007/11841760_12








Documents

International Journal of Accounting Information …...R. Kim et al. International Journal of Accounting Information Systems 27 (2017) 30–54 31 In this paper we ﬁrst provide the