Assessing Business Processes by Checking Transaction Documents for
Inconsistency Risks
Takafumi Komoto
1
, Kokichi Futatsugi
1
and Nobukazu Yoshioka
2
1
Japan Advanced Institute Science and Tecknology, Nomi, Japan
2
National Institute of Information Technology Grace Center, Tokyo, Japan
Keywords: Internal Control, Transaction Documents, Reliability, Inconsistency Risks, Checked Documents Matrix.
Abstract: Business processes can be assessed by checking transaction documents for inconsistency risks and can be
classified into two categories. Inconsistency refers to a mismatch between items (product name, quantity,
unit price, amount price, etc.) among transaction documents. For any process in the first category, the
consistency of any pair of transaction documents in the process is checked, and there is no risk of
inconsistency. For any process in the second category, the consistency of some pairs of transaction
documents in the process cannot be checked, and there is a risk of inconsistency. This paper proposes a
method for the assessment of risk inconsistencies. The assessment can be used to design and evaluate
business processes for a company’s internal control over financial reporting. A business process diagram
and inconsistency risk detection algorithm for classifying business processes is provided.
1 INTRODUCTION
From the viewpoint of internal control, management
has a responsibility to establish business processes
that do not cause deficiencies over financial
reporting. When deficiencies over financial
reporting are pointed out by auditors, companies
lose the reliability of their investors. (Shimizu,
Nakamura, 2007); (Maruyama et al., 2008); (Sasano,
2006).
Certified Public Accountants (CPAs) examine
the consistency among accounting transaction
documents (slips, vouchers, etc.) related to
transactions when performing an accounting audit.
They check whether there is a mismatch between
them and confirm the reliability of transactions.
(Yamaura, 2002)
If such checks and confirmations performed by
CPAs to posted transactions are incorporated into
the business process, more reliable transactions may
be realized. Company workers check between
received slips and archived slips on the same
transaction for consistencies in product name,
quantity, unit price, and amount price in business
processes. In other words, checking and confirming
the consistency of transactions are already
performed on-site.
However, these checks are independently
performed at each department of a company during
the business process. Therefore, any inconsistencies
among whole documents in transactions cannot be
detected solely by checks performed in one
department when such transactions pass through
multiple departments.
For example, there are transaction documents
“a”, “b”, and “c” in a transaction. When division
“A” checks transaction documents “a” and “b”, and
division “B” checks transaction documents “b” and
“c”, inconsistencies in whole documents for the
transaction are detected considering a transitive
relation between “a” and “c” through “b”.
Conversely, when division “A” checks documents
“a” and “b”, and “B” only has document “c” any
inconsistencies between them cannot be detected
because there is no relation between “a”, “b”, and
“c”.
The detection of inconsistencies between
transaction documents depends on what divisions
check in transaction documents, i.e., the business
process.
This paper proposes a method for assessment of
risk inconsistencies. The assessment can be used to
design and evaluate business processes for a
company’s internal control over financial reporting.
A business process diagram and an inconsistency
risk detection algorithm for classifying business
39
Komoto T., Futatsugi K. and Yoshioka N.
Assessing Business Processes by Checking Transaction Documents for Inconsistency Risks.
DOI: 10.5220/0006222000390045
In Proceedings of the Sixth International Symposium on Business Modeling and Software Design (BMSD 2016), pages 39-45
ISBN: 978-989-758-190-8
Copyright
c
 2016 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved

