ControlML: A domain-specific modeling language in support of assessinginternal controls and the internal control system

David Heisea,∗, Stefan Streckerb, Ulrich Franka

aEnterprise Modelling Research Group, University of Duisburg-Essen, 45141 Essen, GermanybInformation Systems Development Research Group, University of Hagen, 58084 Hagen, Germany

Abstract

In this paper, we refine and extend an earlier language design to introduce a domain-specific modeling

language (DSML) for internal controls modeling as an extension to an enterprise modeling method. The

language is aimed at supporting the assessment of a firm’s internal control system through the use of

conceptual models of internal controls. In the paper, we report on the design of the modeling language, on

its integration with the enterprise modeling method, present the language specification, and discuss language

applications in the context of the assessment of an internal control system.

Keywords: Internal control, Internal Control System, Assessment of Internal Controls, Conceptual

Modeling, Enterprise Modeling, Language Design, Domain-Specific Modeling Language, Design Science

Research

1. Introduction

The task of assessing a firm’s internal control system is beset by remarkable challenges: In addition to

the challenges posed by the sheer number of controls and their possible interactions, internal controls affect

the organization at different levels, refer to a multitude of resources and assets, and address a variety of risks

(Maijoor, 2000; Crawford and Stein, 2002). Hence, an assessment of the internal control system requires an

in-depth understanding of a firm’s business, the risks it faces and the controls it has put in place to treat risk

exposure at all relevant organizational levels. That understanding in turn implies an understanding of entity

objectives, business processes, organizational resources, structures, roles, and responsibilities (Rikhardsson

et al., 2006; Elder et al., 2010). Accordingly, the assessment task involves stakeholders with different profes-

sional backgrounds and perspectives on internal control matters including executives, line managers, process

owners, risk managers, internal and external auditors (Spira and Page, 2002). In this respect, the inherent

complexity is intensified by differing mindsets, diverging professional languages, and the resulting barriers

to communication.

∗Corresponding author: phone +49 201 183-2719; fax +49 201 183-4011Email addresses: david.heise@uni-duisburg-essen.de (David Heise), stefan.strecker@fernuni-hagen.de (Stefan

Strecker), ulrich.frank@uni-duisburg-essen.de (Ulrich Frank)

Preprint submitted to International Journal of Accounting Information Systems July 19, 2013

To cope with these challenges, methods and instruments are required that purposefully reduce the com-

plexity inherent in the assessment of an internal control system and that facilitate communication about

internal control matters among diverse groups of stakeholders. Although business process models have long

been used to support the task, it has repeatedly been established that present business process modeling

approaches provide only limited support for assessing the internal control system. A comparative evaluation

study reviews prevalent business process modeling notations in the light of key domain requirements and

concepts and concludes that the studied approaches do not provide the required modeling constructs for the

assessment and raises the demand for constructs that specifically express the semantics of internal controls

(Carnaghan, 2006). Dunn (2006) in a commentary on the last study adds that present approaches do not

provide support for the appropriate representation of the relevant organizational context of internal controls

(i. e., entity objectives, business processes, organizational resources, structures, roles, and responsibilities).

Such concepts are, however, common to enterprise modeling approaches such as ARIS (Scheer, 1992), SOM

(Ferstl and Sinz, 1998) and MEMO (Frank, 2012) which provide further abstractions of the enterprise and

its organizational action systems (i. e., modeling constructs to create conceptual models representing, for

example, organizational resources, structures, roles, and responsibilities). While current enterprise modeling

approaches do provide support for aspects of the enterprise in demand when supporting the assessment of

internal controls, research on domain-specific modeling languages (DSMLs) for representing internal con-

trols and internal control systems in the context of enterprise modeling approaches has—as far as we are

aware—been limited to early language design prototypes yet.

These observations have inspired our research on a dedicated DSML for internal controls modeling. The

present work follows a design science research process to develop such a DSML, ControlML, as extension

to an enterprise modeling method. In the paper, we refine and extend an earlier language design, report

on its integration with the enterprise modeling method, present the language specification, and apply the

language to demonstrate its practical use for assessing internal control systems.

The next section relates the present research to prior work on internal controls modeling. Section 3 com-

ments on the research method. Design objectives, requirements, and essential assumptions are established in

Section 4. Section 5 outlines the theoretical and conceptual background informing the language design. The

structural specification of the language, its meta model, is discussed in Section 6. A prototypical language

application is devised in Section 7. The paper concludes with a discussion and an outlook on paths for

future research in Section 8.

2. Related work

Among the first research on internal controls modeling is that of Karagiannis et al. (2007). In their ap-

proach, three SOX-related modeling concepts—Control, Risk, and Account—are introduced as an extension

2

to an enterprise modeling approach and a corresponding modeling tool. Language concepts are specified

by a meta model (see also Karagiannis, 2008, p. 1164) and related to further concepts for risk management

such as Event and Action. Interpretation of the semantics of modeling concepts is, however, partly left to

the language user, as the meta model does not show attributes and the accompanying documentation does

not offer further details. Moreover, important aspects of the design of a DSML are only briefly discussed,

for instance, a notation and corresponding diagram types. In a series of papers, Namiri and Stojanovic

(2007a,b) identify additional domain concepts (e. g., Control Objective, Risk Assessment, Authority), and

visualize conceptual relationships in a UML class diagram notation (Namiri and Stojanovic, 2007b, p. 63).

Their “domain model” structures the technical terminology in the auditing domain with the intention to

“formulate logical statements representing the controls constraining the behavior of a Business Process”

(Namiri and Stojanovic, 2007b, p. 62). However, the domain model does not specify the details (i. e., syn-

tax and semantics) of a DSML and nor does it account for further modeling concepts pertaining to the

organizational action system surrounding internal controls.

With a different focus on internal controls modeling, Sadiq et al. (2007) interpret controls in terms of

rules and target rule-based compliance checking based on automated reasoning (for related approaches,

see e. g., Governatori et al., 2006, 2008). In contrast to the present work, models of controls and business

process models are kept separate for pragmatic reasons: “prematurely load[ing] business process models

with compliance controls will be highly problematic from a practical standpoint” (Sadiq et al., 2007, p. 151).

Their approach starts from textual descriptions of controls in terms of normative statements such as “The

creation and approval of purchase orders must be undertaken by two separate purchase officers”. The

textual descriptions of internal controls are transformed into formal representations based on a modal logic

to be used to reason on compliance violation (Lu et al., 2007, 2008). A procedure to link the logic-based

statements about internal controls to process models is described, so that clauses appear as annotations of a

process model. Further rule-based approaches to modeling internal controls include the work on a PROLOG

implementation by Bailey, Jr. et al. (2000) and on a Petri net-based online auditing tool aimed at rule-based

compliance verification (van der Aalst et al., 2011). Petri nets have earlier been discussed as a means to

document business processes and corresponding internal controls also aiming at algorithmic verification of

compliance (Pitthan and Philipp, 1997; Chen and Lee, 2003). In a related approach, Weigand and Elsas

(2012) propose to derive internal controls from REA models based on an axiomatic foundation.

In summary, a rich body of literature contributes to modeling internal controls. However, prior work has

not closely examined the syntax and semantics of domain-specific modeling concepts for internal controls

modeling. Nor does any previous research deal with the intricacies of the reuse of concepts in the context of

enterprise modeling and of extending present enterprise modeling approaches with domain-specific concepts

for internal controls modeling. Based on the preliminary results of this ongoing research project (Strecker

et al., 2010, 2011a), the present work refines and extends an earlier tentative language design to introduce a

3

DSML for internal controls modeling as extension to an enterprise modeling method. Present rule-based and

formal approaches complement the conceptual modeling approach presented in this work with conceptual

models seen as a prerequisite to further automation. This brief analysis of the current state-of-the-art guides

our research on domain-specific modeling constructs in support of the assessment of internal controls.

3. Research method

The artifact designed in this research is a (domain-specific) modeling language; a linguistic artifact

consisting of an abstract syntax (represented as a meta model), a concrete syntax (a corresponding graphical

notation) as well as explanations of the intended semantics of language concepts in natural language (Wand

et al., 1995; Wand and Weber, 2002; Frank, 2002). The present work is based on a research method

configured for the epistemological particularity of research on modeling languages (Frank, 2006b). The

method is informed by fundamental thoughts rooted in the philosophy of language, such as the dilemmas

arising when attempting to evaluate an (artificial) language (Frank, 2006a). It has been refined over the

past 15 years (see Frank, 1998, for further historical context) and constitutes the methodological foundation

for long running design science research projects of which the present work is part (see Frank, 2012, for an

overview of projects and Strecker et al., 2011b, 2012, for recent research results). In the light of idealized

design science research processes (e. g., Verschuren and Hartog, 2005; Peffers et al., 2007; Geerts, 2011),

the present work reports on the activities of defining design objectives (Section 4), design and development

(Sections 5 and 6), and demonstration (Section 7) besides the previous problem identification and motivation.

The concluding section addresses further research activities, for example, those relating to the evaluation of

the artifact.

This work targets integration with an enterprise modeling method to benefit from reuse of existing and

mature modeling concepts and procedural guidelines. Developing a DSML in this context presupposes re-

constructing technical terms of the targeted domain and their (perceivable) semantics (Ortner, 2008; Frank,

2010). One widespread approach to conceptual reconstruction—and that followed here—is to review, ana-

lyze, and interpret pertinent literature in the field under consideration (e. g., Gelinas et al., 2004; Dunn et al.,

2005a; Davis et al., 2007; Moeller, 2008; Elder et al., 2010). Reconstruction of a professional terminology is

