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

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

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

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

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

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

edition.

Glautier, M. W. E., Underdown, B., 2001. Accounting,

Theory and Practice, FT Prentice Hall. Harlow, 7

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