processes are provided.
The paper is organized as follows. The next
section describes business process modeling using
our business process diagram while Section 3
introduces an inconsistency risk detection algorithm
for classifying business processes. Section 4 presents
a case study. Section 5 discusses related work.
Section 6 concludes this paper.
2 BUSINESS PROCESS
DIAGRAM
A business process diagram is a diagram used to
describe business processes of a company by listing
business events and archived transaction documents
and checked documents set. At first we will explain
the elements and notations of the “business process
diagram” using a simple example.
2.1 An Order-to-Delivery Process
Diagram
This simple diagram (Figure 1) describes an “order-
to-delivery process” in which a company orders
goods from a vendor, and the vendor delivers the
goods to the company. In this process, the company
orders goods from the vendor with a purchase order
document. When the vendor receives the purchase
order document, it prepares the goods for shipping
and delivers them with an invoice. The company
receives the goods with the invoice and checks
between the purchase order and the goods to ensure
consistency with the invoice. The diagram in Figure
1 describes the “order-to-delivery process.”
In this diagram, 【vendor】 and 【company】
show entities. An “order” and a “deliver” are
events in the transaction process. The events are
indicated by arrows pointing from a sending entity
toward a receiving entity of a transaction document.
The events are run sequentially from top to bottom
along a timeline of the entities.
The sides of an arrow are visualized by the
following symbols to distinguish between a
transmission and a reception.
"●": start of the process, "▽": end of an event
"△": start of an event, "▼": end of the process
On a side of the timeline between “▽” (end of an
event) and “△” (start of a following event), work
at the acceptance event can be described. (The work
can be omitted.)
Figure 1: Order-to-Delivery Process Diagram.
In general, each transaction document is issued
in accordance with a business event in the
transaction. A “purchase order” and an “invoice”
issued in this business process are described
sequentially in the dashed frame indicating the
archived transaction documents under the timeline
of each entity. A line is drawn under a received
document to distinguish it from a sent document.
Business events, an “order” and a “deliver,” can be
described in the side of the dashed frame to link to
the transaction documents, a “purchase order” and
an “invoice.”
In general, workers of a company also check
between a received transaction document and
archived transaction documents on the same
transaction for consistencies in product name,
quantity, unit price, and amount price in business
processes. In the “order-to-delivery process diagram,”
the state of transaction documents, whether checked
or not by a division receiving a transaction
document, is described.
At first, when 【vendor】 receives a purchase
order, it does not keep any documents. Therefore, a
checked documents set φ(empty set) is described.
Next, when 【company】 receives an invoice, it
keeps the purchase order. As 【company】 checks
between the invoice and the purchase order, a
checked documents set {purchase order, invoice} is
described.
2.2 Elements and Notation of Business
Process Diagram
As shown using the simple example, the business
process diagram consists of the following elements.
 "Division": entity that performs the work in the
process.
 "Timeline": time flowing from top to bottom.
 "Event": things needed to send and receive a
transaction document from one division to
Sixth International Symposium on Business Modeling and Software Design
40

another division in a predetermined order.
 "Transaction document": documented work
instructions and/or operating report in the
business process.
 "Archived documents": transaction documents
that the divisions sent and received.
 "Checked documents set": set of documents that
the department is keeping (including a received
document).
Figure 2: Business Process Diagram.
"Division", "Events", "Transaction document",
"Archived documents", and "Checked documents
set" are symbolized and defined as follows.
 Division a, b ∈ Div (Div: the entire division)
 Event e
n
(a, b) ∈ E (E: the entire event): the n-
th event to send and receive a document from
division “a” to division “b”.
 Event order n ∈ N (N: natural number)
 Transaction document d
n
∈ Doc (Doc: all
documents): the document to send and receive in
the event e
n
(a, b)
 Archived documents S
n
(a): documents that
division “a” sent and received until the event en
 Checked documents set V