an iterative process involving more than the identification of candidate (meta) concepts, their attributes and

relations. Instead it requires the identification and resolution of terminological ambiguity and truncation,

for instance, which may imply the introduction of additional abstractions. That in turn requires the shaping

of their intended semantics, and leads to designing abstractions (i. e., language concepts) appropriate for

domain-specific analyses and applications based on deliberate design decisions. The underlying research

method is therefore driven by devising and analyzing domain-specific use scenarios describing, among other

things, prototypical model-based analyses in the intended use context (Frank, 2013).

4

4. Design objectives, requirements and assumptions

The overarching objective of the design science research project in which ControlML and further

DSMLs were developed is to devise a comprehensive modeling method for governance, risk, and compliance

(GRC). The primary objective of the design of ControlML is to effectively and efficiently support stake-

holders when performing an assessment of the internal control system. More specifically, this research is

aimed at supporting stakeholders interpreting internal controls and the surrounding organizational action

system when assessing the internal control system. Given that an understanding of the internal control

system is educed in group processes (Damianides, 2005, p. 79), its purpose is to support group processes by

reducing the complexity inherent in internal control systems and by providing abstractions tailored to the

perspectives of stakeholders involved. Consequently, this work is aimed at fostering and facilitating commu-

nication and collaboration among stakeholders participating in the assessment, and particularly addressing

interaction between auditor and auditee. It also aims to increase the transparency of internal control mat-

ters, specifically by visually representing internal controls as part of the organizational action systems, and

by improving traceability of the controls in place to treat risk exposure. These high-level requirements—

reducing complexity, fostering communication and collaboration, and improving transparency of internal

control matters—are refined to establish the subsequent requirements a DSML aimed at supporting internal

controls modeling should satisfy (see also Strecker et al., 2011b):

R1 A DSML should link internal controls to the surrounding organizational action system composed of all

organizational entities relevant to the assessment. This organizational context is provided by (at least)

entity objectives, business processes, business risks, performance measures, organizational resources,

structures, roles and their responsibilities (Carnaghan, 2006, p. 177). Rationale: The organizational

context in which an internal control is designed to be used is of particular importance to its accurate

interpretation (Sutton and Hampton, 2003; Spira and Page, 2002). Providing explicit and qualified

relationships between controls and organizational context by way of a DSML is seen as both contributing

to reducing complexity, and improving transparency of internal control matters.

R2 A DSML should account for relationships among internal controls on different organizational levels,

from IT operations to business processes to value chains to the organization as whole. Rationale:

PCAOB Auditing Standard No. 5 and other regulations assume relationships between internal controls

as expressed, for instance, by a control hierarchy (Gelinas and Dull, 2010, p. 241). Relations between

internal controls need not, however, be strictly subordinate. Rather, controls relate to each other in often

case-specific ways as exemplified, for example, by diverse taxonomies of controls (Dunn et al., 2005a,

p. 455). Explicit and qualified relationships among controls as part of a DSML promise to improve the

transparency of internal control systems and, specifically, the interrelations between internal controls.

R3 A DSML should account for the multiplicity of means to achieve control objectives and of the resulting

5

variety of internal control implementation. Rationale: A wide spectrum of ways to achieve control

objectives employing a multitude of different organizational measures including policies and procedures,

manual and automated controls is discussed (Gelinas and Dull, 2010; Elder et al., 2010). Providing

appropriate abstractions of control means by means of a DSML is seen as a contribution to improving

the transparency of internal control matters, and to reducing the complexity of internal control systems.

R4 A DSML should provide means for justifying the existence and relative importance of an internal control

and for revealing assumptions underlying internal control justification. Rationale: It has repeatedly been

suggested to foster communication and collaboration on internal control matters by annotating assertions

underlying the control specification and its intended usage (Carnaghan, 2006, p. 177). It is assumed

that by providing a traceable rationale of an internal control, accurate interpretation of internal controls

will be fostered and communication barriers among stakeholders lowered.

R5 A DSML should provide meaningful representations of internal controls and internal control systems

to satisfy the needs of affected groups of prospective users. To foster an intuitive use, representations

should, as far as possible, correspond with abstractions, concepts and (visual) representations known and

meaningful to the targeted group of stakeholders. Moreover, a DSML should provide means to integrate

the various perspectives with each other. Rationale: The assessment process involves stakeholders with

different professional backgrounds. To foster communication among these stakeholders, a DSML needs

to support the perspectives of different (groups of) stakeholders into account.

It is assumed that satisfying these requirements will ensure the high-level requirements and the design

objective will be met. That in turn implies that hypotheses underlie the relationships between higher and

lower level requirements. It is, for example, assumed that if a modeling language supports integrated per-

spectives tailored to the needs of stakeholders involved in the assessment of internal controls, communication

barriers are lowered and collaboration among stakeholders with different professional backgrounds is facil-

itated. In other words, the language positively contributes to approaching the primary design objective.

In this regard, the identified requirements and the design goals guide the design of the modeling language,

ControlML.

5. Theoretical and conceptual background

Research on ControlML builds on a method for enterprise modeling, the “Multi-Perspective Enterprise

Modeling” (MEMO) method researched and applied since the early 1990s (Frank, 1994). The rationale for

choosing the MEMO method (subsequently referred to as MEMO) over other enterprise modeling approaches

such as, for example, ARIS (Scheer, 1992) is based on several considerations: (1) MEMO provides an

extensive set of modeling constructs relevant to designing a language for internal controls modeling, including

the modeling of organizational goals, units, roles, responsibilities, and resources; (2) MEMO is based on a

6

instance of

< A/R Manager >

Authorize Credit

< Smith, John D. >

Authorize Credit #6110840A4

started: 2012-09-24 09:45completed: 2012-09-24 10:04

< Smith, John D. >

Authorize Credit #7781085C9

< Miller, J.-A. >

Authorize Credit #....

started: ...completed: ...

Met

a Le

vel /

M2

Type

Lev

el /

M1

Inst

ance

Lev

el /

M0

Appl. Server #01

Serial-No.: PX118D-07DInstalled: 2007-07-15

Appl. Server #02

Serial-No.: ...Installed: ...

Financial eTransactionApplication Server

Instance

Type

Business Processname : StringorganisationalUnit : String

Servername : Stringtype : {application, database, file}

Meta TypeInternal Control

designator : Stringdescription : StringisPreventive : Boolean

Internal Control: „IO 3.3: Prevent unauthorized refund“Description: Demands a segregation of duties in the

refund business process, i.e., a separate authorization of the refund

isPreventive: true

Conducted at: 2012-09-24 13:45Responsible person: Smith, John D.

Conducted at: ...Responsible person: ...

Conducted at: ...Responsible person: ...

started: ...completed: ...

Figure 1: Essential levels of abstraction in the MEMO language architecture: Instance, Type and Meta Type [@Publisher:

Please use colored figures for web and black/white-figures for print (the latter are provided in separate files marked with the

extension “bw”)]

meta modeling approach whose language architecture is extensible through DSMLs (Frank, 2011d) and

is complemented by guidelines and a process model aimed at the design of the respective DSML (Frank,

2010); and (3) in contrast to proprietary approaches, the specification of the MEMO method—especially

its language architecture, meta modeling language, and most language specifications—are publicly available

(Frank, 2012).

In MEMO, DSMLs are specified by a meta model, a corresponding graphical notation and accompanying

descriptions of language concepts and of intended semantics of modeling concepts in natural language. Thus,

a language specification is semi-formal as it comprises formalisms (i. e., the meta model and visual language)

and informally specified artifacts (i. e., verbal descriptions for those aspects of the language design that

should not or cannot be expressed (solely) through formal means based on a deliberate design decision).

The MEMO Meta Modeling Language (MEMO MML) and the MEMO language architecture serve as meta

modeling foundation for the design of ControlML. The language designer specifies modeling concepts of

the DSML (i. e., meta types) at the meta level—referred to as the M2 level in OMG terminology (see Fig. 1).

These meta types (e. g., Business Process) are instantiated by the language user (modeler) to types at the

type level (M1). Note that the MEMO MML is defined at the meta-meta or M3 level omitted from Fig. 1

(Frank, 2011d).

Building on the MEMO MML for defining language concepts of a DSML fosters the integration of

modeling languages. DSMLs are specified using the same meta modeling language, which enables the

7

language designer to reuse meta types already specified in a MEMO modeling language. Sharing common

concepts at the meta level (e.g., Business Process) leads to integrated models at type level, for example,

a business process model integrated with an organization structure model, with a model of IT assets, and

with a model of internal controls. Moreover, the reuse of existing modeling concepts promises to increase

the productivity of both language design and language application: Language designers benefit from mature

language concepts and notations and can focus on relevant additions and modifications at the meta level;

modelers and language users benefit from the reuse of existing models at type level (e. g., reuse of business

process models) and can focus on extending or refering to these models. Figure 2 illustrates the integration

of type level models in MEMO and shows diagram types provided by MEMO for different perspectives on an

organization from a strategic management perspective (a strategy net, goal system or value chain diagram)

to a business operations perspective (business process map, business process diagram, organization chart

diagram) to an IT operations perspective (an IT resource diagram or an object model). Each modeling

language in MEMO provides a set of language concepts for the aspects the language focuses on and that can

be reused in other MEMO modeling languages. Of particular importance for internal controls modeling are

(1) concepts for modeling organizational structure (to assess internal control scope); (2) business processes

and organizational resources (to determine the organizational action system surrounding an internal control);

