THE ACCCOUNTING CONCEPT AS KEY CONCEPT FOR
BUSINESS MODELLING
Coen Suurmond
RBK Group, Keulenstraat 18, 7418 ET Deventer, The Netherlands
csuurmond@rbk.nl
Keywords: Business modelling, Software architecture, Accounting.
Abstract: Many problems in IT systems can be traced back to two misconceptions: that all information comes from
these systems and that the information from these systems represents reality “as is”. IT systems are often
closed and inflexible. Modelling accounting subsystems, as closely as possible to operational practice, can
prevent these problems. Current software architecture provide technical support for this approach. In
modelling the formalisation and standardisation of the use of language is an important issue.
1 INTRODUCTION
The development, implementation and operational
use of information systems within enterprises face
certain persistent problems. These problems arise
from misconceptions about the nature and role of
information systems within an enterprise. I refer
here firstly to the misconception that the role of the
computer-based information systems is to cover all
of the information supply within an enterprise. And I
refer here secondly to the misconception that it is in
the nature of an information system to represent
reality "as is".
These misconceptions shape the analysis and the
design of IT systems mostly as background
assumptions, and are undiscussed. The nature and
the role of information outside of the IT systems are
often underexposed in IT projects, and such
information is considered peripheral to these
systems. Once an IT system is in use, the
representations in the system are often considered as
leading. E.g., a sales order is no longer seen as an
agreement between a buyer and a seller; a sales
order is defined by its representation in the system.
The result of these misconceptions is that IT
systems often do not function properly in practice.
Unforeseen limitations are imposed on business
processes and on the commercial and logistic
opportunities of the enterprise, as a consequence of
the use of IT systems. Limitations that might cost
money internally and that trade externally.
This can produce various reactions that aim to
absorb these unforeseen negative consequences.
First, the system can be expanded, to remove, to
evade or to circumvent the limitations. Second,
practice might create its own way of working and its
own auxiliary systems for certain processes,
alongside the IT systems that were meant to do this.
Third, practice might learn to live with the
limitations.
At the basis of any solution for the problems at
issue must be the awareness that it is the task of
computer-based information systems to facilitate
business processes. These systems thus have an
instrumental nature and a serving role. They cannot
be the Archimedean point from which business
processes are controlled. Neither should these
systems determine how the business must be done.
To meet these demands IT systems should be
open in three meanings of the word: (1) they have to
be able to collaborate with other systems outside of
their own functional areas, (2) they have to be able
to collaborate with other systems within their own
functional areas, when these systems have a lower-
level execution task or a higher-level controlling
task, and (3) they have to be able to deal with events
within their functional area that (temporarily)
circumvent the system.
If we want to achieve this openness, then I think
it is useful, if not unavoidable, to exploit the concept
of "accounting" as a core concept in the design of
information systems. The accounting concept
analyses the accounting processes separated from
other processes, its operations are based on clearly
96
Suurmond C.
THE ACCCOUNTING CONCEPT AS KEY CONCEPT FOR BUSINESS MODELLING.
DOI: 10.5220/0004459000960102
In Proceedings of the First International Symposium on Business Modeling and Software Design (BMSD 2011), pages 96-102
ISBN: 978-989-8425-68-3
Copyright
c
2011 by SCITEPRESS Science and Technology Publications, Lda. All rights reserved
defined services and it implies clearly demarcated
organisational responsibilities. Although the concept
originates in the financial domain, it is very well
applicable outside of the financial field; indeed, the
concept should hold for all information that is used
communally in an organisation.
2 ORGANISATIONAL ASPECTS
OF ACCOUNTING PROCESSES
2.1 Division of Labour, Coordination,
Responsibility
Mintzberg defines the structure of an organisation as
“the sum total of the ways in which divides its
labour into distinct tasks and then achieves
coordination among them” (Mintzberg, 1979). He
distinguishes five different kinds of coordination
mechanisms, namely: (1) mutual adjustment, (2)
direct supervision, (3) standardisation of work, (4)
standardisation of outputs, and (5) standardisation of
skills. From an organisational point of view an
accounting department can be considered both as a
specialisation of labour and as a coordination
mechanism.
Accounting departments are often specialised in
the processing of either financial data, employee
data or production data. The justification of such
departments in an organisation is in the required
competencies of the employees, as well as in the
sensitivity of data. The departments have to meet a
variety of requirements of a variety of stakeholders.
They have to meet both the internal requirements of
the operational and management processes, and they
have to meet the requirements of external
stakeholders. The head of the department is
responsible for the quality of the information
supplied.
Accounting processes might also perform
coordinating roles in an organisation. When the
meaning and use of accounting data are clearly
defined, and when the accounting processes are
specified as well, this will in effect be a coordination
mechanism by standardisation of output and by
standardisation of skills. The required skills are
related to the ways and means of collecting and
verifying the data in the operational processes, and
(equally important) to the interpretation of the
information supplied.
2.2 Organisational Meaning
Directing information flows through an accounting
department or an accounting system also implies
formalising the language used. The language used
within an organisation is a mixture of everyday
speech, jargon, and forms of more or less formalised
language. Different departments can have different
interpretations of the same concept. If an order is
delivered to a customer in a truck with trailer, there
is one shipment. If two trucks arrive together for the
same delivery, does this involve one or two
deliveries, and one or two shipments? If the
customer demands that an order is delivered as a
whole, then the answer is clear for the commercial
department: in both cases one shipment is made. For
the freight documents it is clear as well: in the first
case one shipment is made with the accompanying
freight documents and in the second case two
shipments are made, each with their own
documents. For the receiving DC of the customer it
is also clear: in both cases two deliveries are made
that must be docked and unloaded separately.
In practice people within an organisation use
different kinds of sign systems simultaneously. The
everyday use of language is fairly free and
unconfined, even within the context of an
organisation. For commercial and financial
transactions the language used is more formalised
and is ultimately grounded in written law and case
law. The use of automated systems is another form
of formalisation of sign use. Part of it is formatting
(type and size of the fields), part of it is predefined
categorisation (tick the correct box) and part of it is
capturing some part of the organisational reality in
IT artefacts.
To implement an accounting system implies the
advance creation of conventions governing the
terminology, relations and meaning. In this sense it
is a formalisation of the use of language. It can also
be considered as a coordination mechanism in the
organisation: standardisation of meaning.
3 THE ACCOUNTING CONCEPT
3.1 Definitions
Starreveld arrives in his original work in the early
60s about information processes in organisations at
this definition of accounting: "The systematic
collection, recording, processing and supplying of
information for purposes of the managing and
functioning of a household and for purposes of the
accountability thereof" (Starreveld, 1963). The
American Accounting Association defines
accounting as follows: "the process of identifying,
THE ACCCOUNTING CONCEPT AS KEY CONCEPT FOR BUSINESS MODELLING
97
measuring and communicating economic
information to permit informed judgements and
decisions by users of the information”. The
definition of the AICPA in 1961: “Accounting is the
art of recording, classifying and summarizing in a
significant manner and in terms of money,
transactions and events which are, in part at least, of
a financial character, and interpreting the result
thereof” (Glautier et.al., 2001). The value of these
definitions is that they sketch a clear and normative
view of the role of accounting in the business
processes.
From the FASB, part 2: “The purpose of this
Statement is to examine the characteristics that make
accounting information useful. …All financial
reporting is concerned in varying degrees with
decision making (though decision makers also use
information obtained from other sources). …The
usefulness of information must be evaluated in
relation to the purposes to be served, and the
objectives of financial reporting are focused on the
use of accounting information in decision making ...
Even objectives that are oriented more towards
stewardship are concerned with decisions.
Stewardship deals with the efficiency, effectiveness,
and integrity of the steward. To say that stewardship
reporting is an aspect of accounting’s decision
making role is simply to say that its purpose is to
guide actions that may need to be taken in relation to
the steward or in relation to the activity that is being
monitored.”
3.2 Analysis and Expansion of the
Definitions
It is clear that the term accounting traditionally has a
strong connection to the financial management and
to internal and external financial reporting. At the
same time it becomes clear from the definition of
Starreveld that this financial aspect is not an
essential element of the definitions given. The
essential elements of the definitions are: (1) the
systematic nature of the collecting, processing and
making available of data, (2) the separation of the
collecting, processing and making available of data
on the one side and the interpretation of the data on
the other side, (3) the usage for operational
decisions, and (4) the usage for internal and external
reporting, analysis and accountability.
Regarding the systematic nature I would like to
draw attention to an element that is only found
explicitly in the definition of the AICPA: classifying
and summarising. Boisot has made an analysis of the
nature of information and he defines three aspects of
information (Boisot, 1998). One aspect concerns the
extent to which the information has been codified, a
second aspect concerns the degree of abstraction,
and the third aspect concerns the degree of diffusion.
In an accounting system information will have to be
codified, the users request information at different
levels of abstraction and an accounting system is a
mechanism for diffusion both within and outside of
the organisation.
4 OPENNESS OF INFORMATION
SYSTEMS
4.1 Two Forms of Information Supply
A car navigation system is an example of an open
system that gives its user the right information while
leaving him the freedom to take his own decisions.
Such a system continuously indicates the route to be
followed, taking into account the actual position,
possible routes and traffic intensity on the different
routes.
This information system is open because it
allows the driver to take his own decisions. He can
divert form the route whenever he opts to do so. The
navigation systems always works from the actual
situation; what happened before and what motivates
the choices of the driver are completely irrelevant.
To describe a route by step-by-step directions is
quite a different story. See for example the
directions given by the British AA for the trip from
Corrie on Arran to Bridgend on Islay:
Direction
Miles
Start out on unnamed road 0.00
Turn left onto the A481 0.07
Turn right 8.78
Continue by vehicle ferry
(Claonaig – Lochranza)
8.81
Turn right 13.47
Turn left onto the B8001 13.57
Turn right onto the A83
(signposted Glasgow)
18.63
Turn left
(signposted Islay ferry)
19.00
Contirnue by vehicle ferry
(Port Askaig – Kennacraig)
19.25
Turn left onto the A846 48.82
Arrive on the A846 56.66
Section time 6:16, Total time 6:16
Such a description loses a lot of its value when
the driver is forced off the prescribed route. Apart
BMSD 2011 - First International Symposium on Business Modeling and Software Design
98
from that, these specific directions do not take into
account that the driver should take either the ferry to
Port Askaig (as described), or the ferry to Port Ellen
(not described), depending on the time. And
checking the miles travelled against the odometer of
the car won’t work either, because of the two ferries
involved.
4.2 Two Forms of Information Supply
Starreveld writes in 1962 about information supply
for making judgements ex ante (for decisions in the
execution of processes) and ex post (for the
accountability of processes) (Starreveld, 1963). He
emphasises that on lower levels of the hierarchy
there is mostly a need for all kinds of "grab"-
information that is necessary to guarantee a correct
and efficient execution of the tasks by good
preparation.
Especially in production organisations there is a
tendency to increasingly emphasise a cycle of
planning and control where plans are made higher-
up in the organisation and executed lower-down and
where the results are reported back. This tendency is
reflected in ERP systems with their modules for
planning and control. The shop floor gets production
orders to be executed, and can only report back in
relation to those production orders. Registration of
unplanned activities is difficult or even impossible,
even if some problem on the shop floor made those
unplanned activities necessary.
Compare this tendency with this quote from
Robert Anthony: “Several authors state that the aim
of control is to assure that the results of operations
conform as closely as possible to plans. We
emphasize that such a concept of control is basically
inconsistent with the concept used in this study. To
the extent that middle management can make
decisions that are better than those implied in the
plans, top management wishes it to do so. And the
middle management can in fact make better
decisions under certain circumstances; to deny this
possibility is implicitly to assume that top
management is either clairvoyant, or omniscient, or
both, which is not so.” (Anthony, 1965)
Current ERP systems could be compared to the
directions given by the AA. The individual steps are
determined in detail in advance of the execution of a
process and employees in the execution of the
process get information pushed about the steps to be
taken. This way of working is vulnerable in case of
deviations, the responsibilities are higher-up and
those that perform the tasks are regarded as being
just cogs in the machine. The approach described by
Starreveld and Anthony assumes a situation in which
employees at every hierarchical level of the
organisation have tasks and responsibilities and
these are not frustrated by centralised and
bureaucratic information systems. They can get the
information they need whenever they ask for it, and
they can make their own decisions within their
domain. As a model this is more comparable to
driver assisted by a navigation system.
5 SOFTWARE DEVELOPMENT
5.1 Software Engineering
Like organisations, software engineering has its
methods for managing complexity. The multi-tier
model, the client/server model and the service
oriented architecture model are three examples of
the principle of 'separation of concerns'. Earlier
forms are the concept of structured programming,
employing units (Pascal) or modules (Modulo) and
later on object-oriented programming.
The mentioned mechanisms in software
engineering are each directly concerned with the
structure of the software as such. They do not or
only tangentially concern themselves with how the
software is used. In the last few decennia the
discussion is increasingly about architecture. At first
it was about the architecture of software, then about
the architecture of information systems and finally
about the architecture of the enterprise.
Within the software engineering as such Taylor
states “By architecture we mean the set of principle
design decisions made about a system; it is a
characterization of the essence and essentials of the
application” (Taylor et al., 2010). The architecture
of this artefact consists of a number of more-or-less
independent parts and the connections between them
(static structure). Further there is a specific way in
which the communication between the parts happens
(dynamic structure). Both for the static and for the
dynamic structure the architect makes use of a
repertoire of standard patterns. This manner of
working has first been charted by the architect
Christopher Alexander and later on has spread
widely within software engineering.
However, that similar mechanisms for managing
complexity have been developed both in
organisations and in software engineering does not
mean that the mechanisms of both worlds should be
considered equal. In the case of software we are
dealing with a strictly formal and determined
THE ACCCOUNTING CONCEPT AS KEY CONCEPT FOR BUSINESS MODELLING
99
system, whereas in the case of an organisation we
are dealing with a social system.
5.2 RM-ODP (Reference Model for
Open Distributed Processing)
The RM-ODP describes a model for the
collaboration of interconnected autonomous,
heterogeneous information processing systems. ”The
objective of ODP standardization is the development
of standards that allow the benefits of distributing
information processing services to be realized in an
environment of heterogeneous IT resources and
multiple organizational domains. These standards
address constraints on system specification and the
provision of a system infrastructure that
accommodate difficulties inherent in the design and
programming of distributed systems.” (RM-ODP,
1998).
In the formulated aims of the RM-ODP it can be
seen that accounting systems as described above fit
beneath the heading "organisational" in such an IT
structure. At the same time we must realise that a
technical infrastructure cannot say anything about
the organisational responsibilities and that the IT
component often must be complemented with a
human component for a complete information
supply. It is ill conceivable that the financial
department and the employee department would be
fully automated and unmanned departments.
5.3 Software Architecture &
Accounting Subsystems
The modern developments in software engineering,
coupled with architectural ideas such as those
expressed in RM-ODP are an solid basis for
representing accounting subsystems in software.
Such a separated accounting subsystem is accessed
exclusively through well-defined interfaces, which
are clear from a software perspective and the
separate terms of which can be mapped clearly to
definitions in the business processes. Such separated
accounting subsystems can meet the demands of
openness in structure and in management mentioned
earlier. Ideally, the accounting system records just
what actually is the case, regardless of any plans or
intentions. When someone takes stock from the
warehouse, this should be registered. The IT system
should not forbid registration, because of some rule
or constraint in the accounting system. It happened
and it is relevant to the representation of the stock in
the IT system, so it must be recorded in the
accounting system.
In the same vein, employees and systems should
be able to retrieve the information they need for their
tasks (within the boundaries of authorisation) from
the accounting subsystems involved and make their
relevant facts available for the accounting
subsystems. These processes should be based on a
pull model for information retrieval and a push
model for the information produced, all according to
the organisational tasks and responsibilities.
6 KEY ISSUES IN THE DESIGN
OF ACCOUNTING PROCESSES
6.1 Organisational Issues
Each accounting process has to be clearly grounded
in the organisation. It should be clear who is
responsible for the data. Accounting processes
should be located as closely as possible to the
operational processes involved, to ensure short
communication lines. Those responsible for the
accounting processes should have a clear
understanding of both the operational processes and
the accounting processes so that they are able to
solve any problems occurring in the collecting,
processing or interpreting of data. They should
actively monitor the usage of the accounting
processes, and indicate when they should be
adjusted because of changing practices. This final
point specifically concerns tracking change of
meaning, either abrupt or slowly evolving. Consider
for example the concept "customer" when an
organisation first encounters the difference between
the entity that places an order, the entity to which
they should be delivered and the entity that pays for
the delivered goods.
6.2 Modelling Issues
The domain of each accounting subsystem is clearly
defined, together with the meaning of the main
concepts. The rules for determining the identity of
the individual accounting entities are explicit. The
way in which both systems and human users refer to
the separate accounting entities is defined and tested
for practical applicability. Categories and range of
values of the attributes of the entities are defined in
advance.
The domain is determined by the question of
what is it concerned with and of what is information
requested. Essentially this is the same question as
the one asked about objects in OO-thinking. An
object is an identifiable unit with its own identity.
BMSD 2011 - First International Symposium on Business Modeling and Software Design
100
However, objects are no "ready-mades". They need
to be carefully defined. See the problem above of
what constitutes one shipment.
Another issue is how involved parties can
identify the accounting entities. Systems use unique
references, which must connect uniquely to physical
or conventional reality. This can happen by physical
identification such as barcodes or chips. It can also
happen by conventional identification such as GTIN
numbers for products or GLN numbers for addresses
and locations, managed by the international GS1
organisation.
Human users have to know what they are dealing
with as well. Either the references used are fit for
both machine and human recognition, or different
references are used for machines and for human
users.
6.3 Technical Issues
The accounting processes can be supported by one
or multiple IT subsystems with the responsibility for
their proper working lying with those responsible for
the accounting processes involved (and not with a
central IT department somewhere far away in the
organisation). Besides IT systems the accounting
processes can be supported by locally developed
solutions, in Excel for example, and by a systematic
storage of forms, receipts, and lists. What medium is
used to store data is less important, that the data are
collected and made available according to the agreed
procedures and in a correct, timely and complete
manner is essential.
The interfaces of the IT subsystems supporting
the accounting processes are explicit and complete.
There is no tacit meaning and there are no hidden
side effects. From the defined interfaces and from
the defined technical implementation of the IT
subsystem its behaviour can be fully explained. The
technical interfaces of the subsystem can be directly
mapped to the organisational aspects of the
accounting processes. The subsystems can deal with
the key characteristics as mentioned in RM-ODP
10746-1, paragraph 6.1: remoteness, concurrency,
lack of global state, partial failures, asynchrony,
heterogeneity, autonomy, evolution and mobility.
7 CONCLUSIONS
In the introduction two misconceptions were
identified as a source of many problems in the use of
IT systems, namely the idea that an information
system would coincide with the IT systems used and
that the information in IT systems would represent
the reality "as is". The need open systems to
facilitate business processes instead of systems
designed from closed and encompassing models
was discussed.
It was then analysed that the accounting concept
as defined by Starreveld should provide a good basis
for open systems. Well-designed accounting
subsystems that provide their services to the
organisation and to applications independently of
one another should make the systems more
manageable. A condition for this is that the
independent accounting subsystems are well
embedded into the organisation, as closely as
possible to the operational processes. Modern
software architectures like RM-ODP should provide
a good technical basis for this.
The design of an accounting subsystem for a
specified area starts with abstracting and modelling
it. This should be accompanied by a thorough
analysis of the process logic in the area, to arrive at
an adequate and practical choice of the entities and
references. This should also be accompanied by a
certain formalisation and standardisation of the use
of language.
When the people involved are familiar with the
ins and outs of the chosen model they will be able to
work well with the model in the interaction with the
accounting subsystem while retaining the freedom of
interpretation of data from the subsystem because
they know what is not represented and because they
are able to combine the data with data from other
sources autonomously.
In conclusion: adequate accounting systems
function semi real time, provide crucial services to
the business processes, and are driven by employees
that have a thorough practical knowledge of these
processes.
REFERENCES
Mintzberg, H., 1979. The Structuring of Organizations,
Prentice Hall Inc. Englewood Cliffs, N.J.
Starreveld, R. W., 1963. Leer van de administratieve
organisatie, N. Samsom NV. Alphen aan den Rijn, 2
nd
edition.
Glautier, M. W. E., Underdown, B., 2001. Accounting,
Theory and Practice, FT Prentice Hall. Harlow, 7
th
edition.
Boisot, M., 1998. Knowledge Assets, Oxford University
Press. Oxford.
Anthony, R., 1965. Planning and Control Systems,
Graduate School of Business Administration Harvard
University. Boston.
THE ACCCOUNTING CONCEPT AS KEY CONCEPT FOR BUSINESS MODELLING
101
Taylor, R. N., Medvidovic, N., Dashofy, E.M., 2010.
Software Architecture, John Wiley and Sons,
Hoboken.
RM-ODP, ISO/IEC 10746-1, 1998, Information
technology – Open Distributed Processing- Reference
Model: Overview. ISO/IEC, Genève
BMSD 2011 - First International Symposium on Business Modeling and Software Design
102