n
: set of the documents
S
n
(a) that division “a” received the document d
n
in the event e
n
The elements and notation of the business process
diagram notation are shown in Figure 2.
2.3 Preconditions for Business Process
Diagram
There are some preconditions for the business
process diagram to represent practical standard
business processes.
In a business process, when a person in charge in
the division receives a transaction document, he/she
works in accordance with business rules and issues a
transaction document for reporting his/her task or
indicating a task of the next division. When he/she
receives a transaction document from another
division, and archive documents of the transaction
are kept in this division, he/she can prevent an
operational error by comparing the common items
(product name, quantity, unit price, amount price,
etc.) between the received document and archived
documents.
Business process diagrams are used to detect
inconsistency risks by examining mistakes or frauds.
Accordingly, in the business process diagram it is
assumed that transaction documents are not changed
during storage and delivery. In other words, a sent
document and a received document concerning the
same event are regarded as the same.
It is also assumed that the event order of the
business process is fixed. In general, business events
in the company, in accordance with the principle of
the separation of duty, are performed without being
indicated by a transaction document. Therefore, in
the business process diagram, the division not
receiving a transaction document cannot send a
transaction document except at the start of the event.
For example, in the purchase order process, the
accounting division cannot pay for goods without
receiving disbursement approval by the procurement
division. In other words, each business event is
carried out in the usual fixed order.
2.4 Example of Business Process
Diagram at Risk for Inconsistency
Figure 3, which has a slightly modified business
process diagram compared with Figure 1,
【company】 division of Figure 1 is divided into
【purchase】 division and 【warehouse】division.
The business event of receiving a report from
【warehouse】 division to 【purchase】division is
added.
Figure 3: Business Process Diagram at Risk for
Inconsistency.
Assessing Business Processes by Checking Transaction Documents for Inconsistency Risks
41

Looking at the checked documents set V
i
,
received report d
3
and order d
1
is compared.
However, invoice d
2
is not compared. Therefore,
inconsistencies cannot be detected even if there is an
error in the invoice. The business process diagram in
Figure 3 is at risk for inconsistency of transaction
documents.
3 INCONSISTENCY RISK
DETECTION ALGORITHM
When a business process diagram is given, we
provide an inconsistency risk detection algorithm
that determines whether the business process has
inconsistency risks among transaction documents.
The inconsistency risk detection algorithm is
based on the equivalence relation of transaction
documents. Transitive closure for the checked
document matrix of the business process diagram is
calculated using the Floyd-Warshall algorithm.
(Cormen et al., 2009).
When the elements of the transitive closure
matrix are all 1, no risk of inconsistency is decided.
When the elements of the transitive closure matrix
are 0, a risk of inconsistency is decided.
3.1 Documents Check and Equivalence
Relation
“Documents check” compares common items of a
received document to archived documents in the
receiving division. Common items of transaction
documents in the business process are product name
and quantity, unit price, amount price, etc.
We determined that “documents check” serves as
an equivalence relation as the result of the following
analysis of “documents check.”
Document d
1
is naturally compared with itself
(reflexivity law). When document d
1
is compared
with document d
2
, document d
2
is compared with
document d
1
(symmetric law). In addition, if
document d
1
and document d
2
are compared, and
document d
2
and document d
3
are compared, then
document d
1
and d
3
have also been compared
(transitive law).
Comparing reflexivity law and symmetry law is
a convincing operation. For transitivity law, it has
also been determined that a convincing operation
can be assumed.
It should be noted that our discussion is based on
the assumption of the sameness between the sent
document and the received document, and the
transitive law of “documents check”.
3.2 Inconsistency Risk Detection
Algorithm
The state of the comparison with the entire set of
transaction documents of business process diagram
Doc = {d
1
, ・・・, d
n
} is represented by a matrix
(Checked Documents Matrix).
Checked documents matrix T(i, j) is set as 1 if
document d
i
and document d
j
are compared. T(i, j) is
set as 0 if they are not compared.
Since the checked documents have an
equivalence relation, the diagonal elements (i, i) are
consistently 1 by reflexivity law, and (i, j)
component and (j, i) component are equal by
symmetric law.
We will explain the Checked Documents Matrix
T using the following example. The entire set of
documents of the matrix are Doc = {d
1
, d
2
, d
3
}.
Checked Documents Matrix T
0
describes how
document d
1
is compared with d
2
and d
3
, but
document d
2
is not compared with d
3
.
However, document d
2
and d
1
are compared, and
document d
1
and d
3
are compared in T
0
, so document
d
2
and d
3
are also compared by transitive law.
At first glance, document d
2
and d
3
seemed not to
be compared in T
0
. But matrix T
1
applying the
transitivity law represents the true state of checked
documents.
As described above, continuing to apply the
transitivity law for initial checked documents matrix
T
0
, by calculating T
1
, T
2
・・・, transitive closure T
subsequently cannot be applied by the transitivity
law any more. Transitive closure T represents the
true state of checked documents.
Then, starting from the initial checked
documents matrix T
0
, by applying the transitivity
law, if the elements (i, j) of checked documents
matrix T (transitive closure) are all 1, all the
documents have been checked. Therefore, there is no
risk of inconsistency in the business process.
Conversely, if the elements (i, j) of transitive closure
T include zero, no documents are checked with each
other. Therefore, there is a risk of inconsistency in
Sixth International Symposium on Business Modeling and Software Design
42