(3) organizational goals, objectives and performance indicators (to analyze internal controls with respect to

entity objectives); (4) risk and impact in case of risk occurrence (to provide a rationale for control existence).

In this regard, a kernel of DSMLs and concepts is provided by MEMO: The organization modeling lan-

guage (MEMO OrgML; Frank, 2011c) specifies concepts for modeling business processes and organizational

structures (e. g., Process, Event, and Organisational Unit) and dedicated diagram types (e. g., a business

process diagram detailing the control flow of a process) (Frank, 2011a,b,c). The goal modeling language

(MEMO GoalML; Kohling, 2012) provides concepts for modeling organizational goal systems (e. g., Ab-

stract Goal, Accountability Relation). The strategy modeling language (MEMO SML) provides high-level

abstractions commonly referred to at the senior management level, for example, concepts for creating value

chain diagrams (e. g., Value Chain Activity). The IT modeling language (MEMO ITML; Frank et al., 2009)

allows the modeling of IT assets (e. g., Information System) and associations to the business processes they

are used in, among others.

The MEMO kernel of languages has been extended by DSMLs to support further analyses in various

application domains. Two extensions to the kernel are indicated at the right-hand side of Figure 2: The risk

modeling language (MEMO RiskML) provides concepts such as Risk and Effect Specification and diagram

types like the shown risk diagram which accounts for interrelations among risks (Strecker et al., 2011b).

The performance measurement language (MEMO MetricML) introduces concepts such as Indicator and

an indicator system diagram type in support of the reflective design and use of performance measurement

8

Goa

l Sys

tem

Dia

gram

Stra

tegy

Net

Valu

e Ch

ain

Dia

gram

Busi

ness

Pro

cess

Dia

gram

Org

aniz

atio

nal C

hart

title : String

create

d : D

ate

sideRatio: Rat

io

Slide

getC

onte

nt()

conte

nt: XM

LString

Te

xt

caption : String

Gra

phics

getA

rray

()

numberO

fRows : Inte

ger

numberO

fCols : Inte

ger

Tab

le

getV

ideo()

video: Video

desc

ription

Vid

eo

Qu

est

ion

Op

en

Qu

est

ion

Ch

oic

e

Cit

atio

ntitle : String

...Publica

tion

groupW

ork

 : Boolean

timeFr

ame : In

tege

r

Ass

ign

me

nt

war

ning : B

oolean

emphas

is : Inte

ger

Ad

vice

Form

ula

He

ad

lin

eFo

otl

ine

Logo

getG

raphics()

figu

re: Gra

phics

Gra

ph

ics

Diagra

m

getD

iagr

am()

visu

alis

ationTyp

e: D

iagr

amD

ata

Dia

gra

m

staticRepre

senta

tion: Gra

phics

type: D

iagr

am

Co

nce

ptu

alD

iagr

am

nam

e : String

Mo

de

llin

gLan

gua

ge

Master

Frame

effect: A

nim

ationTyp

eonEve

nt: Eve

ntT

ype

An

ima

tio

n

0..*

0..1

1..*

1..*

lineColour: Colour

Gra

phicsO

bject

Co

mp

ose

dFi

gure

Cir

cle

Re

ctan

gle

fillC

olour: Colour

relW

idth

: Percenta

gere

lHeight: Percenta

gere

lPosition: Coord

inate

Region

star

tPosition: Coord

inat

eendPosition: C

oord

inate

Lin

e

desc

ription: String

sourceID

: String

pro

toco

l: String

inputP

ara

mList: XM

LString

resu

lt: X

MLS

tring

Inte

rfac

e

obta

ins data

 fro

m

includes

includes

includes

includes

0..*

0..1

0..1

0..1

0..*

0..*

0..10..*

updat

e()

Fra

me

getT

itle() : String

Ch

ap

terS

lid

e

getT

itle() : String

Tit

leSl

ide

title : String

Re

gula

rSli

de

description : St

ring

creat

ed : Dat

etitle : String

subTitle : String

Pre

senta

tion

getC

hap

terN

o() : In

tege

rtitle : String

Ch

apte

r

Stru

ctu

red

Pre

sen

tati

on

Sim

ple

Pre

sen

tati

on

getSlid

eNo() : In

tege

r

Pro

xySl

ide

succ

essor 

of

0..1

0..1

1..1

0..*

starts with

starts with

0..*

1..1

lastNam

e : String

firstN

ame : String

Au

tho

r

1..*

0..*create

d

starts with

0..*

1..1 0..1

0..1

repre

sents

1..1

0..*

1..1

1..1

repre

sents title of

repre

sents title of

1..1

1..1

titleBack

ground: C

olour

chap

terB

ackg

ound: Colour

titleFo

nt: Font

regu

larF

ont: Font

headlin

eFo

nt: Font

footlineFo

nt: Font

...

Pre

sen

tati

on

Styl

e

headlin

eFo

nt: Font

footlineFo

nt: Font

...

Slid

eSt

yle

inherits from

0..*

0..*

0..1

0..*

defines layo

ut of

0..*

0..1

icon: Gra

phics

...Fr

ameSt

yle

creat

ed : Dat

ere

gularB

ackg

round: Colour

font: Font

fontC

olour: Colour

Style

...Qu

est

ion

Fra

me

Styl

e

0..*

inherits from

Inherits fro

m

0..*

0..1

0..1

defines layo

ut of

defines layo

ut of

defines layo

ut of

0..1

0..*

0..1

0..*

succ

essor of 

...Ass

ign

me

ntF

ram

eSt

yle

0..1

0..*

defines layo

ut of

relW

idth

: Percenta

gre

lHeight: Percenta

gere

lPosition: Coord

inate

Abstra

ctFrame

varian

t of

0..1

0..*

varian

t of

0..1

0..*

varian

t of

0..1

0..*

view on

instance of

name : String

Mo

de

l

1..1

0..*

1..*

0..*

creat

ed : D

ate

chapte

rFont: Font

head

lineFo

nt: Font

footlineFo

nt: Font

...

Ch

apte

rSty

le

Obj

ect M

odel

IT R

esou

rce

Dia

gram

Busi

ness

Pro

cess

Map

Risk

Dia

gram

Indi

cato

r Sys

tem

Dia

gram

Dia

gram

s of

cor

e M

EMO

lang

uage

sD

iagr

ams

of e

xten

sion

s to

MEM

O

Figure 2: Integration of DSMLs in the MEMO method

9

<AttributeName> ':' <EntityName>|<TypeName><AttributeName><AMultiplicity> ':' <EntityName>|<TypeName>

<AttributeName> ':' <EntityName>|<TypeName>

<EntityName>

<Multiplicity>

<EntityName>

<Multiplicity>

<Designator>

<EntityName>

<#><String>

(Abstract Meta Type – The italic header characterizes the Meta Type as abstract, i.e., it

cannot be instantiated)

Constraint – describes particular constraints that have to be valid for all instances of the meta type; can be described in natural language or, e.g., using the OCL

Meta Type – abstracts over a set of similar types and describes their structure in terms of attributes

Generalization/Specialization

<role>

Meta-Association – describes a relation between the two connected meta types; is further qualified by a designator, multiplicities and (optional) roles

i

Multiplicity (also: Cardinality) – describes to how much instances of this meta type one instance of the distant meta type is at minimum/at maximum is connected to

Role – describes the participation of this meta type in the association further

Attributes – Attributes are initialized upon instantiation of the meta type, i.e., they

are assigned a value; can (optional) have a multiplicity that describes the amount of

initializations

Intrinsic Attribute – are not initialized upon instantiation of the meta type like regular attributes, but one level further

down

Language – The colored rectangle serves as unique identifier for the modeling language this meta types origins from; hence the specification of the meta type can be found in the specification of the originating modeling language.

‘<<surrogate>>‘<EntityName>

<EntityName> <EntityName> <EntityName>

Surrogate – serves as a surrogate for various other meta types and, thereby, aims to reduce the complexity in the

visual represenation of the meta model (e.g., by reducing the amount of meta-associations in the meta model); a surrogate should always be used with exemplary meta

types the surrogate serves to abstract over Surrogate Relation – serves to describe exemplary meta types the surrogate serves to abstract over; note that the list of meta types is always exemplary, that is, not complete

Figure 3: Overview of key concepts and notation elements of the MEMO Meta Modeling Language (MEMO MML)

systems (Strecker et al., 2012). These modeling languages are integrated with each other through common

concepts at the meta level. For example, the concept of Process defined by the MEMO OrgML is reused in

the GoalML (which goals does a business process pursue?), in the ITML (where is an information system

used?), and in the RiskML (which business processes are affected by a certain risk type?). In Figure 2, the

integration of the modeling languages by sharing meta types is exemplarily indicated by the edges drawn

between the diagrams. In the meta models, the reuse of a concept originally specified in another MEMO

modeling language is indicated by a color-coded language identifier attached to the meta type. Figure 3

offers an overview of key concepts and notation elements of the meta modeling language, MEMO MML.

While at first, the MEMO MML looks similar to the UML MOF and UML class diagrams, it differs in

three respects (for a detailed comparision of MEMO MML and UML MOF, see Frank, 2011d): First, the

MEMO MML focuses on concepts necessary for meta modeling and, thus, does not come with the complexity

of a multi-purpose approach as, for instance, UML MOF. Second, as a dedicated meta modeling language,

the MEMO MML contains concepts which specifically provide possible solutions to known challenges in

meta modeling. And third, it has a specific graphical notation to support a clear visual distinction between

meta models on the one hand and models at type level (and, specifically, UML class diagrams) on the other.

10

6. Language Design: The MEMO Control Modeling Language (MEMO ControlML)

6.1. Terminological analysis

In auditing literature and practice, the terms “control”, “internal control”, and “internal control system”

are commonly used (Moeller, 2008). Despite their proliferation, the lack of a precise definition has repeatedly

been commented upon (Maijoor, 2000). The term “control” is subject to a considerable diversity of uses

and disciplines, for example, “management control, organisational control, internal controls, operational

control and financial control, which all seem to revolve around the same concept” (Rikhardsson et al., 2005,

p. 5). The auditing perspective on internal control is decisively influenced by the Committee of Sponsoring

Organizations of the Treadway Commission (COSO) (COSO, 1992, 2004) and subsequent auditing standards

such as the PCAOB Auditing Standard No. 5 (for a discussion see Maijoor 2000 and Rikhardsson et al.

2006): “COSO defines internal control as a process, effected by an entity’s board of directors, management

and other personnel. This process is designed to provide reasonable assurance regarding the achievement

of objectives in effectiveness and efficiency of operations, reliability of financial reporting, and compliance

with applicable laws and regulations. [. . . ] Internal control is not merely documented by policy manuals

and forms. Rather, it is put in by people at every level of an organisation. [. . . ]” (COSO 2010; adapted

from COSO 1992).

While this very broad conceptualization provides insights into essential domain-specific concepts (e. g.,

objectives, policy, reasonable assurance), it also points to terminological ambiguity: The concept of “internal

control” includes both, procedural (i. e., dynamic) aspects (i. e., business processes, auditing and monitoring

processes) and structural (i. e., static) aspects (e. g., policies, organizational structures, organizational roles).

It also links to other concepts such as risk or control objectives: “Enterprise risk management is a process,

[. . . ] designed to identify potential events that may affect the entity, [. . . ] to provide reasonable assurance

regarding the achievement of entity objectives” (COSO, 2004, p. 2). In fact, the COSO framework breaks

down “internal control” into five interrelated components: Control Environment, Risk Assessment, Control

Activities, Information and Communication as well as Monitoring (Gelinas and Dull, 2010, pp. 224–225). A

prevalent representation of “internal control” in auditing practice is the “control matrix” (Gelinas and Dull,

2010, p. 227) and its variants, for example, a (process and) control matrix which maps control objectives to

relevant control means grouped by business processes (Gelinas and Dull, 2010, p. 649).

A key domain concept is the control objective, sometimes also termed the control goal (Gelinas et al.,

2004, p. 249). It represents a desired state of an enterprise (e. g., “Prevent unauthorized refunds”) with

respect to achieving an entity objective (e. g., “Minimize error rate of incorrect refunds”) that is threatened

by a risk (e. g., “Internal fraud due to fraudulent behavior of employees”). A control objective is associated

with a recommended course of action that should be taken to provide reasonable assurance that entity ob-

jectives will be met and, thus, corresponding risks of not achieving it are mitigated. The course of action can

11

involve policies, procedures, practices, or organizational structures as concrete measures or means of control

implemented to ensure effectiveness of a control (Elder et al., 2010). An important means to prevent fraud

is “segregation of duties” (Gelinas and Dull, 2010, p. 255). This means of control is intended to achieve

the control objective and represents an abstraction over static means of control such as written policies

or organizational structures and dynamic means of control such as activities and processes. Alternative

denominators for the control means concept include “control activity” (IT Governance Institute, 2007) and

“control plan” (Gelinas et al., 2004, p. 249). Both terms, however, carry a significant risk of misinterpreta-

tion: The term “activity” raises associations with dynamic abstractions neglecting static aspects while the

term “plan” emphasizes a perspective other than the intended means-end association.

Examples of general control means given in COSO publications include the authorization of transactions

and adequate safeguarding of assets and records. The achievement of the desired outcome of a control

objective is measured by an indicator (e. g., “Percentage of fraudulent refund transactions”) as is the severity

of risk. Responsibilities, as in the RACI (responsible, accountable, consulted, informed)-conceptualization

suggested, e. g., by the IT Governance Institute (2007), are typically defined for more than one organizational

role (“executive”, “business process owner”, etc.) with respect to a control objective. It is important to

note that the monitoring and auditing of an internal control system (e. g., performed as internal control

assessment by an external auditor) are processes detached from the actual internal control system, in that

the system itself becomes subject to the audit (COSO, 2009).

These interpretations of domain terminology represent intermediate results of the conceptual reconstruc-

tion process which inform the subsequent language design. Further intermediate results of the reconstruction

process including a semantic net are discussed in Strecker et al. (2010, 2011a).

6.2. Specification of the ControlML

The language specification of the MEMO ControlML is composed of a meta model represented in

the MEMO MML, a respective graphical notation, and explanations of the intended semantics of language

concepts. The diagrammatic representation of the meta model is split into two figures to focus on different

aspects of the language design. In the following sections, we focus on the key elements of the modeling

language ControlML and discuss extensions to the earlier tentative language design (for a discussion of

alternative designs and a more elaborate rationale of design decisions see Strecker et al., 2011a, pp. 17ff.).

Fig. 4 presents the corresponding meta model excerpt of the ControlML with a focus on the language

kernel; a focus on integration of ControlML with the MEMO family of modeling languages is illustrated

in the meta model excerpt in Fig. 6 and discussed in Section 6.3.

The initial design decision with respect to the targeted domain pertains to the specification of language

concepts specifying an internal control type. It follows from the terminological analysis that the very

conception of “internal control” cannot be conceptualized as a singular concept as such, but rather as

12

description : StringinvolvementType : String

Control Involvement

recommendedAction : Stringassertion [0..*] : AssertionintendedEffect : {preventive,detective,corrective}isManual : Boolean

Control Means

intendedState : Stringexplanation : StringareaFS : FinancialStatementArea

Control Objective

haspertains to0..* 0..* 1..1

0..* 1..*

Reference Object

1..1

name : String

Control Category belongs to

specification : Stringorigin : PolicyProvider

Codification governed by

1..*

0..*

targets

supports

0..* 0..*0..*

0..*

real

ised

by

0..*C1

C1context Control Objective inv: self.ControlObjective->excludes(self)

0..*

Organisational Unit

Figure 4: Meta model of the MEMO ControlML with a focus on the language kernel (revised from Strecker et al., 2011a,

p. 20)

an abstraction over various concepts which in turn constitute an internal control. An essential design

decision has therefore been to represent an internal control by its control objective and by the means of

achieving the control objective. Hence, two dedicated meta types, Control Objective and Control Means,

are introduced (a similar kernel is proposed by Namiri and Stojanovic, 2007a; Karagiannis, 2008). The

rationale for introducing those two meta types is to enable dedicated model-based audit analyses based on

respective conceptual models of control objectives and control means. To account for essential requirements

(see Section 4), further refinements are, however, necessary and are detailed below. Three constituents

are central to the language specification (the meta model is shown in Fig. 4): (1) The Control Objective

language concept and the ancillary concepts Codification and Control Category ; (2) the Control Means

modeling concept; (3) the Control Involvement meta type.

Ad (1) Control Objective. The meta type Control Objective serves to describe the intentions connected with

an internal control. It is described by a natural language description of the desired state of control by

the attribute intendedState (“Prevent unauthorized refunds”) and by an explanation of the intended state,

explanation (“The billing system receives shipping items from the shipping system [. . . ]”). Annotating the

financial statement area, areaFS, links a control objective to financial reporting. The recursive supports

association between respective types allows to represent the internal control system as a hierarchy or net of

controls (see Fig. 5 for an example). Thus, it enables further analyses such as which IT controls relate to

which business controls. The ancillary language concept Codification specifies a legal regulation the control

objective is governed by and its originating policy provider. Feedback from practicing auditors advised

keeping track of these codifications (e. g., a certain clause in an auditing standard) and of the originating

policy provider (e. g., “PCAOB Auditing Standard No. 5”) as a contribution to justifying the existence

and importance of an internal control. The meta type Control Category allows the creation of customized

control taxonomies and the assignment of one or more categories to a control objective to support a flexible

13

categorization of internal controls, since in auditing practice there are different approaches to structuring

control objectives (e. g., Dunn et al., 2005b, pp. 441ff.).

Ad (2) Control Means. The Control Means language concept serves to describe the means to achieve rea-

sonable assurance. It is determined by the recommended course of action provided in a natural language

specification, recommendedAction. Such a specification might mention a written policy and corresponding

procedures (e. g., “The Accounting Supervisor makes copies of the checks and sends the check copies along

with the invoice hard copy supporting documentation to the Cash Application Department”). The current

conceptualization as shown in Fig. 4 aims to offer flexibility while, at the same time, maintaining a structure

for assessment purposes. The terminological analysis indicates that (1) multiple means exist that can be

deployed to achieve a control objective; (2) the same means can be reused by several control objectives; and

(3) a certain means can pertain to several structural and procedural elements and thus exhibit a “multidi-

mensional” characteristic (e. g., a written policy connected with a process “Authorize credit”). Due to the

chosen cardinality of the targets-relationship between the meta types Control Objective and Control Means,

it is possible to assign a multitude of means to one control objective; similarly, a control mean can be used

to support the achievement of different control objectives, thereby promoting the management and reuse

of control means in an organization. Following suggestions elicited from the literature, further semantics

is specified by assertion (what are assumptions underlying the function of a control means and what is its

rationale?) (Carnaghan, 2006, p. 177) and by classifying control means into preventive, detective or correc-