the business process.
The inconsistency risk detection algorithm of the
business process diagram is as follows.
<Inconsistency Risk Detection Algorithm>
1) Set the initial checked documents matrix T0.
 All elements of T
0
are set to 0, and for Checked
Documents Set Vi of the business process
diagram, when V
i
contains document d
i
and d
j
,
(i, j) of T
0
is set to 1 for all i.
 Diagonal elements of T
0
are set to 1. When the
element (i, j) is 1, the symmetry element (j, i) is
set to 1.
2) Calculate the transitive closure of checked
documents matrix T
0
.
 Calculate the T
n
by applying the Floyd-
Warshall algorithm (Cormen et al., 2009).
【Floyd-Warshall Algorithm (Cormen et al., 2009) 】
The (i, j) element of the matrix T
k
is t
k
ij
.
for k = 1 to n
T
k
= a (t
k
ij
) is a new matrix
for i = 1 to n
for j = 1 to n
t
k
ij
= t
k-1
ij
∨ (t
k-1
ik
∧t
k-1
kj
)
return T
n
.
3) When the elements of the transitive closure T
n
are all 1, there is no risk of inconsistency in the
business process. When the elements of T
n
are
not all 1, there is some risk of inconsistency in
the business process.
Figure 4: Standard Purchase Order Process Diagram.
4 CASE STUDY BY STANDARD
PURCHASE ORDER PROCESS
The assessment of the standard purchase order
process is performed in this case study. First, we
make the business process diagram of the standard
purchase order process (Figure 4) and extract the
checked documents matrix from the checked
documents sets V
i
(for all i). Next, the inconsistency
risk detection algorithm is applied for checked
documents matrix T
0
, and the inconsistency risk of
the process is judged.
4.1 Purchase Order Process Diagram
and Inconsistency Risk Judgment
In the standard purchase order process, the purchase
division orders goods from the vendor and notifies
the warehouse division of the order. The vendor
delivers the goods to the warehouse, and the
warehouse receives them and sends the receiving
report to the purchase division. The purchase
division requests the accounting division for the
payment in accordance with the invoice. The
accounting division completes the disbursement and
informs the purchase division about it to prevent
duplicate payments. (Sasano, 2006); (Kaneko 2001)
This standard purchase order process diagram is
shown in Figure 4.
The inconsistency risk detection algorithm is
applied to the checked documents matrix T
0
, as
shown in Figure 5. Since the elements of transitive
closure matrix T
11
are all 1, no risk of inconsistency
in the standard purchase order process is determined.
Figure 5: Transitive Disclosure Matrix T
11
of Checked
Documents Matrix T
0
.
5 RELATED WORK
We are currently unaware of any studies that model
the business process by focusing on the documents
generated in the business process and that assess the
business process for inconsistency risks.
From the perspective of specific practical
analysis of business rules and business processes,
Assessing Business Processes by Checking Transaction Documents for Inconsistency Risks
43