tive controls according to their effect in time relative to the occurrence of a risk, intendedEffect (Gelinas

et al., 2004, p. 253). Another characteristic is captured by a functional differentiation between manual and

automated control activities in isManual attribute.

Ad (3) Control Involvement. The Control Involvement modeling concept serves to describe the relation

between a control objective and an organizational unit. Since further types of involvement beyond RACI

are conceivable and to be expected (e. g., a “supports” involvement), Control Involvement is not limited to

these four types of involvement but allows organizations to define their own types of involvement—by means

of an involvementType and a description.

Figure 5 drafts a graphical notation of the ControlML and illustrates the internal control diagram

type. The diagram is based on the refund returned goods process drawn on by Carnaghan (2006, p. 200) and

is further enriched with exemplary controls reconstructed from the COBIT documentation (IT Governance

Institute, 2007). Different from other notational mappings, multiple meta types, Control Objective, Control

Means, Control Category, and Codification, map to a single graphical symbol (a rectangle with an “auditor’s

eye” attached). The rationale for this design decision is to provide a visual overview of (selected) internal

controls with this diagram type. Given respective tool support, the model user (e. g., an auditor) could then

14

Control Objective: Segregation of dutiesIntended State: Prevent unauthorized refundsRecommended Action: Separate authorization process for refunds above 500 €, signed by some different actorIntended Effect: preventiveis Manual: trueCategory: Business Control

Control Objective: User Account ManagementIntended State: No user has privileges that are not required for his current tasks.Explanation: Address requesting, establishing, issuing, suspending, modifying, and closing user accounts and […]Category: IT Control, Codification: COBIT, DS5.4supports

Control Objective: Network SecurityIntended State: No unauthorized information flows to and from networks are possible.Explanation: Use security techniques and related management procedures, e.g., firewalls, […]Regulation: COBIT, DS5.10

Control Objective: Management of IT SecurityIntended State: IT security is consistent with business requirements.Explanation: Manage IT security at the highest appropriate organisational level, so the management […]Regulation: COBIT, DS5.1

Control Objective: Identity ManagementIntended State: Every user can be uniquely identified.Explanation: Ensure that all users (internal, external, and temporary) and their activity on IT systems […]Category: IT Control, Codification: COBIT, DS5.3

supports

Internal Control Diagram

supports

Control Objective: Segregation of dutiesIntended State: Prevent unauthorized transactionsCategory: IT Control

Meta Type Control Objective

Meta Types Control Category & Codification

Recommended Action: With each change in the organizational structure and in the staffing, check for necessary modifications in the user accounts.Intended Effect: Preventiveis Manual: trueCo

ntro

l Mea

nsRecommended Action: Ensure different user access rights for refund transactionsIntended Effect: preventiveis Manual: false

Cont

rol M

eans

Recommended Action: After each software update it has to be checked, if the user accounts and their privileges are still validIntended Effect: Preventiveis Manual: true

Cont

rol M

eans

Meta Type Control Means

Figure 5: An internal control diagram showing internal controls and their interrelations as a visual system of internal controls

(based on the refund returned goods process drawn on by Carnaghan, 2006, 200 and further enriched with exemplary controls

reconstructed from the COBIT documentation).

navigate from such a high-level overview to viewing specific control objectives and have their control means

shown in another diagram type. Note that other graphical notations and diagram types are conceivable, for

instance, a tabular representation or a diagram type focusing on control means rather than control objectives

(showing which control objectives a control mean addresses). In particular, ControlML is designed to

assign different notational elements to the same modeling concept (e. g., to address specific perspectives of

particular groups of stakeholders) and to offer various diagram types for the same model (each with, e. g.,

different foci). Moreover, the formal foundation of the DSML allows for transforming the internal control

model into different forms of representation (e. g., a spreadsheet or a check list) to accommodate the specific

needs of groups of stakeholders.

6.3. Integration with the MEMO family of modeling languages with extensions for assessment of internal

controls

The ControlML is integrated with the MEMO family of modeling languages through reuse of common

language concepts (see Section 5). Figure 6 presents another aspect of the meta model showing how key

concepts of the ControlML integrate with concepts of other MEMO languages (marked by a colored

rectangle attached to a meta type).

The semantics of the Control Objective language concept is further refined by links to the entity objectives

that are the target of the control objective (Goal) and to indicators providing measurements related to the

control objective (Indicator). The Control Involvement modeling concept is refined to refer to organizational

roles (Organisational Role), so that roles defined in an organizational structure model can be reused for

15

C2

C3 context Control Means inv: self.ReferenceObject.BusinessProcess->notEmpty() implies

self.ReferenceObject.BusinessProcess->forAll( b : BusinessProcess | b->isOclTypeOf(AuditProcess).isEmpty() )

Indicator RiskControl Means

Organisational Role

Control Objective

Goal haspertains to

0..1

0..* 0..* 1..11..*

mon

itors

0..1

0..* 1..*measures

Information System Software

type : {manual, semi-autom., autom.}

Business Process Organisational Unit

OrgML ITMLGoalML RiskML

0..* 1..1

assures achievement of

mitigates

...

targets

MetricML

0..*0..* 0..* 0..*

Control Involvement

frequency : FrequencyTypescope : ScopeTypeisExternal : Boolean

Audit ProcessfrequencyType : {per instance, on demand, event driven, <timeUnit>}scopeType : {total, partial, sample}

Explanation of ControlML-specific attribute types

Symbols for concepts reused from other MEMO languages:

riskMeasure

<<surrogate>>Reference Object

real

ised

by 0..*

0..*

0..*affects

C3

C2 context Control Objective inv: self.ControlMeans.ReferenceObject->excludes( self.affectedEntity )

II

IIII

affectedEntity

0..*

measures

0..*

Figure 6: Meta model of the MEMO ControlML with a focus on integration with the MEMO family of modeling languages

(revised from Strecker et al., 2011a, p. 20; Rectangles “I” and “II” mark extensions discussed in Section 6.3)

internal controls modeling. The explicit association of risks (Risk) with control means enables further

analyses for auditing purposes. For instance, identifying risks without controls and vice versa (as proposed

by Spira and Page, 2002). Likewise, control means may be linked to indicators, Indicator, measuring the

outcome of actions associated with a particular control means.

Furthermore, the organizational context of an internal control is introduced by associating the Control

Means modeling concepts with those organizational entities (e. g., Business Process, Organisational Unit, In-

formation System) that may participate in implementing (or realizing) an internal control—thereby shaping

the semantics of control activities in terms of describing the organizational context the activity is executed

in. For this purpose, the surrogate concept Reference Object represents all modeling constructs relevant to

internal control assessment—with the intention of providing the necessary flexibility in modeling the means

of internal control (see Section 6.1). The present language specification allows, for example, to represent

the realization of a control means to achieve segregation of duties by referencing the two relevant business

processes (“Prepare credit” and “Authorize credit”) as well as the two organizational roles involved (“Sales

Account Manager” and “A/R Manager”).

Extending the earlier language design, the affects relation is introduced between Control Objective and

Reference Object. Besides representing the various organizational elements that realize a control means,

16

the meta type Reference Object is also used to represent the organizational entities that are affected by

an internal control (see Rectangle “I” in Fig. 6). For example, a business processes type affected by the

“segregation of duties” control or a server type affected by a “ensure correct user access rights” control.

Note that affected and realizing reference objects may coincide. Although this seems confusing at first,

the differentiation is necessary, since it enables analyses such as “which organizational elements are subject

to internal control?” (affects-association), “does an organizational element contribute to the realization of

an internal control?” (realised by-association) or “which organizational elements are affected by a control

objective but are missing a respective control means?” (comparison of affects- and realised by-association).

An example for this differentiation into affected and realizing reference objects is provided in Figure 7 in

Section 7: The control objective “Segregration of duties” (at the center of the diagram) affects the “Refund

returned goods” and, at the same time, is realized by the process “Authorize credit”.

A further extension pertains to the support for the modeling of auditing and monitoring processes. Audit

processes differ from business processes in that they are specifically designed to run outside of a firm’s regular

operations with the intention to control a particular audit object such as a business process, a record of

transactions etc. From a modeling perspective, however, audit processes exhibit characteristics of business

processes in that a certain regularity can be assumed as well as a temporal order of tasks producing events.

Hence, auditing and monitoring processes can, in principle, be represented using a business process modeling

language such as BPMN or, in context of enterprise modeling, the MEMO OrgML. We, therefore, propose

reusing and extending—that is, specializing—the Business Process concept specified in the MEMO OrgML

to an audit process subtype (see Rectangle “II” in Fig. 6). The semantics of the Audit Process modeling

concepts are further detailed by the particular frequency of process instantiation (i. e., at which intervals

is the process triggered?), the scope of its analysis (e. g., are all, only a part or a specific sample of the

instances of the audit object inspected?) and whether it is an external audit process. Specializing the generic

Business Process meta type leads to a particular advantage: Current diagram types, modeling techniques,

and implementations in modeling tools—optionally even the graphical notation—can be reused for modeling

audit processes. An example is shown in Fig. 7 where the audit process “Audit refund transactions and

detect irregularities” is represented using the regular business process notation symbol defined by the MEMO

OrgML. This reuse of familiar modeling concepts is assumed to foster the acceptance of audit process

modeling. The two OCL-constraints in Fig. 6 ensure that reference objects cannot realize a control means

and, at the same time, be affected by a control objective this control means targets (C2); and that audit

processes cannot realize a control mean (C3).

17

7. Language application: Applying MEMO ControlML to support the assessment of internal