the study described in this paper is considered to be
unique.
Business process studies from the perspective of
law compliance and standards are part of the field of
business process compliance. These studies provide
a framework for internal control in accordance with
the Committee of Sponsoring Organizations of the
Treadway Commission (COSO) and in accordance
with health care privacy as established by the U.S.
Health Insurance Portability and Accountability Act
of 1996 (HIPPA) by analyzing the entire laws and
standards. (Breaux et al., 2006); (Siena et al., 2009)
However, this paper does not provide a specific
method that conforms to the standards established by
COSO and HIPPA.
We are aware of a Resources, Events, and
Agents (REA) study that analyzes and models
financial accounting systems. In that study, all
aspects of financial accounting are analyzed, but
specific proposals for accounting audits are not
provided. (McCarthy, 1982)
6 CONCLUSION
Comparison of received transaction documents with
archived transaction documents by a person in
charge of each division in a company is naturally
performed to prevent any errors in the operation of
each division. However, we cannot conclude that
such a simple check in each division is enough to
ensure consistency for the entire set of transaction
documents in the business process, despite
consistency in transaction documents belonging to
individual divisions.
As indicated above, if the business process is
properly designed, the consistency for the entire set
of transaction documents is ensured. This operation
approximately corresponds to auditing done by
CPAs to confirm the existence of transactions.
This paper proposes a method of assessing
business processes by checking transaction
documents for inconsistency risks. This method
consists of a “Business Process Diagram” and an
“Inconsistency Risk Detection Algorithm.”
Using the "Business Process Diagram" and the
"Inconsistency Risk Detection Algorithm,” business
processes can be classified in two categories. For
any process in the first category, the consistency of
any pair of transaction documents in the process is
checked, and there is no risk of inconsistency. For
any process in the second category, the consistency
of some pairs of transaction documents in the
process cannot be checked, and there is a risk of
inconsistency.
When a business process is properly designed to
meet the needs of the business process in the first
category, inconsistency risks can be reduced.
We confirmed in the case study that the standard
purchase order process established in the practices,
due to the accumulation of experience over many
years, is a business process in the first category.
This study aims to establish a high-quality
method for inconsistency risk evaluation that can be
incorporated into business rules and business
processes by analyzing documents that are created
on the basis of business rules and business processes.
In this study, we modeled the business processes of
transactions and assessed them for consistency risks.
We will pursue logical verification by using
CafeOBJ to refine our "Inconsistency Risk Detection
Algorithm."
We will research a method to investigate
mistakes and fraud in business processes in the
future.
ACKNOWLEDGEMENTS
We thank Prof. Syuji Iida and Dr. Yasuhito Arimoto,
Prof. Takao Okubo, Prof. Naoharu Kaiya, Mr.
Motoharu Hirukawa, Ms. Junko Torimitsu for their
valuable comments and feedback for our approach.
REFERENCES
K. Shimizu, M. Nakamura, 2007: Internal Control for IT
Professionals, Zeimukeiri Kyoukai (in Japanese).
M. Maruyama, S. Kamei and T. Miki, 2008: Readings
from Internal Control Environment, Shoeisha (in
Japanese).
M. Sasano, 2006: Introduction and Practice of Internal
Control, Chuokeizaisha (in Japanese).
A. Kaneko 2001: Business Seminar Company Accounting
Introduction, Third Edition, Nihon Keizai Shimbun,
Inc. (in Japanese).
H. Yamaura, 2002: Financial Auditing Theory, second
edition, Chuokeizaisha (2002) (in Japanese).
T. Cormen, C. Leiserson, R. Rivest and C. Stein, 2009:
Introduction to Algorithms [Volume 2], third edition,
MIT Press.
Travis D. Breaux, Matthew W. Vail, and Annie I. Anton,
2006: Towards Regulatory Compliance: Extracting
Rights and Obligations to Align Requirements with
Regulations. RE 2006: 46-55.
Alberto Siena, Anna Perini, Angelo Susi, and John
Mylopoulos, 2009: Towards a framework for law-
compliant software requirements. ICSE Companion
2009: 251-254.
Sixth International Symposium on Business Modeling and Software Design
44

McCarthy, E. W, 1982: The REA Accounting Model: A
Generalized Framework for Accounting Systems in a
Shared Data Environment. The Accounting Review,
(July 1982): pp. 554-578.
Assessing Business Processes by Checking Transaction Documents for Inconsistency Risks
45