controls

We now apply the MEMO ControlML to an application scenario to demonstrate how to utilize lan-

guage concepts for the assessment of internal controls. The scenario is based on and inspired by a refund

returned goods process drawn on by Carnaghan (2006, p. 200) for which internal controls are described in

natural language. For example, “[t]he sales account manager must authorize returns by completing a ‘re-

turn merchandise authorization’ (RMA) paper form that is sent to customer service” and “[t]he information

system restricts the ability to create, change, or delete sales order return and credit requests to authorized

personnel” (quoted in Carnaghan, 2006). Note how these sentences refer to relevant organizational roles

(“sales account manager”, “authorized personnel”), responsibilities (“must authorize”), resources such as

documents (“RMA”) and IT artifacts (“information system”). Figure 7 reconstructs the description of the

scenario in Carnaghan (2006, pp. 191ff.) using the MEMO ControlML and further languages from the

MEMO family of modeling languages: It shows a goal model (top left) that represents (an excerpt of) a

hierarchy of the enterprise’s strategic goals and subsequent business objectives; a business process model

for “refunding returned goods” at three levels of detail (i. e., an aggregated process and its decompositions;

bottom left); a model of the corresponding organizational structure (including organizational roles and com-

mittees; top right) and a model of IT assets used in the process (showing an information system abstraction

of an ERP system; bottom right). Relationships between concepts in different models are explicitly mod-

eled by associations (e. g., the ERP system used in the business process “Authorize credit”) or by shared

concepts (e. g., the organizational role “A/R manager” in both the process “Authorize credit” and in the

organizational structure model). Further abstractions provided by MEMO such as corresponding object

models are omitted for the sake of clarity.

The enterprise model shown supports dedicated analyses for the assessment of internal control systems

based on the conceptual models of internal controls: The control objective “Prevent unauthorized refunds”

recommends a segregation of duties in the aggregated process “Refund returned goods”. The internal control

semantics is further specified by the IT control “Prevent unauthorized transactions”, by the risk “Internal

fraud” it aims to mitigate, by the audit activity “Audit refund transactions and detect irregularity”, and by

the indicator “Percentage of fraudulent refund transactions” to measure achievement of the control objective.

Figure 7 also demonstrates how the control objectives can be associated with concepts that represent the

organizational action system they are embedded in. First, they can be associated with the entity objectives

they are aimed at assuring the achievement of (i. e., the goal “Minimize error rate of incorrect refunds” in

the goal model). Second, control objectives can be linked to static and dynamic abstractions representing

means of control. For example, the above mentioned control objective affects the business process “Re-

fund returned goods”, whereas the actual realization of the recommended action “segregation of duties”

18

Goo

ds

retu

rned

Goo

ds

refu

nded

Ref

und

retu

rned

go

ods

< A

/R d

epar

tmen

t >

Aut

horiz

e re

turn

of

good

s

< S

ales

Acc

ount

M

anag

er >

Link

to p

rior s

ale

< In

vent

ory

cler

k >

Cre

dit c

usto

mer

ac

coun

tE

RP

Sys

tem

Goa

l: P

roce

ss 9

9% o

f al

l ref

unds

in u

nder

1 W

eek

Goa

l: M

inim

ize

erro

r ra

te o

f in

corr

ect

refu

nds

(max

. 1.5

%)

Pre

pare

cre

dit

< S

ales

Acc

ount

M

anag

er >

Aut

horiz

e cr

edit

< A

/R M

anag

er >

Goo

ds li

nked

to

sal

eG

oods

re

fund

ed

IT A

rchi

tect

ure

Boar

d

Exec

utiv

e B

oard

Sal

es

...

...

uses

uses

affects

affe

cts

acco

unta

ble

resp

onsi

ble

Legend

com

pris

esB

usin

ess

Pro

cess

assu

res

achi

evem

ent o

f

refe

rs to

Agg

rega

ted

Bus

ines

s P

roce

ss

Goa

l

Con

trol

Obj

ectiv

e

Com

mitt

ee

Org

aniz

atio

nal

Rol

e

Softw

are

IT h

ardw

are

reso

urce

dire

cts

dire

cts

#Fr

eque

ncy

of

mee

tings

[#

/mon

th]

#

IT

A/R

Man

ager

Sale

s Ac

coun

tM

anag

erin

form

ed

Cont

rol O

bjec

tive:

Seg

rega

tion

of d

utie

sIn

tend

ed S

tate

:Pre

vent

una

utho

rized

tr

ansa

ctio

ns […

]Ca

tego

ry:I

T Co

ntro

l

mitigates

Cont

rol O

bjec

tive:

Opt

imize

IT in

fras

truc

ture

Reco

mm

ende

d Ac

tion:

Esta

blish

an

IT

arch

itect

ure

boar

d to

gui

de a

rchi

tect

ure

[…]

Cate

gory

:IT

Cont

rol,

Regu

latio

n:CO

BIT,

PO

3.5

?

Indi

cato

r

Ris

k

refe

rs to

Goa

l: I

ncre

ase

in

cust

omer

sat

isfa

ctio

n by

5%

ITA

ccou

ntin

gSa

les

refe

rs to

ER

P S

oftw

are

Dat

abas

eS

erve

rA

pplic

atio

nS

erve

r

requ

ires

Bac

kup

mea

sure

s

#Fr

audu

lent

ref

und

tran

sact

ions

[%

]ITIT mea

sure

s

mon

itors

Fina

ncia

l Off

icer

Cont

rol O

bjec

tive:

Seg

rega

tion

of d

utie

sIn

tend

ed S

tate

:Pre

vent

una

utho

rized

refu

nds

[…] C

ateg

ory:

Busin

ess C

ontr

ol

Goal System

realized by

Business Process

Organizational Structure IT Landscape

Inte

rnal

Con

trol

Dia

gram

Aud

it re

fund

tra

nsac

tions

and

de

tect

irre

gula

rity

Risk

: Int

erna

l fra

ud

Visi

bilit

y: h

igh

Unc

erta

inty

:med

ium

‐?

Figure 7: Application scenario: Return refund goods process drawn on by Carnaghan (2006, 200) as a reconstruction using the

MEMO ControlML and MEMO family of modeling languages (revised from Strecker et al., 2011a).

19

is depicted at the most detailed level of the process model. Third, the IT control refers to an IT asset in

the IT landscape model (“ERP system”) that realizes the segregation at the information system level by

authorization and system access policies. Linking the two control objectives also demonstrates how asso-

ciations between controls aid in analyzing internal control systems. Associating a control objective with a

corresponding risk (“Internal fraud”) provides an implicit rationale for the existence of a control objective

possibly indicated by a performance measure (“Fraudulent refund transactions in %”). Finally, the inte-

gration with an organizational structure model emphasizes different types of involvement of organizational

roles. For instance, the two roles participating in the “Credit customer account” process—“Sales Account

Manager” and “A/R Manager”—are linked to the control objective specifying their type of involvement (i. e.,

“accountable” and “responsible”, respectively), whereas a “Financial Officer” is one regularly informed but

not explicitly modeled as part of the business process.

Such integrated models of the enterprise and its internal control system promise to provide intuitive

access to internal control matters and a comprehensible conceptual foundation for differentiated analyses

during the assessment of internal control systems. By associating internal controls with further abstractions

(e. g., of organizational goals or IT landscapes) and by providing dedicated diagram types for specific types

of analyses—deliberately omitting confounding details—such an approach facilitates internal control-related

communication and collaboration between groups of stakeholders with different professional backgrounds.

Additionally, such enterprise models can serve as foundation for auditing purposes in that they support

the comparison of internal controls in place with the likes of prescribed internal controls as defined by, for

instance, COBIT (IT Governance Institute, 2007).

ControlML can also be applied to reconstruct prescribed internal controls as reference models, that

is, reusable conceptual models of internal controls associated with the promise to be applicable to a large

class of prospective use contexts, and to improve the productivity of language users. Figure 8 illustrates

how ControlML is applied to reconstruct controls defined by the COBIT 4.1 framework: Internal controls

defined by the framework (e. g., COBIT PO 4.11) are reconstructed using the ControlML once (upper

right quadrant) and stored in a repository (i. e., a model database) accessible by prospective language users

(bottom right quadrant). Language users select those reference models from the repository they consider

relevant for their own modeling purposes and import the reference models into their modeling tool (upper

left quadrant). Given the inevitably imprecise specification of internal controls in respective frameworks

(being applicable to a wide range of use contexts demands sacrifices to their level of detail), correspond-

ing reference models of internal controls will remain underspecified in certain regards. For instance, the

“Management of IT Security” control objective defined by COBIT demands involvement of “the highest

appropriate organizational management” (IT Governance Institute, 2007). Since organizational structures

vary to a great extent in organizations, it is not feasible to preconceptualize reference models with precise

organizational roles (conceivable roles include the CIO or any other IT executive) with respect to control

20

...ASU SIC Internal Controls

Cobit 4.1: IT General Controls

Control Objective: IT Strategy CommitteeControl Objective: Data and System OwnershipControl Objective: Supervision

Control Objective: Technology Standards

Control Objective: IT Architecture BoardIntended State: The IT architecture conforms to […]Explanation: Establish an IT architecture board to […]Regulation: COBIT, PO3.5 IT Architecture Board

realized by

Control Objective: IT Steering CommitteeIntended State: An IT steering committee is establishedExplanation: Establish an IT steering commitee […]Regulation: COBIT, PO4.3

IT SteeringCommittee

realized by

Control Objective: Segregation of DutiesIntended State: Prevent unauthorized financial operations.Explanation: Implement a division of roles and […]Regulation: COBIT, PO4.11

< OrgUnit >

Approve Financial Transaction

realized by

loaded from

selection of relevant Control

Objectives

adaption & integration

Reference Models for Control O

bjectivesRepository for Reference M

odelsEn

riche

d En

terp

rise

Mod

elRe

leva

nt C

ontr

ol O

bjec

tives

for t

he E

nter

pris

e

Control Objective: Identity ManagementIntended State: Every user can be uniquely identified.Explanation: Ensure that all users (internal, external, and temporary) and their activity on IT systems […]Regulation: COBIT, DS5.3

realized by<Information

System>

Control Objective: Management of IT SecurityIntended State: IT security is consistent with business requirements.Explanation: Manage IT security at the highest appropriate organizational level, so the management […]Regulation: COBIT, DS5.1

realized by

<CIO/ IT executive>

Control Objective: Network SecurityIntended State: No unauthorized information flows to and from networks are possible.Explanation: Use security techniques and related management procedures, e.g., firewalls, […]Regulation: COBIT, DS5.10

realized by

Figure 8: Reconstructing COBIT 4.1 control objectives as reference models using MEMO ControlML

involvement. Hence, the reference models will, in most cases, have to be adapted to the specific organiza-

tional use context in a modeling project for internal controls (lower left quadrant). Yet, the overall modeling

effort is reduced and, at the same time, compliance with auditing standards and guidelines is fostered due

to the reuse of proven artifacts.

8. Conclusion

The present work directs the discussion on supporting the assessment of internal control systems through

conceptual models to include further abstractions common to enterprise modeling that go beyond business

process modeling (i. e., modeling constructs representing internal controls and the corresponding organi-

zational action system). In this context, a DSML for the modeling of internal controls is specified and

applied to demonstrate its practical use. The DSML addresses five essential domain-specific requirements:

It accounts for the organizational context important to internal control interpretation (R1); explicit and

qualified relationships among internal controls (R2); and the multiplicity of control means (R3). The lan-

guage aids in the perception of a traceable rationale of an internal control by way of explicit (assertion) and

implicit (association with risk types) modeling concepts (R4). Further research is required with respect to

constructing tailored visual representations meaningful to groups of prospective users (i. e., diagram types

and notation elements) (R5).

The language’s meta model-based specification and corresponding graphical notation provides abstract

21

and concrete syntax and formal semantics of dedicated modeling constructs for key domain-specific concepts.

The demonstration indicates that the ControlML allows for modeling of coherent and consistent concep-

tual models of internal controls that promise to facilitate interpretation and assessment of internal control

systems. In particular, the design artifact contributes to existing work in that it adds essential concepts to

internal controls modeling and semantics to key modeling concepts.

However, the present conceptualizations in ControlML assume that the precise semantics of concepts

promote comprehension by language users. Further research has to study the effects of the presented con-

ceptualizations on prospective users, that is, whether the proposed concepts do indeed lower communication

barriers and increase transparency of internal control matters. The number of concepts and the diversity

of relations in ControlML suggests that the language itself may initially increase complexity in practice,

before complexity is reduced after mastering the language. At present, it is therefore not feasible to predict

the effects of MEMO ControlML on the complexity-reducing effects of using a DSML in the assessment

of internal control systems and the complexity-increasing effects of the language itself.

With regard to auditing practice, enterprise models created with ControlML provide an instrument for

audit reviews and function as audit evidence (i. e., as a structured documentation of a firm’s internal control

system) to facilitate interpretation and assessment of controls by stakeholders. The feedback received from

practicing auditors on the use scenario described in Section 7 indicates at least partial confirmation of this

working hypothesis (as does Cendrowski et al., 2007, p. 208). In this respect, the present work addresses

the suggested lack of research on internal control assessment methods (Mock et al., 2009, p. 66), and opens

paths for future research on such methods: A method based on ControlML requires a corresponding

process model to guide the application of language concepts to the assessment of the internal control system.

While the application scenario in Section 7 illustrates the principle use of essential language concepts, a

corresponding process model should provide more detailed guidelines on how to use the language for specific

model-based analyses and assessments. The development of such a process model is on our research agenda.

References

Bailey, Jr., A. D., Han, K. S., Stansifer, R. D., Whinston, A. B., 2000. The Intelligent Internal Accounting Control Model

using a Logic Programming Approach. In: Vasarhelyi, M. A., O’Leary, D. (Eds.), Artificial Intelligence in Accounting and

Auditing: Creating value with AI. Vol. 5 of Rutgers Series in Accounting Information Systems. Markus Wiener Publishers,

Princeton, NJ, pp. 66–93.

Carnaghan, C., 2006. Business process modeling approaches in the context of process level audit risk assessment: An analysis

and comparison. International Journal of Accounting Information Systems 7 (2), 170–204.

Cendrowski, H., Martin, J. P., Petro, L. W. (Eds.), 2007. The Handbook of Fraud Deterrence. John Wiley and Sons, Hoboken,

New Jersey.

Chen, K. T., Lee, R. M., 2003. Knowledge-based evaluation of internal accounting control systems — a pattern recognition

approach. In: Proceedings of the American Accounting Association Conference. Honolulu, HI.

22

COSO, Sep. 1992. Internal Control — Integrated Framework. The Committee of Sponsoring Organizations of the Treadway

Commission.

COSO, Sep. 2004. Enterprise Risk Management – Integrated Framework (Executive Summary). The Committee of Sponsoring

Organizations of the Treadway Commission.

COSO, 2009. Guidance on Monitoring Internal Control Systems: Introduction. The Committee of Sponsoring Organizations

of the Treadway Commission.

COSO, Sep. 2010. What is internal control? http://www.coso.org/resources.htm, The Committee of Sponsoring Organiza-

tions of the Treadway Commission.

Crawford, M., Stein, W., 2002. Auditing Risk Management: Fine in Theory but who can do it in Practice? International

Journal of Auditing 6 (2), 119–131.

Damianides, M., 2005. Sarbanes-Oxley and IT Governance: New Guidance on IT Control and Compliance. Inf. Sys. Manage.

22 (1), 77–85.

Davis, C., Schiller, M., Wheeler, K., 2007. IT Auditing : Using Controls to Protect Information Assets. McGraw-Hill.

Dunn, C. L., 2006. Business Process Modeling Approaches in the Context of Process Level Audit Risk Assessment: An Analysis

and Comparison : Discussion Comments. International Journal of Accounting Information Systems 7 (2), 205–207.

Dunn, C. L., Cherrington, J. O., Hollander, A. S., 2005a. Enterprise Information Systems: A Pattern-Based Approach, 3rd

Edition. McGraw-Hill Irwin, Boston, MA.

Dunn, C. L., Gerard, G. J., Grabski, S. V., 2005b. Critical evaluation of conceptual data models. International Journal of

Accounting Information Systems 6 (2), 83–106.

Elder, R. J., Beasley, M. S., Arenes, A. A., 2010. Auditing and Assurance Services: An Integrated Approach, 13th Edition.

Pearson, Boston et al.

Ferstl, O. K., Sinz, E. J., 1998. SOM Modeling of Business Systems. In: Bernus, P., Mertins, K., Schmidt, G. (Eds.), Handbook

on Architectures of Information Systems. Springer, Berlin, pp. 339–358.

Frank, U., 1994. Multiperspektivische Unternehmensmodellierung: Theoretischer Hintergrund und Entwurf einer objektorien-

tierten Entwicklungsumgebung. Oldenbourg, Munchen.

Frank, U., 1998. Essential Research Strategies in the Information Systems Discipline—Reflections on Formalisation, Contin-

gency and the Social Construction of Reality. The Systemist 20, 98–113.

Frank, U., 2002. Multi-Perspective Enterprise Modeling (MEMO): Conceptual framework and modeling languages. In: Pro-

ceedings of the 35th Annual Hawaii International Conference on System Sciences (HICSS). Honululu, pp. 72–82.

Frank, U., 2006a. Evaluation of Reference Models. In: Fettke, P., Loos, P. (Eds.), Reference Modeling for Business Systems

Analysis. Idea Group, Hershey, PA, pp. 118–140.

Frank, U., 2006b. Towards a Pluralistic Conception of Research Methods in Information Systems Research. ICB Research

Report 7, Institute for Computer Science and Business Information Systems (ICB), University of Duisburg-Essen, Germany.

Frank, U., 2010. Outline of a Method for Designing Modelling Languages. ICB Research Report 42, Institute for Computer

Science and Business Information Systems (ICB), University of Duisburg-Essen, Essen, Germany.

URL http://www.icb.uni-due.de/fileadmin/ICB/research/research_reports/ICB-Report-No42.pdf

Frank, U., 2011a. MEMO Organisation Modelling Language: Focus on Business Processes. ICB-Research Report 49, Institute

for Computer Science and Business Information Systems (ICB), University of Duisburg-Essen, Essen, Germany.

URL http://www.icb.uni-due.de/fileadmin/ICB/research/research\_reports/ICB-Report-No49.pdf

Frank, U., 2011b. MEMO Organisation Modelling Language: Focus on Organisational Structure. ICB-Research Report 48,

Institute for Computer Science and Business Information Systems (ICB), University of Duisburg-Essen, Essen, Germany.

URL http://www.icb.uni-due.de/fileadmin/ICB/research/research\_reports/ICB-Report-No48.pdf

Frank, U., 2011c. MEMO Organisation Modelling Language (OrgML) – Requirements and Core Diagram Types. ICB-Research

23

Report 47, Institute for Computer Science and Business Information Systems (ICB), University of Duisburg-Essen, Essen,

Germany.

URL http://www.icb.uni-due.de/fileadmin/ICB/research/research\_reports/ICB-Report-No47.pdf

Frank, U., 2011d. The MEMO Meta Modelling Language (MML) and Language Architecture. 2nd Edition. ICB-Research

Report 43, Institute for Computer Science and Business Information Systems (ICB), University of Duisburg-Essen, Essen,

Germany.

URL http://www.icb.uni-due.de/fileadmin/ICB/research/research_reports/ICB-Report_No43.pdf

Frank, U., 2012. Multi-Perspective Enterprise Modeling: Foundational Concepts, Prospects and Future Research Challenges.

Software and Systems Modeling, available online first, DOI 10.1007/s10270-012-0273-9.

Frank, U., 2013. Domain-Specific Modeling Languages - Requirements Analysis and Design Guidelines. In: Reinhartz-Berger,

I., Sturm, A., Clark, T., Wand, Y., Cohen, S., Bettin, J. (Eds.), Domain Engineering: Product Lines, Conceptual Models,

and Languages. Springer.

Frank, U., Heise, D., Kattenstroth, H., Ferguson, D., Hadar, E., Waschke, M., 2009. ITML: A Domain-Specific Modeling

Language for Supporting Business Driven IT Management. In: Rossi, M., Gray, J., Sprinkle, J., Tolvanen, J.-P. (Eds.),

Proceedings of the 9th OOPSLA workshop on domain-specific modeling (DSM).

Geerts, G. L., 2011. A design science research methodology and its application to accounting information systems research.

International Journal of Accounting Information Systems 12, 142–151.

Gelinas, U. J., Dull, R. B., 2010. Accounting Information Systems, 8th Edition. South-Western Cengage Learning, Mason, OH.

Gelinas, U. J., Sutton, S. G., Fedorowicz, J., 2004. Business processes and information technology. South-Western Thomson

Learning, Mason, Ohio.

Governatori, G., Hoffmann, J., Sadiq, S. W., Weber, I., 2008. Detecting Regulatory Compliance for Business Process Models

through Semantic Annotations. In: Ardagna, D., Mecella, M., Yang, J. (Eds.), Business Process Management Workshops.

Vol. 17 of Lecture Notes in Business Information Processing. Springer, pp. 5–17.

Governatori, G., Milosevic, Z., Sadiq, S., October 2006. Compliance checking between business process and business contracts.

In: Proceedings of the 10th IEEE International Enterprise Distributed Object Computing Conference (EDOC’06), Hong

Kong, China, Oct 16, 2006. IEEE Computer Society, Los Alamitos, CA, USA, pp. 16–20.

IT Governance Institute (Ed.), 2007. CobiT 4.1: Framework, Control Objectives, Management Guidelines, Maturity Models.

IT Governance Institute of the Information Systems Audit and Control Association, Rolling Meadows.

Karagiannis, D., 2008. A Business process Based Modelling Extension for Regulatory Compliance. In: Bichler, M. et al. (Ed.),

Multikonferenz Wirtschaftsinformatik. pp. 1159–1173.

Karagiannis, D., Mylopoulos, J., Schwab, M., 2007. Business Process-Based Regulation Compliance: The Case of the Sarbanes-

Oxley Act. In: Requirements Engineering : 15th IEEE International Requirements Engineering Conference, RE 2007,

October 15-19th, 2007, New Delhi, India. IEEE, pp. 315–321.

Kohling, C., 2012. Entwurf einer konzeptuellen Modellierungsmethode zur Unterstutzung rationaler Zielplanungsprozesse in

Unternehmen. Doctoral dissertation, University of Duisburg-Essen, Institute for Computer Science and Business Information

Systems (ICB), Essen, Germany.

Lu, R., Sadiq, S. W., Governatori, G., 2007. Compliance Aware Business Process Design. In: ter Hofstede, A. H. M., Benatallah,

B., Paik, H.-Y. (Eds.), Business Process Management Workshops. Vol. 4928 of Lecture Notes in Computer Science. Springer,

pp. 120–131.

Lu, R., Sadiq, S. W., Governatori, G., 2008. Measurement of Compliance Distance in Business Processes. Inf. Sys. Manag.

25 (4), 344–355.

Maijoor, S., 2000. The Internal Control Explosion. International Journal of Auditing 4 (1), 101–109.

Mock, T. J., Sun, L., Srivastava, R. P., Vasarhelyi, M., 2009. An evidential reasoning approach to Sarbanes-Oxley mandated

24

internal control risk assessment. International Journal of Accounting Information Systems 10 (2), 65–78.

Moeller, R. R., 2008. Sarbanes-Oxley Internal Controls : Effective Auditing with AS5, CobiT and ITIL. John Wiley & Sons,

Hoboken, NJ.

Namiri, K., Stojanovic, N., 2007a. A formal approach for internal controls compliance in business processes. In: 8th Workshop

on Business Process Modeling, Development, and Support, BPMDS 2007 in conjunction with CAiSE 2007. Trondheim,

Norway.

Namiri, K., Stojanovic, N., 2007b. Pattern-based design and validation of business process compliance. In: Proceedings of

the 2007 OTM Confederated International Conference on On the move to meaningful internet systems: CoopIS, DOA,

ODBASE, GADA, and IS-Volume Part I. Springer, pp. 59–76.

Ortner, E., 2008. Language-critical Enterprise and Software Engineering. In: Proceedings of the Fourteenth Americas Confer-

ence of Information Systems, AMCIS 2008, Toronto, ON, Canada, Aug 14–17, 2008.

Peffers, K., Tuunanen, T., Rothenberger, M. A., Chatterjee, S., 2007. A design science research methodology for information

systems research. Journal of Management Information Systems 24 (3), 45–77.

Pitthan, J., Philipp, M., 1997. Einsatz von Petri-Netzen fuer die Aufnahme, Dokumentation und Analyse Interner Kontrollsys-

teme im Rahmen der Jahresabschlusspruefung. In: Stucky, W., Winand, U. (Eds.), Petri-Netze zur Modellierung verteilter

DV-Systeme. No. 350. Universitaet Karlsruhe, Karlsruhe, Germany, pp. 87–104.

Rikhardsson, P., Best, P., Green, P., Rosemann, M., 2006. Business Process Risk Management, Compliance, and Internal

Control: A Research Agenda. Tech. rep., Department of Business Studies, Management Accounting Research Group, Aarhus

School of Business, Aarhus, Denmark.

Rikhardsson, P., Rohde, C., Rom, A., 2005. Exploring Enterprise Systems and Management Control in the Information Society:

Developing a Conceptual Framework. Management Accounting Research Group Working Papers M-2005-05, University of

Aarhus, Aarhus School of Business, Department of Business Studies, Aarhus, Denmark.

Sadiq, S. W., Governatori, G., Namiri, K., 2007. Modeling Control Objectives for Business Process Compliance. In: Alonso,

G., Dadam, P., Rosemann, M. (Eds.), BPM 2007. Springer, Berlin, pp. 149–164.

Scheer, A.-W., 1992. Architecture of Integrated Information Systems : Foundations of Enterprise Modelling. Springer, Berlin.

Spira, L. F., Page, M., 2002. Risk Management — The reinvention of internal control and the changing role of internal audit.

Accounting, Auditing & Accountability Journal 16 (4), 640–661.

Strecker, S., Frank, U., Heise, D., Kattenstroth, H., 2012. MetricM: A modeling method in support of the reflective design

and use of performance measurement systems. Information Systems and e-Business Management (ISeB) 10 (2), 241–276.

Strecker, S., Heise, D., Frank, U., 2010. Toward modeling constructs for audit risk assessment: Reflections on internal controls

modeling. In: Esswein, W., Turowski, K., Juhrisch, M. (Eds.), Modellierung betrieblicher Informationssysteme (MobIS

2010). GI, Bonn, pp. 131–148.

Strecker, S., Heise, D., Frank, U., 2011a. Prolegomena of a modelling method in support of audit risk assessment: Outline of a

domain-specific modelling language for internal controls and internal control systems. Enterprise Modelling and Information

Systems Architectures: An International Journal 6 (3), 5–24.

Strecker, S., Heise, D., Frank, U., 2011b. RiskM: A multi-perspective modeling method for IT risk assessment. Information

Systems Frontiers (ISF). Special Issue on Governance, Risk and Compliance Applications in Information Systems 13 (4),

595–611.

Sutton, S. G., Hampton, C., 2003. Risk assessment in an extended enterprise environment: Redefining the audit model.

International Journal of Accounting Information Systems 4 (1), 57–73.

van der Aalst, W., van Hee, K., van der Werft, J. M., Kumar, A., Verdonk, M., 2011. Conceptual model for online auditing.

Decision Support Systems 50, 636–647.

Verschuren, P., Hartog, R., 2005. Evaluation in Design-Oriented Research. Qual Quant 39 (6), 733–762.

25

Wand, Y., Monarchi, D. E., Parsons, J., Woo, C. C., 1995. Theoretical foundations for conceptual modelling in information

systems development. Dec. Supp. Syst. 15 (4), 285–304.

Wand, Y., Weber, R., 2002. Research commentary: information systems and conceptual modeling — A research agenda. Inf.

Syst. Res. 13 (4), 363–376.

Weigand, H., Elsas, P., 2012. Model-based auditing using REA. International Journal of Accounting Information Systems 13,

287–310.

26